PHP CVE-2026-109618: Why Millions of Websites Went Dark Overnight

Two critical PHP vulnerabilities disclosed on October 21, 2026 forced governments and major platforms to take their websites offline rather than risk exploitation. Tracked as CVE-2026-109618 and CVE-2026-109619 and rated CVSS 9.2, both flaws allow unauthenticated remote code execution — and with PHP powering roughly 70% of the web, the impact was unprecedented.

In this post, you’ll learn:

• What CVE-2026-109618 and CVE-2026-109619 actually do at the technical level
• Which high-profile organizations took services offline — and why shutting down was the right call
• Which PHP versions are affected and which patches fix the flaws
• The temporary mitigations if you cannot patch immediately
• How AI-assisted vulnerability research found these bugs before criminals did
• What this incident teaches about patch readiness and incident response

---

What Happened: The Day the Internet’s Foundation Cracked

On October 21, 2026, the PHP project released emergency security updates for two vulnerabilities that had been present in PHP for years. Both enable unauthenticated remote code execution — the most severe class of web vulnerability, where an attacker needs no credentials, only the ability to reach the server.

What made the day extraordinary wasn’t just the bugs. It was the response. Organizations worldwide made a deliberate, defensive choice: take the websites offline before attackers could reach them. The NSA, the Wikimedia Foundation, Nintendo, BBC program pages, and government services across France, Germany, the Netherlands, Finland, and Belgium all pulled public-facing services temporarily. For many security teams, a planned outage was a cheaper, safer bet than gambling on not being exploited in the window before patches landed.

The story broke first through Krebs on Security and The Record, with CERT-EU security advisory 2026-018 and the UK NCSC providing official guidance within hours. The BBC also covered the global outages as they happened.

The Technical Breakdown: Two Memory Bugs, One Root Cause

Both vulnerabilities live in PHP’s core request-handling lifecycle — not in a specific extension you can simply disable. That’s what makes them so dangerous: nearly every PHP deployment was exposed by default.

CVE-2026-109618: OOM Corruption During Request Initialization

The first flaw exploits PHP’s behavior when it runs out of memory while initializing request data. When out-of-memory (OOM) cleanup runs, it treats partially initialized data as valid — corrupting memory in a way an attacker can steer toward code execution. Attackers can trigger the condition simply by sending a crafted multipart/form-data upload request, something any web-facing server accepts by design.

CVE-2026-109619: Stale Global State Between Requests

The second flaw is a use-after-free condition. Internal state from a previous request persists in memory after being freed, and a later request on the same worker process can access that stale state before normal initialization resets it. Confirmed attack paths include PHP’s session upload progress handler and fatal error backtraces — features commonly enabled on shared hosting and default configurations.

A public proof-of-concept demonstrating unauthenticated RCE against both Apache mod_php and PHP-FPM surfaced quickly, with reports of in-the-wild exploitation against platforms like Magento. When a working exploit exists for the runtime layer of 70% of the web, defenders don’t get the luxury of a quiet patch window.

Who Went Offline — and Why That Was the Right Call

The list of organizations that chose downtime over exposure reads like a who’s-who of the internet:

• Government services: the US NSA, France’s info.gouv.fr, Germany’s ITZBund services, the Netherlands’ DigiD/MijnOverheid, Finnish public web services, and the Belgian foreign ministry
• Major platforms: Nintendo, BBC program pages, DeviantArt, and Wikimedia Foundation systems including Wikipedia
• Local government: Edinburgh Council among many others

To anyone who experienced one of these outages, the decision may have looked dramatic. It wasn’t. When a vulnerability allows unauthenticated code execution at the language-runtime level, every unpatched hour is an attacker’s opportunity. The math is unforgiving: a planned outage costs reputation points; a successful RCE costs data, users, and months of incident response and threat detection work.

It’s the same logic we’ve covered in how modern attack campaigns operate at machine speed — defenders who wait for certainty concede the initiative.

Affected Versions and the Fixes

The vulnerabilities affect all PHP versions below the patched releases — and the patched releases only cover supported branches. In other words: if you’re not on one of the October 21 releases, you’re vulnerable, and if you’re on an end-of-life branch (8.1 or older), there is no official fix coming. This incident is your migration deadline.

Patched versions released October 21, 2026:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Check your version with php -v, and treat anything below 8.2.35 as vulnerable. For managed hosting, verify with your provider which patch level they applied — and when. Don’t assume; providers lag.

Can’t Patch Immediately? The Temporary Mitigations

If upgrading takes days because of legacy constraints, defenders can reduce exposure — imperfectly but meaningfully:

1. Disable session upload progress: set session.upload_progress.enabled = Off in php.ini or .user.ini
2. Block multipart requests at the web server: reject requests with a Content-Type: multipart/form-data header in Nginx or Apache before they ever reach PHP — drastic, but it closes the confirmed OOM attack path
3. Disable fatal error backtraces on PHP 8.5: set fatal_error_backtraces = Off if the feature isn’t required

Be clear about what these are: they buy time, they don’t fix the bug. Anything less than the patched versions remains exploitable through paths that will continue to surface — the same reason turning threat intelligence into actionable defense matters more than one-off workarounds.

The AI Angle: How These Bugs Were Found

Perhaps the most significant part of this story is who found the bugs: Wiz Research and security researcher Ryan Austin (Calif), with assistance from OpenAI, as part of an AI-assisted vulnerability research initiative. Memory-lifecycle bugs like these have historically taken years of expert manual auditing to surface — and many never surfaced at all.

AI-assisted code review found two decade-class vulnerabilities in the world’s most widely deployed language runtime, and the disclosure led to patches before mass exploitation. That’s the defensive promise of AI in security made real — a sharp contrast to the offensive uses of AI we’ve tracked in phishing campaigns, and a preview of how AI is reshaping both red and blue team work. The skills that catch these bugs — and defend against them — are exactly the AI-era security skills the market now rewards.

The Lessons: What This Incident Should Change for You

Infrastructure-level vulnerabilities will keep happening — in runtimes, in libraries, in everything downstream. The teams that sailed through this week were the ones with the boring fundamentals already in place:

1. Know your runtime versions. If you can’t answer “what PHP version are we on, everywhere” in minutes, asset inventory is your first project.
2. Patch EOL software now, not next incident. PHP 8.1 and below had no fixes for these CVEs. End-of-life means the next bug might mean a rewrite-under-fire — a lesson in why the best defense needs offense thinking too.
3. Have a “shut it down” playbook. The organizations that acted fastest had already decided, in advance, under what conditions they’d take services offline. Making that call at 2 AM under pressure is how hesitation happens.
4. Reduce the attack surface by design. Features like session upload progress that you don’t use are pure liability — a principle at the heart of zero trust architecture.
5. Watch the official channels. CERT advisories and vendor bulletins beat social media panic every time.

Conclusion

CVE-2026-109618 and CVE-2026-109619 are a historic reminder that the web runs on infrastructure most of us never think about — and that its foundations can crack. The organizations that weathered the day best were the ones that patched fast, or accepted a controlled outage over an uncontrolled breach. That’s not luck; that’s preparation.

1. Update PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 today
2. Audit every server for EOL PHP versions and migrate them
3. Apply the temporary mitigations wherever patching is delayed
4. Write your shutdown playbook before the next runtime-level CVE
5. Subscribe to CERT and vendor advisories for your stack

The next internet-scale vulnerability is a matter of when, not whether. The difference between an outage and a breach is what you do in the first hours — and how ready you were before the advisory ever landed.