Two Vulnerabilities That Touched Everything

Both flaws lived in code paths nearly every PHP request touches: memory management and error handling.

CVE-2026-109618 was an out-of-memory corruption issue. If a request hit PHP’s memory_limit at precisely the wrong moment, the engine left partially initialized internal data behind and later treated it as valid. On Apache with mod_php, an unauthenticated request could trigger this before any application code ran. Full remote code execution was demonstrated with default settings.

CVE-2026-109619 was a stale global state problem. A fatal error at the wrong point could leave internal state pointing to memory from a previous request. A later request handled by the same worker could then use that freed memory, a classic use-after-free that researchers turned into a working RCE against a real-world application.

Both carry CVSS v4.0 scores of 9.2. And here’s the part that should make you uneasy: researchers also demonstrated unauthenticated disclosure of PHP worker memory. That leaked memory can contain passwords, authentication tokens, and API keys.

The Structural Failure Nobody Wanted to Admit

Here’s where the story gets uncomfortable. The PHP Foundation doesn’t sugarcoat it: the root cause behind CVE-2026-109618 was identified in 2024, during the first external security audit PHP had undergone in years (funded by Germany’s Sovereign Tech Agency and carried out by Quarkslab).

A potential exploit path was theorized. But no concrete attack vectors were found, other issues with clearer impact took priority, and the security team, operating on consensus, got stuck.

“We won’t pretend otherwise: the delay was a structural failure, caused by both the security team’s decision process and its lack of resources.”

That’s a refreshingly honest admission from an open source project. But it also exposes the uncomfortable truth about legacy infrastructure: the most dangerous vulnerabilities aren’t the ones you don’t know about. They’re the ones you know about but can’t afford to fix.

When AI Changes the Threat Calculus

The 2024 audit couldn’t find a concrete exploit path. By August 2026, three organizations independently did, on the same day.

On August 11th, researcher Ryan A at security firm Calif reported an unconditional remote code execution with the same root cause. OpenAI independently reported the same root cause that same day. Wiz followed with additional attack vectors on August 24th, and OpenAI added more on September 18th.

The difference? AI-assisted vulnerability research has fundamentally changed the economics of finding exploitable bugs. What took human researchers months of painstaking manual analysis in 2024, AI tools can now surface in days. The PHP team has fully embraced this shift: they’ve added OpenAI’s Daybreak Red for validating reports and exploits, worked with Alpha-Omega to scan PHP with Anthropic’s Claude Mythos, and built sanitizer builds and reproduction environments matching their CI on every supported platform.

This cuts both ways. The PHP security team has published 15 CVEs since July 1st and worked through more than 100 invalid or duplicate reports. AI helps triage and group reports by root cause, but a person still makes every call and works on every patch.

The uncomfortable implication for the broader supply chain security risks in widely used software dependencies: attackers now have the same AI advantages as defenders. The asymmetry isn’t in finding bugs anymore, it’s in having the organizational capacity to fix them.

The Chainguard Embargo Breach: A Case Study in Coordination Failure

The coordinated disclosure was working. Until it wasn’t.

On Tuesday, October 20th, around 15:00 UTC, the two CVE IDs started circulating on forums and social media with a wrong release time and a wrong CVSS score (10.0 instead of the actual 9.2). No technical details leaked initially. The PHP project moved its pre-announcement forward and shifted the release from October 22nd to October 21st, a compromise between urgency and giving distributors time to package fixes.

Then, at 07:41 UTC on October 21st, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix.

The first actual in-the-wild exploit appeared 55 minutes later.

Was Chainguard responsible? The PHP Foundation says its security team closely monitored appearing PoCs and found no functional exploits before the coordinated disclosure. Meanwhile, Chainguard claimed exploits were already circulating. The community response was visceral, calls to remove Chainguard from all coordination lists, boycotts, and accusations that the company endangered half the internet to sell its security services. One developer described taking their website down entirely after PoCs started circulating, only to receive a sales pitch from Chainguard affiliates via their public support form.

This isn’t just drama. It’s a structural problem for open source security: when vendors receive patches early to protect their users, they become part of the trust boundary. Breaking that trust has consequences that extend far beyond a single release cycle. The lesson for any organization involved in coordinated disclosures: the embargo isn’t a suggestion, and the cost of being wrong is measured in exploited production systems.

Professionalizing Security Before It’s Too Late

The PHP Foundation’s response to all this is genuinely encouraging, which is not a sentence I expected to write about a 30-year-old scripting language.

