Security
Web Development
PHP2Shell: Patching the Layer Underneath WordPress and Drupal
On October 21, the PHP project shipped emergency fixes for two critical flaws in PHP itself. Together they are being called PHP2Shell. Both can let an attacker with no account run code on a web server, and both are rated 9.2 out of 10. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
If your site runs on WordPress, Drupal or almost any other PHP application, this applies to you. Updating WordPress or Drupal does not fix it. The flaws live in the PHP runtime underneath the application. That layer is updated by your host, your server packages, or your container images.
Here is what is affected, how to confirm you are patched, and what to do if you cannot patch today.
What happened
The flaws are tracked as CVE-2026-109618 and CVE-2026-109619. Researchers at Wiz, Calif and OpenAI found them and worked with the PHP security team on the fix. The researchers say AI tools helped them turn long-standing bugs into working exploits in about a week.
Disclosure did not go to plan. Details leaked on October 20, ahead of a planned October 22 release, so PHP moved its fixes up a day. Within hours of the release, the security firm watchTowr reported active exploitation attempts against both flaws. Cloudflare reported attackers changing their payloads to get around its firewall rules. As of this writing, no confirmed break-in of a specific server has been reported. CISA has urged immediate patching.
Some organizations did not wait to find out. In the Netherlands, several government and education services went offline as a precaution. That is an unusual step, and it shows how seriously operators are taking this.
Why this one is different
Most PHP security news is about plugins, modules, or the CMS itself. Those flaws depend on what a site has installed. PHP2Shell does not. Because it sits in the language engine, even a page that only prints "Hello World" can be attacked on a vulnerable PHP version. A site with flawless application code is still exposed.
Every common way of serving PHP to the web is affected. That includes PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP advisory rates mod_php as the highest risk. There, a single request can trigger the attack before any application code runs. PHP-FPM is harder to exploit, but it is not safe.
There is a second risk that does not require running code at all. An attacker can read memory from the PHP worker process. That memory may hold passwords, session tokens, API keys and data from other visitors' requests.
The affected code goes back more than a decade, to PHP 5.4. Old, unsupported servers are exposed too, and they will not get an official update.
How to confirm you are patched
Find every PHP runtime that serves web traffic. Include staging servers, microsites, and old campaign sites that still answer requests. Forgotten servers are where incidents like this tend to land.
Check the package changelog, not just the version. Linux distributions got the fix early and often apply it to older-looking version numbers. A distribution package can be patched while still reporting an older 8.2 or 8.3 release. Look for the two CVE numbers in the changelog.
Get written confirmation from your host. On managed hosting, the host patches the runtime. Ask which version or package you are on and when it was applied.
Rebuild your container images. A patched base image does nothing until your own images are rebuilt and redeployed.
Restart PHP. After updating, restart Apache, PHP-FPM and any long-running PHP workers. The old code keeps running until you do.
One thing to check after patching: the fix adds a new hard memory limit. A process that reaches it ends immediately, without running its shutdown handlers. Review your memory_limit and post_max_size settings against what your application really needs, especially for large uploads and imports.
If you cannot patch today
The PHP project is clear that only updating fully protects a server. The steps below reduce exposure to specific attack paths. They do not make a server safe.
For CVE-2026-109618: the advisory recommends setting memory_limit to -1 so applications cannot override it. Keep post_max_size low and enforce request-size limits at the web server or proxy.
For CVE-2026-109619: set session.upload_progress.enabled to 0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces to 0. This blocks the confirmed attack paths but not every variant.
Turn on your firewall provider's rules. Cloudflare and other providers have deployed rules for these flaws. Treat them as a stopgap, because attackers are already working around them.
If you run PHP 8.1 or older, no official release is coming. The PHP security team has published source patches for 7.4, 8.0 and 8.1 for teams that build from source or are waiting on a vendor. For most sites, this is the moment to plan an upgrade to a supported branch. PHP 8.2 itself reaches end of life on December 31, about ten weeks from now.
Signs of an earlier compromise
Patching closes the door. It does not tell you whether someone came through it first. The researchers suggest checking your logs for these signs.
Unusual upload requests. Look for odd multipart requests followed by memory-limit errors or repeated 500 errors.
Oversized session cookies. Look for unusually large PHPSESSID cookies in responses.
Unexplained restarts. Look for PHP workers restarting with no clear cause.
Because of the memory-read risk, consider rotating secrets stored on any server that was exposed. That includes database passwords, API keys, and payment or CRM credentials.
What this says about maintenance
When we wrote about Drupalgeddon in 2014, attacks began about seven hours after the patch. PHP2Shell follows the same pattern one layer lower. The PHP Foundation has said a 2024 audit found early signs of one of these flaws, and that work on a fix then stalled for months. It called that delay "a structural failure." AI tools later turned the theoretical bug into a working exploit in days.
That is the change to plan around. Bugs that sit unnoticed for years can now become working attacks very quickly. This week, the teams in the best position already knew which servers ran PHP, who patched each one, and how fast. That inventory is worth building now, before the next runtime flaw.