In short: One week after the first observed attack attempt, PHP2Shell is now mainly a question of implementation: patches for PHP 8.2 to 8.5 have been available since 21 October, major distributions have followed, and the BSI (German Federal Office for Information Security) warns at level orange. Attack attempts have been observed; the BSI initially did not report confirmed successful attacks on a broad scale. Still open are old versions, servers that have not been restarted and the question of what happened before the patch.
The situation in three sentences
PHP2Shell is two critical vulnerabilities in the PHP interpreter itself, CVE-2026-109618 and CVE-2026-109619, each rated CVSS v4.0 9.2. They allow remote code execution without logging in, which is the case security people fear most. PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are affected; the PHP team sees the highest risk with mod_php.
This overview sorts the status on 25 October 2026 by actor. You will find the course of events day by day in the PHP2Shell chronology; here the focus is on the overall picture.
What is confirmed after one week
The statements from the PHP project are established: the releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 of 21 October close both vulnerabilities. For PHP 7.4, 8.0 and 8.1 there are only minimal source backports, no official releases. php.net stresses that there are no complete interim measures and that the update is the only safe route.
On 23 October a notice on CVE-2026-115560 was added. It concerns only an unusual session configuration; as a remedy, php.net names session.upload_progress.enabled=0 until the next regular bugfix release.
The major distributions have also taken a position. We have checked the official announcements:
| Vendor | Status according to the official announcement |
|---|---|
| Ubuntu | USN-8948-1 for 22.04, 24.04, 26.04 and 26.10; USN-8948-2 for 14.04 to 20.04 via Ubuntu Pro |
| Debian | corrected packages for bookworm (php8.2, DLA-4848-1) and trixie (php8.4, DSA-6574-1) |
| Red Hat | bulletin RHSB-2026-013 for RHEL 7 to 10; some updates available, others in progress |
Red Hat rates CVE-2026-109618 as "Important" with its own rating and justifies this with higher attack complexity. That is a different rating method from that of the PHP project and no reason to postpone the update.
How authorities assess the situation
The BSI has declared warning level 3 / orange. It recommends updating immediately and, if that is not possible right away, taking the affected web servers offline temporarily. The BSI expected rapid, large-scale exploitation. What the rating means is explained on the page What the BSI recommends on PHP2Shell.
According to reports, CERT-EU considers it possible that versions from PHP 5 onward are affected and advises isolating publicly reachable applications if they cannot be patched promptly. CERT-Bund (the German government CERT) and the security company Huntress have also issued warnings.
The recommendation to shut down if necessary was visibly implemented. According to media reports, the city of Mainz took its central web portal offline as a precaution; offices remained reachable by telephone and email. In Hesse, according to hessenschau, sites of the state government, the BKA (German Federal Criminal Police Office) and the cities of Kassel and Wiesbaden were temporarily offline. The State Chancellery reported no attack, and the sites were reachable again in the evening. According to reports, other municipalities, universities and hospitals acted similarly.
What is known about attacks
The separation between observation and confirmation is particularly important here.
- Observed: According to media reports, there was a first attack attempt on 17 October, observed by Amazon. Cloudflare and Patchstack reported attack attempts; Cloudflare also saw changed attack patterns.
- Reproduced: According to reports, watchTowr says it reproduced CVE-2026-109618.
- Not confirmed: The BSI initially reported no confirmed successful exploitation on a broad scale. Huntress saw no attacks in partner environments at the time of its report.
- Unknown: There are no published, confirmed indicators of compromise. Anyone who wants to check whether a server is affected has to look for behavioural patterns.
Two figures are circulating on the scale. The Unit 42 researchers at Palo Alto Networks arrived at more than 22.6 million potentially vulnerable instances reachable from the internet. CybelAngel cites around 2.24 million reachable PHP hosts, 59 percent of them, by its own evaluation, on versions without an upcoming official fix. The two measure different things and are not directly comparable. A classification is provided by the article Reading the figures correctly.
What is still open
Three questions will determine the coming weeks:
- Old versions: According to the evaluations mentioned, a large part of the reachable PHP installations runs on branches without an official fix. Whether commercial long-term offerings cover PHP2Shell has to be confirmed in writing by the provider in each case.
- Incomplete updates: New packages only take effect once all PHP processes have been restarted. Red Hat expressly points out that a mere reload is not enough.
- The time before the patch: Between 17 and 21 October, servers were vulnerable while attack attempts were already under way. A patch does not prove that nothing happened during this time.
Keep web server and PHP logs from 20 October onward, as the trade press recommends. Without logs, the most important open question for your server can no longer be answered later.
What operators should check now
For your own situation assessment, four checkpoints per server are enough: Is PHP at a fixed version or a confirmed backport? Have all processes been running since the update? Is session.upload_progress.enabled switched off on the server side while the advisory on CVE-2026-115560 is outstanding? Have there been anomalies since 17 October?
For the last point, the page Have I already been compromised? helps. A web server process that starts a shell, new PHP files in upload folders, unknown cron jobs or SSH keys are warning signs that justify a closer investigation.
How does PHP SOS help?
- We assess the patch level of each server on the basis of package status, changelog and process start times.
- Where no patch is available, we apply the interim measures from php.net and clarify the route to a supported version.
- We preserve logs from 20 October onward and look for traces from the time before the patch.
- With PHP2Shell immediate help, we bundle these steps for companies that need clarity quickly.
Frequently asked questions
Is PHP2Shell already being actively exploited?
Cloudflare and Patchstack reported attack attempts. The BSI initially did not report confirmed successful attacks on a broad scale. Huntress saw no attacks in partner environments at the time of its report.
Is the danger over after the patches?
No. The patches only protect servers that have installed them and restarted all PHP processes. Systems on PHP 8.1 and older remain vulnerable without a confirmed backport, and a patch does not remove malware planted beforehand.
Why were authority websites offline?
According to media reports, the city of Mainz and several bodies in Hesse, among others, took their websites offline as a precaution. This matches the BSI recommendation for servers that cannot be updated immediately. A shutdown does not mean that an attack took place.
Are there indicators for a PHP2Shell attack?
There are no published, confirmed indicators of compromise so far. Detection relies on behavioural analysis, for example on PHP processes that start a shell, or on new PHP files in upload folders.