PHP2Shell Vulnerability: The Flaw Is in PHP Itself

By Editorial Team | October 28, 2026

We have covered PHP2Shell twice already: in our post of 21 October and in our Top 5 of 23 October. A week after PHP shipped its emergency patches, this is a closer look at the PHP2Shell vulnerability: what the flaw is, what turned out to matter, and what is still worth checking this week.

Two critical flaws in the PHP core, known together as PHP2Shell, let unauthenticated remote attackers run code on affected web servers under certain conditions. The PHP2Shell vulnerability covers CVE-2026-109618 and CVE-2026-109619, both rated 9.2 in CVSS v4.0. It affects every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

The weakness sits in PHP itself, not in a plugin, theme, framework or custom application. Patching WordPress, Drupal, Joomla or another PHP application is therefore not enough. You have to update the PHP runtime, or install a patched package from your operating-system vendor, hosting provider or appliance supplier. This post reflects the situation as of 27 October 2026.

PHP2Shell vulnerability illustrated: a web server cube with a bright line entering from the outside and passing through a glass PHP layer

The flaw sits in the PHP runtime, below the application.

What Is the PHP2Shell Vulnerability?

PHP2Shell is the name for two related memory-handling flaws in the PHP interpreter. Both can lead to code execution with the privileges of the PHP worker process, and researchers have also described memory disclosure, which could expose sensitive data from the web server process.

Both flaws come from how PHP handles a request that ends abnormally, for example during an out-of-memory condition or a fatal error. PHP can leave internal request data half initialised, or keep pointers to memory that has already been freed. A later request handled by the same PHP worker may then run into that corrupted or stale state. An attacker needs no credentials and no user session. Specially crafted requests may be enough to corrupt PHP’s memory state and, in the end, run arbitrary code on the server.

CVE-2026-109618 is remote code execution through out-of-memory corruption. If PHP is interrupted while internal request data is only partly initialised, its cleanup routine can treat invalid data as valid. Attackers can use that to corrupt memory and execute code.

CVE-2026-109619 is remote code execution through stale global state. If a fatal error interrupts PHP during serialisation or deserialisation, internal context data can keep pointing at memory that is released when the request ends. PHP workers often stay alive to serve later requests, so the next request may touch that freed memory. The result can be information disclosure or code execution. The two flaws share one theme, PHP keeping or misreading memory state after an abnormal end of a request. They differ in the path that creates and abuses that state.

Illustration: a row of server cubes of different sizes, all connected to one shared PHP runtime block

Many sites and applications share one PHP runtime.

Who Is Affected by the PHP2Shell Vulnerability?

The PHP project states that installations serving web requests are affected. That covers the usual deployment models: PHP-FPM behind NGINX or Apache, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Websites and applications built on PHP are exposed if the runtime underneath them is not patched. WordPress, Drupal, Joomla and many custom web applications all fall into that group. Whether a given attack path can be reached also depends on configuration. CrowdStrike notes that PHP’s shipped defaults do not allow the out-of-memory path it demonstrated, while setups tuned for large uploads can. Treat every unpatched system as exposed.

The PHP security team treats Apache mod_php as the highest-risk setup. The module embeds PHP directly in the Apache process, so the interpreter and the web server share one process context. Researchers showed that in this configuration a single unauthenticated request can trigger the flaw before any application code runs. If you use mod_php, make patching your first priority and check whether PHP-FPM is a better fit for your environment. Moving to PHP-FPM does not remove the need to patch, because it is affected too, but it can give better process isolation in many hosting setups.

PHP2Shell vulnerability fixes: eight glass blocks in a rising staircase, the four newest lit in DIESEC blue and the four older ones dimmed

Four branches have patched releases, older ones rely on backports.

Fixed Versions and Urgent Actions

The PHP project released emergency patches for the PHP2Shell vulnerability on 21 October 2026, after details of the flaws had leaked online the day before. Update to one of these versions, or install the equivalent patched package from your Linux distribution, hosting provider or appliance vendor:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

Most environments do not install PHP updates automatically. Identify every server, container, staging environment and appliance that runs PHP, find out which version actually serves web requests, and start with the internet-facing systems. The PHP version on the command line can differ from the one PHP-FPM or Apache runs, so check the web-serving one. Restart the PHP workers after the update and rebuild container images, so the fix takes effect everywhere.

PHP 8.1 and earlier no longer get updates from the PHP project. If you still run them, use a patched package from your distribution or long-term-support vendor, or move to a supported branch. The PHP security team also published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source. Treat the migration as urgent, and note that PHP 8.2 reaches end of life on 31 December 2026. Configuration changes are not a substitute for the update. The PHP project states that there are no complete mitigations and that updating is the only safe choice.

PHP2Shell vulnerability timeline: a first marker before the patch date and a cluster of markers after it

