Patching PHP Is Only Half the Job

TechSpective runs on WordPress, and WordPress runs on PHP, so when the PHP project tells everyone running it on a web server to update immediately, I pay closer attention than I do to most advisories. PHP is a lot like the plumbing in a house. You can repaint the walls and put in new countertops, but the pipes behind the drywall stay right where they were, and nobody gives them much thought until there’s water on the floor. Plenty of organizations are dealing with water on the floor today.

What the PHP Advisory Says

The PHP project released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 under CVSS v4.0, and both can allow unauthenticated remote code execution. One involves how PHP handles running out of memory mid-request, which can leave internal data half-built and then get treated as valid during cleanup. The other lets state from one request hang around after its memory has been freed, where a later request on the same worker can pick it up.

According to the advisory, the exposure covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP team flags mod_php as the highest risk, citing a demonstrated exploit where an unauthenticated request fires before any application code runs. The advisory lists configuration changes that narrow specific attack paths, but the team is blunt that updating is the only complete fix.

PHP gave advance notice on Oct. 20 that a critical release was coming and said it might ship early if details went public or exploitation turned up in the wild. Matt Hull, VP of cyber intelligence and response at NCC Group, said there are now reports of exploit activity, and Ramy Rahman, senior principal solutions engineer at ArmorCode, said exploitation has been observed through a honeypot network.

Patching Doesn’t Prove a Server Is Clean

So should you install the update and call it a day? You should absolutely install it, but calling it a day is where people get into trouble. Hull warned that “organizations should not mistake patching for proof that their systems are clean.” If an attacker got in before the update, patching is a bit like changing the locks while the burglar is still in the house, and he may have propped a back door open on the way in.

Hull said a successful exploit could give an attacker remote shell access and a way to move laterally into other parts of the environment. His advice is to find every PHP deployment, apply the official updates right away, and isolate or disconnect any internet-facing system that can’t be patched yet. Once that’s done, he recommends investigating the period when systems were exposed and watching closely for signs of compromise instead of assuming the risk has passed.

Chris Jacob, field CISO at Securonix, gets more specific about what that investigation looks like. He suggests preserving logs from the web server, proxy, WAF, and endpoints, then combing them for suspicious POST or multipart requests, memory exhaustion, repeated PHP worker crashes, and processes the web server had no business launching. Because one of the flaws can fire before application code runs, an application log that looks fine doesn’t clear the host. If there’s evidence of code execution, Jacob recommends isolating and rebuilding the system and rotating any credentials or API tokens the PHP process could reach.

Forgotten and Outdated PHP Installations

The pipes behind the drywall are the part that worries me. Jacob points out that the vulnerabilities live in the PHP runtime, so updating WordPress, Drupal, Magento, or a custom application doesn’t touch the underlying exposure. “The application may look current while the interpreter underneath it is years out of support,” he said.

He also noted that production servers are only part of the inventory, and that old services, development systems and reusable container images need the same attention. PHP 8.1 and earlier no longer get updates from the PHP project, so Jacob says those systems need a vendor backport or a move to a maintained version. Given the severity, the PHP security team did publish minimal source backports for 7.4, 8.0 and 8.1 for people building from source.

AI Is Shrinking the Window to Patch

Some of the pitches in my inbox today described these flaws as AI-discovered, although the PHP advisory doesn’t say how they were found. Rahman noted that the roughly 70% figure making the rounds reflects how much of the web uses PHP, not how many sites are vulnerable, and he said it’s too early to know whether the impact will come anywhere near Heartbleed, the OpenSSL bug that rattled the internet in 2014.

Rahman is more concerned about speed. He said AI makes it easier for attackers to sift through large amounts of code, revisit bugs that used to be considered too hard to exploit, and reverse-engineer patches as soon as they’re published. “Flaws we once thought were impractical to exploit are back on the table,” Rahman said. He described a credible worst case as an automated campaign working its way through unpatched sites, leading to data theft, fraud and outages.

If you’re still running PHP 8.2, this release comes with an expiration date attached. The branch reaches end of life on Dec. 31, 2026, and won’t receive security fixes after that, which means the next critical PHP advisory may not include a patch for it at all.