- PHP released fixes on October 21 for CVE-2026-109618 and CVE-2026-109619, which can let an attacker with no account run code on a server.
- The flaws sit in PHP itself, so updating WordPress or Laravel does not fix them. PHP 8.1 and older need a vendor backport, a source build or a migration.
- Build an inventory of every PHP server, plan for the older ones, and recheck memory settings after updating, because the fix adds a hard memory limit.
For supported PHP versions, the PHP2Shell fix is a routine update, followed by a check of memory settings. For PHP 8.1 and older, it means a vendor backport, a source build or a move to a newer release. Either way, the hard part is knowing where PHP runs inside your organisation. That gap, between a patch existing and a company knowing where to apply it, is the real story of this week.
Two flaws, one day of scrambling
On October 21 the PHP project released fixes for two flaws, CVE-2026-109618 and CVE-2026-109619. According to The Hacker News, PHP's security team scored each flaw 9.2 under version 4.0 of the CVSS severity system. Either one lets a person with no account run code on a web server.
Each supported line has a fixed release: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The Free Press Journal reports that CERT-In, India's national cyber-security agency, treats any earlier release in those four lines as affected. A leak forced the timing. Details circulated on October 20, ahead of a disclosure planned for October 22, so PHP brought its release forward by a day, The Hacker News reported. We covered the leak and the release day as they happened.
Many organisations took services offline as a precaution. The Hacker News reported that BambooHR paused its service in the United States, Canada and Ireland. Dutch broadcaster NOS reported that DigiD and MijnOverheid went down. The Free Press Journal reported that the Wikimedia Foundation took some systems offline. Security.NL later reported that many Dutch government sites were back online.
Attacks have started, but success is unproven. Cloudflare CTO Dane Knecht said the company was seeing early attacks. Tenable reported that Amazon Threat Intelligence saw an attempt on October 17, four days before disclosure. Amazon said it is unclear whether later attempts would have worked on real systems. As of The Hacker News report, no source had confirmed a successful break-in.
Why updating your application does not help
The weakness is in the engine that runs a site's code, not in any one application, as we reported on October 21. According to The Hacker News, a vulnerable PHP version is exposed even when all it serves is a simple page. Patching WordPress or Laravel leaves the PHP underneath untouched. The runtime is supplied by an operating system package, a hosting provider or a container image.
BleepingComputer says the two bugs share a root cause. When a request ends abnormally, PHP may leave its memory in a damaged state. Sansec described how this plays out. A fatal error, typically running out of memory, stops PHP before it tidies up. A later request, or a reused worker process, then treats freed memory as live data.
Sansec adds that CVE-2026-109618 can also leak memory, much like Heartbleed. The leaked data can include passwords, session tokens and API keys from other requests. PHP's advisory names Apache's mod_php module as the riskiest set-up. A demonstrated exploit there needs only one unauthenticated request, and it fires before the site's own code gets a chance to run.
AI shortened both sides of the clock
Sansec credits researchers at Wiz, Calif and OpenAI with the discovery, with the PHP security team coordinating the fix. The Free Press Journal says the flaws went unnoticed for more than ten years. Sansec places the origin of the weak code in the 2012 release, PHP 5.4.0.
The Hacker News reported the researchers' account that AI models helped turn the flaws into working exploits. By that account, one researcher finished in about a week what would normally occupy a team for months. Calif adds that knowing the code's history still mattered.
The same speed helps attackers. OpenAI acknowledged that AI "can also help attackers exploit them." The Record reported that with AI, most attackers can build a working exploit in under an hour. Detectify's Joviane Jardim expects attackers to compare old and new code once the patch is out.
The risk sits in what you have forgotten
Sophos's Don Smith said the challenge is not just installing the patch but finding every place PHP runs. It may be buried in hosting services or bought-in software that the organisation never thought of as PHP. Jardim said many firms learn about a forgotten PHP server only when an attacker finds it. He estimated that roughly half of PHP websites run older versions, while only PHP 8.2 and newer get patches.
Jardim said it is "an afternoon of updates" if you know where all your PHP runs. That holds only for servers on supported versions. The Record reports experts' concern that millions of PHP sites run ancient versions that likely cannot be updated.
The support gap is wide. The Hacker News reported that official fixes stop at PHP 8.2 and above, and that even 8.2's support window closes on December 31, 2026. The PHP team published source backports for 7.4, 8.0 and 8.1. Sansec reported that the volunteer-run Remi repository, common on RHEL-based servers, had no fix on October 21. Gina Peter Banyard, one of PHP's core developers, was blunt when someone suggested a settings change might do: "The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much," The Hacker News reported.
Questions for your team this week
Ask for a list of every system that runs PHP. Include marketing sites, hosting control panels and devices with PHP built in. Ask who owns the runtime update for each: the host, a vendor or your own team.
Split that list in two. For PHP 8.2 and newer, schedule the update. For 8.1 and older, ask the vendor for a backport, use PHP's source backports, or plan a move to a supported version. Sansec advises customers of Remi's repository to switch to their distribution's PHP packages or build from source.
Ask how each fix was confirmed. Version numbers can mislead. The Hacker News reports that vendors received the patch early, so a package may look out of date and still be fixed. Check the package changelog for the CVE, not the version string. Then restart the services that serve PHP: Apache, PHP-FPM and any workers that stay running between requests.
Then recheck memory settings. The Hacker News reports that the patch introduces a firm memory cap. A process that hits it is killed outright, and its clean-up routines are skipped. Compare memory_limit and post_max_size with what each application needs.
For systems that cannot be patched, Sophos advises isolating them from the internet. Amazon recommends starting investigations from October 17, not from the disclosure date. PHP says its interim settings reduce exposure but do not make a server safe.
The lesson is that a patch protects only the servers someone knows to patch.
Earlier WebPulse coverage: Two critical PHP flaws leaked before fixes; The PHP security fix due today won't arrive through WordPress updates; Two flaws in PHP itself affect sites on vulnerable versions, Patchstack says; AWS says an attacker probed a PHP2Shell decoy four days before the patches; Cloudflare's firewall now checks what your server replied, not just the request.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: The Record.