In May 2026, the Foundation created the Ecosystem Security Team to work alongside the existing PHP security team on triage, coordination, and hardening. They’ve hired dedicated security personnel, Alexandre Daubois for triage and Daniel Scherzer for hardening work. Volker Dusch serves as AI Security Engineer in Residence, focused on communication and collaboration between the security team and the Foundation.

The security team has also changed its decision-making process. Instead of requiring consensus, which caused the OOM fix to stall for two years, decisions can now be made by majority, with compromises encouraged. The Foundation leadership can now steer complex vulnerability responses toward timely resolution.

The project got into OpenAI’s Patch the Planet program, with security firm Calif beginning an audit on July 30th, 2026. Trail of Bits has also been auditing PHP. The German Sovereign Tech Agency’s funding of the 2024 audit demonstrated that public investment in open source security can work, but the Foundation makes it clear that sustained funding is needed, not one-off grants.

This is the broader lesson for legacy modernization: the threat landscape has changed faster than organizational structures can adapt. PHP’s evolution from patch-reactive to proactive hardening mirrors what enterprises face daily with their own legacy systems. The question isn’t whether you’ll face critical vulnerabilities, it’s whether you have the proactive security hardening and automated trust infrastructure in place to respond.

What This Means for Your PHP Strategy

If you’re running PHP in production, this incident is a forcing function for several decisions you’ve probably been postponing:

1. Unsupported PHP versions are a liability you can’t insure against. PHP 8.1 and earlier no longer receive updates from the PHP project. The security team provided minimal source backports for 7.4, 8.0, and 8.1, but that’s a stopgap, not a strategy. PHP 8.2’s EOL is December 31, 2026. The mod-php vs FPM decision matters less than being on a supported branch with a credible upgrade path.
2. Mitigations buy time, not safety. Qualys published detailed temporary mitigations for both CVEs: setting memory_limit=-1 via php_admin_value, disabling session.upload_progress, limiting post_max_size, and configuring pm.max_requests=1 for FPM. These reduce exposure. They don’t make unpatched installations safe. The only complete fix is updating.
3. You need visibility into every PHP installation. Multiple PHP copies on the same asset is the norm, not the exception. The version returned by php -v may belong to a different installation from the one serving web requests. If you can’t inventory your PHP runtimes across containers, hosting panels, and bundled applications, you can’t patch them all.
4. The AI security era demands professional response capacity. The PHP Foundation’s experience shows that AI tools find vulnerabilities faster than consensus-driven volunteer teams can fix them. Your organization needs the same lesson: security can’t be a side project. It requires dedicated, funded teams with decision-making authority, and the ability to move quickly when researchers drop zero-days in your lap.

The deeper insight here is about how legacy systems survive in the AI era. PHP isn’t going away, it still runs a massive share of the web, including government services, banks, and ecommerce platforms. But its continued viability depends on organizational modernization as much as technical modernization. The PHP Foundation is building a sustainable security organization, not because it’s fashionable, but because the alternative is watching the internet’s most widely deployed web language become a permanent attack surface.

On the security implications of closed vs. open AI models in isolated environments, there’s a parallel worth noting: the AI tools that found these PHP vulnerabilities were proprietary systems from Anthropic, OpenAI, and their partners. As AI-assisted security research becomes standard, access to frontier models becomes a security capability in itself. That’s a conversation we should be having more loudly.

The PHP Foundation’s post ends with a straightforward ask: companies that depend on PHP should sponsor the Foundation, hosting providers and governments should fund security work on a sustained basis. After reading the full account of what happened, the two-year stall, the coordinated response, the embargo breach, the around-the-clock work to ship fixes across all supported branches, that request doesn’t feel like begging. It feels like a bill coming due.

Your legacy PHP application might still be working. But as the ISHIR modernization guide notes, an application can remain operational long after it becomes expensive, difficult to secure, and increasingly risky to change. The question isn’t whether PHP is old, it’s whether your architecture is preventing your business from moving forward.

With PHP 8.2 hitting EOL, the legacy modernization decision becomes concrete: upgrade, migrate, or accept the risk. The PHP Foundation has shown it can harden the core when properly resourced. Whether the ecosystem will pay for that security is the open question, and the answer will determine whether the next critical PHP vulnerability is a managed incident or another internet-wide scramble.

Update your PHP. Fund the Foundation if you can. And maybe reconsider that weekend of “urgent maintenance” you just went through, because if the tooling and processes don’t improve, that weekend is going to become a regular occurrence.