If you spent the last 48 hours watching server dashboards, you probably witnessed one of the strangest scenes in modern web infrastructure. We weren’t dealing with a dodgy WordPress plugin or a misconfigured .htaccess file. The flaw sat right in the core PHP C engine itself—and before vendor patches could even reach standard package managers, governments and enterprise platforms were actively yanking network cables out of the wall.
According to reporting from Reuters and BBC News, the fallout was immediate. When the runtime powering over 70% of the web develops an unauthenticated remote execution hole, you don’t get much warning.
The Flaws: Memory Bailouts & Request Bleed
The panic centred on two paired critical vulnerabilities carrying CVSS 9.2 ratings:
- CVE-2026-109618 (Heap-Use-After-Free): A flaw in PHP’s core memory allocator. When handling malformed
multipart/form-datapayloads, an out-of-memory bailout unwound the stack vialongjmp()through half-updated engine state, leaving dangling pointers ripe for memory hijacking. - CVE-2026-109619 (Session Upload Progress Leak): Stale request globals in
session.upload_progressfailed to clear down cleanly upon engine bailout, allowing subsequent HTTP requests handled by the same worker to bleed session tokens, API keys, and memory buffers across tenant boundaries.
Crucially, because this triggered during request parsing inside the C interpreter, it hit before application authentication, input sanitation, or WordPress hooks even woke up. Standard web application firewall (WAF) regexes were completely blind to the low-level allocator state.
The Outage Roll Call: Who Pulled the Plug?
When security alerts from CISA and the UK NCSC warned that traditional perimeter firewalls couldn’t reliably stop the exploit, organisations faced an impossible choice: leave ports exposed to automated webshell loaders, or pull the plug.
The list of confirmed casualties reads like a cross-section of national critical infrastructure:
- United Kingdom (Gov.uk & DVSA): In an official statement to the House of Lords, Tech Minister Baroness Lloyd of Effra confirmed that 32 separate government digital services were intentionally severed and four were running degraded. Digital MOT test registration at the Driver and Vehicle Standards Agency (DVSA) went dark across Great Britain, forcing garages to resort to emergency manual paperwork.
- The Netherlands (DigiD & Port of Rotterdam): The Dutch national digital identity system, DigiD—relied upon by 17 million citizens for healthcare, pensions, and municipal taxes—was forced into an emergency precautionary shutdown alongside MijnOverheid. Even Europe’s largest seaport, the Port of Rotterdam, temporarily severed public-facing logistics and vessel scheduling interfaces.
- Belgium (Smartschool & Flemish Parliament): Over half a million students, parents, and teachers across Flanders were locked out of Smartschool right in the middle of the school day. The official web portal of the Flemish Parliament was taken dark in parallel.
- Healthcare & Hospital Networks: Major hospital groups across the UK (NHS Foundation Trust patient booking micro-sites) and Belgium (the ZNA/GZA hospital network in Antwerp) deactivated external web booking to protect sensitive electronic patient records from lateral movement.
- Major Web & Dev Platforms: DeviantArt forced massive sections of its community and artist galleries into emergency read-only mode to blunt upload-progress memory corruption. The Wikimedia Foundation isolated internal Phabricator development clusters from the public web, while Reddit aggressively throttled unauthenticated interactive endpoints.
The Weaponised PoC & Responsible Disclosure
The match that lit the powder keg was the release of a fully weaponised Proof of Concept (PoC) by an independent researcher paired with frontier reasoning models.
Dropping a functional exploit into the wild before vendor patches are widely compiled and distributed is undeniably irresponsible and dangerous. It handed script kiddies and opportunistic botnets an instant loaded weapon. My own sway would almost certainly have been to hold back the PoC until system administrators had a fighting chance to pull down binaries.
[Probes Detected in Honeypots] ──▶ [Public PoC Drops] ──▶ [Upstream Source Tagged] ──▶ [8-Hour Packaging Gap]
(Pre-disclosure) (Frantic Defence) (14:00 UTC) (503 Meltdown)At the same time, there is a harsh flip side to this coin. Threat actors and state-sponsored crews were already actively reverse-engineering the underlying commits; probes matching these exact allocator triggers were popping up in honeypots and perimeter logs well before the public drop.
The public PoC forced vendors to stop dragging their feet, stripped away any false sense of security, and gave defenders the exact payload mechanics needed to build emergency perimeter blocks. It was reckless, yes—but it might also have prevented weeks of silent, unmitigated zero-day exploitation under the radar.
The 8-Hour Packaging Squeeze & The PPA Meltdown
Once the flaw was public, the internet entered an agonizing waiting room. Upstream PHP maintainers adhered strictly to their scheduled 14:00 UTC release window. But as every sysadmin knows, upstream source code tarballs don’t magically patch production servers.
Linux distributions, cPanel, CloudLinux, and repository maintainers had to backport the patches across every active branch, compile binaries, run regression test suites, and stage packages. That gap lasted between 8 to 12 hours.
And when sysadmins rushed to patch, the distribution supply chain buckled. Millions of automated Ansible playbooks, CI/CD runners, and panic-stricken admins hammered Ondřej Surý’s Debian/Ubuntu repository (deb.sury.org) at the exact same minute. Launchpad edge servers were crushed under the sheer bandwidth, returning endless HTTP 503 Service Unavailable and 504 gateway timeouts.
Admins were trapped: active weaponised probes were sweeping the internet, but their package managers couldn’t fetch the fix. If you couldn’t pull the binary, taking the server offline was the only responsible option left.
Practical Mitigation: What Actually Worked While Waiting?
If you ever find yourself caught in an exploit window while package mirrors are 503ing, here is what actually works under the hood:
1. Kill Upload Progress in php.ini
For CVE-2026-109619, disabling the upload progress subsystem immediately eliminates the cross-request global leakage vector. This has been enabled by default since PHP 5.4:
; /etc/php/*/fpm/php.ini or /etc/php.ini
session.upload_progress.enabled = Off2. Block Multipart Requests at the Reverse Proxy
Setting file_uploads = Off in PHP is not enough on its own for CVE-2026-109618, because PHP’s low-level RFC parser still reads the multipart body to construct $_POST.
The true emergency shield had to happen at the web server layer (Nginx or Apache) before the request ever touched the PHP runtime:
# Emergency Nginx snippet for non-upload endpoints
if ($content_type ~* "multipart/form-data") {
return 403;
}This is precisely why platforms like DeviantArt and Reddit pushed non-essential media features into read-only mode during the height of the panic.
The Morning After: Who Still Has a Headache Today?
By Thursday morning, telemetry from The Guardian and Sky News showed automated exploit probes surging into the millions per hour across global IPv4 space. Mass-scanning botnets are actively spraying every reachable IP looking for unpatched WordPress and PHP endpoints to drop persistent backdoors.
While hyperscalers and agile teams weathered the storm, plenty of people are still nursing a massive headache today:
- MOT Garages & Test Centres: Mechanics and test centres across the UK are now dealing with a backlog of paper test certificates that have to be manually keyed into the DVSA system now that connectivity is trickling back.
- Public Sector IT Teams: Local councils, NHS booking portals, and school districts are still methodically auditing server images and log files for indicators of compromise before re-exposing them to the public internet.
- The Legacy EOL Quagmire: The biggest ongoing train wreck belongs to the millions of unmanaged websites still running unsupported PHP 7.4, 8.0, and 8.1. Because upstream
php.netprovided zero patches for end-of-life branches, organisations without commercial Extended Lifecycle Support (like TuxCare ELS) are stuck between two terrible options: perform an emergency major version upgrade that might break legacy plugins, or leave the box dark.
Thankfully, my own hosting provider over at Sysafe was right on top of it. They mapped the fleet early, deployed the patches within 7 minutes of the official release announcement, and kept actively monitoring and verifying every node right through until the backported legacy ELS packages dropped at midnight—so DanFry.net never missed a beat with zero service downtime.
If you manage your own boxes, check your package logs, ensure you’re on the latest point releases, and keep your maintenance runbooks tight. If you need a refresher on keeping your fleet current, check out my runbook on How Do I Update This OS? and our guide to Hardening Debian 12 and Ubuntu Servers.