On Tuesday, PHP announced a critical security release for Wednesday at 14:00 UTC. Two vulnerabilities, both rated CVSS 9.2. Details, affected versions and fixed versions would follow with the release.
Overnight a proof of concept appeared. A heap use-after-free in session.upload_progress, marked "status: weaponized (lab)", with one line that would worry anyone running PHP: "Stock configuration is enough."
By Wednesday morning its author had corrected it: that chain was "DEAD", with "no RCE, CVSS 0.0". What remained was a medium-severity bug, "NOT code execution". A few hours later PHP's own advisory confirmed remote code execution through upload progress anyway, along a route of its own.
The pre-announcement exists to give you a head start. This week the race started the moment it was published, before anyone had seen a patch.
The advisories went up on Wednesday at 13:34 UTC: CVE-2026-109618 and CVE-2026-109619, both critical, fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Every older release in those branches is affected. The second one covers the session.upload_progress path the PoC went after.
The patch is a roadmap
Patch-diffing is old. You take the fixed version, diff it against the vulnerable one, and the change points straight at the bug. It used to take a skilled person days or weeks to turn that diff into something that fires.
In June, Anthropic measured what that costs with a current model. Their phrasing is blunt: "the patch itself provides a roadmap to the bug." Working from Firefox security patches, the model "built 8 working code-execution exploits autonomously." On Windows, "Mythos Preview's first PoC arrived in 31 minutes and all 18 arrived within six hours."
That is a vendor measuring its own model, and I have been sceptical of exactly that before. But the conclusion does not need the vendor to be generous. Their own summary is that "N-hour is closer to the reality we now operate in", and the people who maintain the software agree, because this week they changed their policies over it.
Two projects, two opposite answers
On Tuesday night Tom Ritter wrote to Firefox developers on behalf of the security team: "As AI keeps improving, our security policies are changing in response." Fixes for sec-high and sec-moderate bugs now land without their tests. The test, which describes the bug in the most precise form there is, lands no sooner than a week after the fixed Firefox ships.
The same day Daniel Stenberg announced the opposite for curl. From 26 October, every vulnerability rated LOW or MEDIUM goes to a public GitHub issue. Only HIGH and CRITICAL stay private.
His reason: "This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in", many of them "figured out by AI models". Over the last few years more than 90% of submissions turned out to be below HIGH, and curl does not have "the bandwidth, manpower or even will" to keep handling all of them under embargo.
Firefox hides, curl publishes. Both projects defend against the same shift, and each defends the resource it is shortest on:
| Project | Scarce resource | What AI made cheap | Response |
|---|---|---|---|
| Firefox | time between fix and use | turning a patch into abuse | hide the test for a week |
| curl | maintainer attention | producing a report | stop treating minor bugs as secrets |
Firefox can afford a week of secrecy because it ships on a fixed release train with automatic updates, so most users have the fix before the test appears. curl cannot afford the embargo ceremony for a stream of reports that are mostly low severity. Both choices are rational. Neither does anything for you.
What the panic skips
Cheap exploits do not mean mass exploitation, and the data says so.
VulnCheck's first-half 2026 report looks at 1,061 vulnerabilities attributed to AI-assisted discovery, and "only 14, or 1.3%, have been confirmed as exploited in the wild." VulnCheck notes that this roughly matches the overall exploitation rate. Bugs a model finds get used about as often as any other bug, which is to say rarely. The avalanche curl is drowning in consists of reports, and the PHP PoC is a small example of one: a confident "weaponized", withdrawn by its own author within hours.
The same report has the other number, though: "23.43% of KEVs showed evidence of exploitation on or before the day the CVE was published." That is down from 28.93% in 2025, so the line does not only go one way. Still, almost a quarter of the vulnerabilities that do get exploited are used on day zero or earlier. For those, "patch within thirty days" is a ritual and protects nothing.
So the risk did not spread evenly. Most bugs stay quiet. The few that matter, a remote bug in a default configuration of software that runs a large part of the web, now go from announcement to working exploit in hours. That is the bucket PHP's release falls into: the first exploit attempt came within hours of the announcement, before there was a patch to read, and now the patches are public.
Nobody was driving the intrusion Sysdig caught in May, and it got in through a CVE that already had a patch. The window between a published patch and an intrusion like that one is what is shrinking.
What I actually do with that
The projects are adjusting their disclosure. The window that remains is yours: the time between a fix being public and it running on your server.
- Measure your own patch-to-production time. Take the last three security updates you shipped and look at when the fix was published and when it was live. If the answer is a week, that week now belongs to someone else.
- Have an emergency path that skips the sprint. A security fix should not queue behind a feature branch, a release train or a review slot. Decide in advance who can ship one on a Wednesday afternoon, and how. Your pipeline is the bottleneck for features, and it is the bottleneck here too.
- Treat a pre-announcement as the start of the incident. PHP gave about seventeen hours' notice. Use it to find every PHP host, check which version and which package source it runs, and have the update ready to roll. When the release lands, the only step left is the deploy.
- Know the mitigation that does not need the patch, and where it stops. The confirmed session route goes through upload progress, which PHP enables by default. According to the advisory,
session.upload_progress.enabled=0"prevents the demonstrated early session producing and consuming operations", but "does not mitigate the other lifecycle paths", and there is "no complete generic configuration mitigation". A config flag buys you hours. The update closes the hole. - Know whose clock you run on. If PHP comes from your distribution, the fix reaches you when the distribution packages it. That delay is part of your window, and it is worth knowing how long it usually is before a day like this.
None of this is new advice. Patch fast, know your inventory, have a fast path. What changed is the price of ignoring it: a week of patch latency used to cost a small risk, and it now costs the time an attacker needs to read a diff with a model.
PHP's release went out on Wednesday afternoon. The first exploit claim arrived before it, and this time it was wrong. The only number in this story you control is how long your server runs the old version after that.