PHP2Shell: Security Patches Are Out, and Attacks Are Already Underway

PHP2Shell is the name given to the two critical flaws that the PHP team has just urgently patched. And with good reason: with an Apache web server paired with mod_php, a simple HTTP request is enough to execute code on the server. Here's the key information you need to know.

This morning, I published an article about the disclosure of information regarding these two critical flaws before the fixes were available. This Wednesday, October 21, 2026, a little before 4 p.m. (Paris time), the PHP security team released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. They patch vulnerabilities CVE-2026-109618 and CVE-2026-109619, both associated with a CVSS v4.0 score of 9.2 out of 10. That score is in line with what the PHP team had announced, while other sources had indicated a score of 10 out of 10.

These flaws were reported by Calif, OpenAI, and Wiz, with the help of AI models. According to the PHP Foundation, the underlying issue had actually been identified as early as 2024, during an audit conducted by Quarkslab, without a fix being proposed. "The delay was a structural failure, caused both by the security team's decision-making process and by its lack of resources," the PHP Foundation acknowledges in a mea culpa.

All execution modes that serve web requests are affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. "We consider the risk to be highest for mod_php, with a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code is executed," the PHP security team explains. That said, as you may have understood, PHP-FPM and the other modes are not spared.

Two Flaws, One Shared Weakness in Error Handling

The two vulnerabilities have one thing in common: when a request is abruptly interrupted, PHP can leave memory in an inconsistent state. Here's what we know about these two flaws:

• CVE-2026-109618: an out-of-memory error can interrupt PHP while some request data is only partially initialized. The cleanup phase then treats it as valid. According to the bulletin published on GitHub, code execution was validated on mod_php with the limits corresponding to the default configuration.
• CVE-2026-109619: a fatal error can leave references pointing to a memory area that has already been freed. The next request, handled by the same worker, can then reuse it (use-after-free). The Session Upload Progress feature, enabled by default, is among the confirmed paths, with code execution validated on mod_php and on PHP-FPM.

For its part, Wiz says it obtained unauthenticated code execution on WordPress, Drupal, and Joomla, as well as a memory leak that could contain passwords or API keys, through these PHP flaws. In all cases, everyone agrees on one point: regardless of the application, the flaw is in PHP, not in the application itself.

On the exploitation side, Cloudflare says it has observed attack traffic targeting its customers, with payloads modified to bypass its WAF rules. This is no surprise, and the situation could quickly spiral.

Update PHP Now, Including on End-of-Life Branches

It is essential to update PHP across all your web servers immediately. There is no doubt that cybercriminals are already on it: Cloudflare has already observed activity on its side. Here's what you need to do:

• Branches 8.2 through 8.5: install the fixed version for your branch. Linux distributions and LTS vendors received the fixes early. As a reminder, PHP 8.2 will no longer receive fixes after December 31, 2026. The update is already available on Debian 13. Below is an example from a test server updated this afternoon.

• PHP 8.1 and earlier: there is no official update, so you need to choose an exit strategy. The cleanest option is still to migrate to a maintained branch. Failing that, check whether your distribution or LTS provider offers a backported fix. For PHP 7.4, 8.0, and 8.1, the PHP team also published minimal source code backports that you must compile yourself. Below that, no fix exists: apply the temporary measures described below and block multipart requests upstream (WAF, reverse proxy) if the application does not need them. If none of that is possible, the UK's NCSC recommends a radical measure: take the system offline until it can be updated.
• rpms.remirepo.net repository: there is no update today for this community-maintained repository. Switch to distribution packages or compile from source.

Note: hosting provider Hosted Power has released an open-source extension designed to close the multipart attack path for both flaws on an unpatched PHP installation, from PHP 5.6 to 8.5, without recompiling PHP. Since version 3, it removes the Session Upload Progress handler and includes the multipart parser from the official fix. It may help servers that will not receive any patch, but its authors say it themselves: the real fix remains updating PHP. Released in an emergency, the tool has already seen several corrective versions during the day, so make sure it is properly loaded by the web server via phpinfo().

If you cannot patch right away, some measures reduce exposure without eliminating it: force memory_limit to -1 (while relying on the container or cgroup for limits), lower post_max_size, set session.upload_progress.enabled to 0 and, on PHP 8.5, fatal_error_backtraces to 0, then restart each worker. The measure mentioned this morning is therefore confirmed, but it only blocks session-related paths, so it must be supplemented. The ideal solution is really the security patch.

Good luck!

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio