The PHP vulnerability PHP2Shell affects all versions of the scripting language and hundreds of millions of web applications worldwide, and several hosters took websites offline as a precaution (including their own website). AI tools helped find the flaws, and a published patch itself becomes a race.
On October 21, 2026, shortly before 4 p.m., security updates for PHP were released that close two critical vulnerabilities. The German Federal Office for Information Security (BSI) rated the situation in a security advisory with criticality 3 (orange). Operators should therefore act immediately. In Germany, several websites were temporarily unreachable because operators disconnected their servers from the internet as a precaution.
The flaws can be understood without expert knowledge: a memory error leaves half-finished states behind, which PHP later processes incorrectly. What is affected is the runtime environment, not a single CMS. What is established, unconfirmed and open should be kept clearly apart. The information is current as of October 22, 2026, and details may change.
The PHP vulnerability at a glance
There are two vulnerabilities in the PHP programming language itself, not in a single content management system. They carry the identifiers CVE-2026-109618 and CVE-2026-109619. Both are rated critical with a value of 9.2 under the CVSS 4.0 scoring system (Common Vulnerability Scoring System, a scale from 0 to 10). From these values, the BSI concludes that exploitation requires neither a login nor user interaction. The goal is remote code execution (RCE), that is, running foreign program code on a server from a distance.
Reports also call this PHP vulnerability PHP2Shell. According to the BSI, the name is meant to recall the similarity to the Log4Shell vulnerability. It has nothing to do with the older WordPress flaw "wp2shell".
The timeline is documented by the announcements of the PHP project. On October 20, 2026, a pre-announcement without details was published. On October 21, 2026, the patches and the advisories followed at 14:00 UTC (4:00 p.m. German time). In its BSI security advisory of October 21, 2026 (version 1.1) (the document carries the identifier BITS-H No. 2026-297981-1132, while the URL contains 1032), the BSI writes that a proof of concept is public and that no confirmed exploitation is known yet. However, there are unconfirmed reports of exploits.
| Identifier | Short description of the cause | Severity |
|---|---|---|
| CVE-2026-109618 | Memory runs low, PHP aborts a request midway through preparation, and the cleanup treats half-finished data as valid | CVSS 4.0: 9.2 |
| CVE-2026-109619 | State from an earlier request remains in the worker and is used by a later request | CVSS 4.0: 9.2 |
What is behind CVE-2026-109618 and CVE-2026-109619
Both flaws belong to the class of memory errors. Put simply, PHP works with memory areas that are reserved per request and released again afterwards. If something goes wrong, states arise that the rest of the program flow does not expect. This is exactly where the vulnerabilities strike. The following description is deliberately simplified and contains no attack details.
For CVE-2026-109618, the PHP project describes an abort on insufficient memory (out of memory). If this abort is triggered while the internal data of a request is only partly prepared, it leaves invalid states behind. During the subsequent cleanup of the request, PHP reads this data and branches on it. As a trigger, the advisory mainly names memory-intensive processing of form uploads (multipart/form-data). Large memory requests by the application itself can also trigger the error.
With CVE-2026-109619, in contrast, state from an earlier request remains in the so-called worker. A worker is a PHP process that serves many requests one after another. A later request can use this stale state before it is reset. So at least two requests that reach the same worker are needed. According to the advisory, confirmed paths are diagnostic messages about settings before initialization, the session upload progress and, in PHP 8.5, the function fatal_error_backtraces.
The situation is most dangerous with Apache using mod_php. An exploit was demonstrated there in which an unauthenticated request can trigger the attack before any application code runs. For PHP-FPM, a partial path was confirmed according to the advisory. What the flaws allow in an individual case depends on the environment. The patches reset the state completely and remove the cause.
Which PHP versions and systems are affected
According to the BSI's assessment, all known PHP versions are affected, going back to at least PHP 5. The flaws are fixed in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP update 8.5.12 applies to the newest branch, the other numbers to the respective older branches that are still supported.
For the already discontinued branches 7.4, 8.0 and 8.1, there are no regular updates any more. According to its security announcement, the PHP Security Team provided minimal backports in the source code. A backport transfers a fix to an older program version without raising the version number. Linux distributions and vendors with long-term support (LTS) partly ship their own fixes. For PHP 8.2, security support ends on December 31, 2026. A branch without support is considered End of Life (EOL).
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