The first attempt came four days before the patches.

A Week Later: What Is Known About the Attacks

As of 27 October, public reporting describes attempts to exploit the PHP2Shell vulnerability, and the picture has been moving. Amazon Threat Intelligence recorded the first attempt, against one of its honeypots, on 17 October, four days before the patches, and said it is unclear how the actor got exploit information while the flaws were under embargo. The technical details leaked on 20 October. On release day Amazon saw several proof-of-concept exploits and described broad exploitation attempts in the wild after the release. watchTowr reported that its honeypot network observed exploitation of both CVEs on 21 October. Zscaler recorded 1,156 exploitation attempts from 156 unique IP addresses against 70 organisations in the first 48 hours after disclosure, using several different tools.

The UK National Cyber Security Centre urged organisations to update immediately and, where that is not possible in time, to consider taking systems offline. On 26 October, CISA added both CVEs to its Known Exploited Vulnerabilities catalog and gave US federal agencies until 29 October to fix them. As of writing, how many systems have actually been compromised has not been established publicly, and that may change.

The flaws have been demonstrated in practice. Wiz Research, which found them together with OpenAI Codex Security and Calif, showed unauthenticated code execution against current WordPress, Drupal and Joomla container images. CrowdStrike reproduced working proof-of-concept exploits in its own testing and describes the attack as quiet: the worker does not crash, the server answers with HTTP 200 and application logs show nothing unusual. Earlier assessments were more cautious. On 22 October the German BSI said it knew of no successful exploitation at scale, and in its analysis of 23 October CrowdStrike said attackers have to adapt public proof-of-concept code to the exact PHP version, libraries, server API and application, and that it had seen only testing, probing and unsuccessful attempts. CrowdStrike also expected capable actors to try the flaws against high-value targets, and many more to follow once a public exploit works for a widely used setup. With the CISA listing in place, treat those assessments as a snapshot, not a reason to wait.

PHP2Shell vulnerability response: four glass tiles with icons for inventory, update, restart and log review

Inventory, update, restart, check the logs.

What SMEs Should Do About the PHP2Shell Vulnerability

Start with the update. List every system that serves PHP web requests: production servers, staging environments, development machines, containers and managed hosting. Then move each one to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply the vendor’s patch. If an application or plugin pins a PHP version, test the new runtime in staging first. With a flaw this severe, keep that test short and focused. It is not a reason to postpone the fix.

Before you update a system that has been exposed, preserve the PHP and web server logs and look for new web shells, unexpected cron jobs and accounts you do not recognise. Both flaws are triggered by errors inside a request, so POST requests containing PHP_SESSION_UPLOAD_PROGRESS, unusually large or deeply nested multipart requests, PHP memory-limit errors in the web server error log that end in “in Unknown on line 0” (a sign that no PHP script was running yet), files written to the web root and outbound connections from PHP processes you cannot explain deserve a closer look. Because exploitation can happen before application code runs, application logs alone may not show it. Amazon advises starting any investigation from 17 October, the earliest known attempt, not from the disclosure date.

If a system cannot be updated right away, apply the temporary mitigations in the PHP advisory. They reduce exposure to specific attack paths but do not make an installation safe. If even that takes too long, the NCSC advises considering taking the system offline until it is mitigated. Then confirm that your detection and response coverage reaches the web tier. Correlate endpoint, server and network telemetry so that odd PHP worker behaviour, unexpected command execution or post-exploitation activity gets spotted quickly.

Illustration: a central web server cube enclosed by a thin ring, all connected blocks lit

Patching first, then keeping watch on the web tier.

Closing Thoughts

The runtime under your website is part of your attack surface, however rarely you look at it. The fix is available. What takes time is knowing where PHP runs, who owns each system and whether it is really patched.

One detail of the PHP2Shell vulnerability deserves attention in the weeks after patching: the attack is described as quiet. The worker does not crash, the server answers with HTTP 200 and the application logs show nothing unusual. What does show up is the aftermath, such as a web server process starting a shell or a new file appearing in the web root. That is the kind of activity Managed Detection & Response powered by NovaMDR is built to watch for, 24/7, across endpoints, networks, cloud services and firewalls. It complements patching and does not replace it.

And if you want to know whether your own PHP estate is as patched as the inventory says, a penetration test of your internet-facing systems shows what an attacker can really reach. A patch note is a claim, a test is evidence. Whether you run security yourself, add targeted support or hand it over completely, we match the help to your team.

Sources: PHP security advisory, CISA Known Exploited Vulnerabilities catalog, UK NCSC: critical security issue affecting PHP. Reporting: AWS Security Blog: PHP2Shell exploitation prior to public disclosure, Zscaler ThreatLabz: CVE-2026-109618 and CVE-2026-109619.