ArchiveSunday, 25 October 2026

Kate: Hello and welcome to the weekend deep dive. It's Sunday, October twenty-fifth. This week one story ate the whole security world: PHP2Shell. Two critical flaws in the core of PHP, the language running roughly seventy percent of websites with a known server-side language. There was a leaked embargo, millions of attack attempts, government sites going dark, and a surprisingly big argument about whether anyone was actually hacked. Dade, why is this worth fifteen minutes of our Sunday?

Dade: Because it's a rare story where every layer matters at once, Kate. The bug itself is serious: unauthenticated remote code execution in the interpreter, not in some plugin. But the more interesting parts are around it. How a coordinated disclosure fell apart in about a day. Why a bug that's decades old suddenly became exploitable. And the gap between "millions of attempts" and "confirmed compromises", which tells you a lot about how to read threat intelligence. For a consultant, it's also a very practical week: every client has PHP somewhere, often in places they've forgotten about. So let's go through it properly, from the timeline, to the mechanics, to what you tell a client on Monday morning.

Kate: Let's start with what happened. Walk me through the timeline.

Dade: So the story starts earlier than most people think. The PHP Foundation says signs of the underlying problem showed up back in twenty twenty-four, when a core developer was fixing something that came out of a Quarkslab audit. At that point it was theoretical. Nobody had a concrete attack, other bugs looked more urgent, and every proposed fix had a price: breaking compatibility, creating new denial-of-service risks, or forcing changes in third-party extensions. The security team couldn't agree, and only a handful of people really understand the engine at that depth. So it stalled and restarted for months. Then in August it flipped. According to the Foundation, Calif reported an unconditional remote code execution with the same root cause on August eleventh, and OpenAI independently reported the same root cause that very day. Wiz added more attack vectors. Interestingly, Wiz tells it slightly differently: they say they discovered the first bug on August nineteenth and reported on the twenty-fourth. The sources don't fully agree, probably because there were several related findings, but the broad picture is the same. From August eleventh, fixing this became the top priority.

Kate: And the plan was to publish on the twenty-second of October. What went wrong?

Dade: Pretty much everything that can go wrong with an embargo. On Tuesday the twentieth, around three in the afternoon UTC, the two CVE numbers started circulating on forums and social media. They came with the wrong release time and a made-up severity score of ten point zero. The real score is nine point two. No technical details leaked, but the cat was out. So PHP moved its pre-announcement to seven thirty that evening and pulled the release forward a day, to Wednesday. Then, around eight o'clock, Calif accidentally published a video showing their exploit working against several targets. They deleted it, but you know how the internet works, copies were everywhere within hours. And on Wednesday morning, at seven forty-one UTC, more than six hours before the agreed release, Chainguard published patched container images. The Foundation calls that unilaterally breaking the embargo, because anybody could now study the fix in binary form. Chainguard's CEO, Dan Lorenc, said he did it because exploits were already hitting in the wild, and he later apologized for the stress it caused the maintainers.

Kate: Okay, so now the part I think people find hardest. How do these bugs actually work?

Dade: Let me use an analogy. Imagine a restaurant kitchen where every order, every request, gets its own tray of ingredients, and the cleaning crew wipes the tray when the order is done. The first bug, CVE twenty twenty-six, one oh nine six one eight, is about what happens when the kitchen runs out of counter space halfway through setting up the tray. PHP handles running out of memory with a jump, a function called longjmp, that abandons what it was doing immediately. The problem is that the tray is only half set up. Some things are initialized, some are garbage. And then the cleanup code comes along and trusts the contents of that tray, working on invalid data. If an attacker controls how the memory got exhausted, say with heavy multipart requests, they can influence what that garbage looks like, and that can turn into code execution. And in the setup PHP rates as the highest risk, Apache with mod_php, this happens before any application code even runs. So it doesn't matter how clean your WordPress plugin is. The second one, one oh nine six one nine, is the stale state bug. Same kitchen, different failure. A PHP worker handles many requests in a row, one after another. Some internal state from the previous request can survive after the memory behind it has been freed, so a pointer is left pointing at something that no longer exists. When the next request arrives, PHP uses that leftover state before its normal initialization has reset it. PHP has confirmed paths through the session upload progress feature, and on PHP eight point five through the backtrace you get with fatal errors, but it's explicit that those aren't the only ones. That matters later, because the quick workaround of switching off upload progress only closes the confirmed session routes. Not every variant. And the attacker controls the whole request, so there's no need for a real upload form or a login. Both flaws have been in the code for a very long time. The vulnerable code goes back to PHP five point four, from twenty twelve.

Kate: So if it's that bad, why did the headlines say hardly anyone was actually compromised? I want to understand that gap.

Dade: Good question, and it comes down to a protection called ASLR, address space layout randomization. Think of it as shuffling the furniture in the building every time it opens. A memory-corruption exploit needs to know where things are, and if the addresses are randomized, a blind attacker mostly just crashes the worker. So a real exploit needs two steps: first leak an address, then use it. That's why Mandiant's CTO, Charles Carmakal, said many of the public proof-of-concepts look vibe-coded, meaning they can't run code at all. He did say they validated some that do achieve remote code execution against default mod_php deployments, though not against PHP-FPM. VulnCheck has seen hundreds of PoC repositories on GitHub and says very few contain a legitimate working exploit. Then it got interesting. Overnight on Thursday, VulnCheck built what they believe is the first exploit that defeats ASLR on x86-64, chaining the two bugs together with a memory leak, on PHP eight point four point twenty-six, with the recommended production setting where errors aren't displayed. They kept it for their customers. And SOCRadar found an attacker's open server holding a script that does something similar: recycle the worker, leak addresses through the session cookie, then abuse upload progress to run a shell command. VulnCheck's own words were that adversaries are clearly spending time, and tokens, on this bug. And the researcher who said that also added something I'd put on a slide: the technical difficulty of exploiting a vulnerability shouldn't be confused with protection against it.

Kate: Let's widen the lens. There's an AI angle here too, isn't there? Wiz said something striking.

Dade: They did. Wiz said the flaws had been present for decades, but demonstrating they were exploitable took an exceptionally complex chain of steps, at the edge of what human researchers could practically do, and that frontier AI models substantially reduced that barrier. A timeline Wiz published mentions their own tooling plus two frontier models in the discovery. OpenAI was involved in the research and outreach as well, and said it considers this one of the most impactful security issues in recent memory. Now, I want to be careful. Another analysis points out the AI claim is not independently verified, and the official PHP announcement doesn't confirm it. So I'd treat it as the researchers' account, not an established fact. But even with that caveat, it fits a trend we've talked about all year: AI doesn't need to invent new bug classes. It just makes the old, laborious, expert-only work of turning a theoretical memory bug into a working exploit cheaper. And it works for defenders and attackers alike. Chainguard's CEO, by the way, said they also independently found the issue using their test harness and a frontier model, after an initial warning. And honestly, the part I find most uncomfortable is the maintainers. The PHP Foundation wrote that the delay was, quote, a structural failure, caused by the security team's decision process and its lack of resources. Since the first of July they've published fifteen CVEs, and they've also dealt with more than a hundred reports that were invalid, duplicates, or not reproducible. AI tools help validate findings, but a human still has to choose the fix, implement it and review it. So the Foundation is moving to majority decisions so hard fixes don't wait forever for consensus, and it's asking companies, hosters, cloud platforms and governments to fund more engineers with deep engine knowledge. When seventy percent of the web depends on a handful of people, that's a funding problem, not just a technical one. It's the same pattern as Log4Shell in twenty twenty-one, and Wiz explicitly makes that comparison.

Kate: Okay, so, practical. Who's exposed, and what does a consultant tell clients on Monday?

Dade: Start with scale, because it's huge. Censys counted about three million hosts and fifty-six point six million web properties running PHP, and as of Friday, over thirty-four million PHP services still looked vulnerable. VirusTotal estimates only around two hundred and seventy-two thousand hosts run a supported branch, eight point two to eight point five. The fixed versions are eight point five point twelve, eight point four point twenty-seven, eight point three point thirty-six and eight point two point thirty-five. And here's where it gets messy. For seven point four, eight point zero and eight point one, PHP only published minimal source backports, no official releases. So you either get a backported package from your distribution or vendor, rebuild from the source, or upgrade. For older branches like five point x, the project announced nothing, so those need an upgrade or isolation. One scan counted around eight hundred and eighty-four thousand internet-facing hosts reporting PHP eight point one or older. And the operational fallout was real even without confirmed hacks. The U.K. government said thirty-two digital services were unavailable and four partially, mostly from precautionary shutdowns while patching, and the NCSC sent roughly fifty thousand warnings. Underneath all of that, it's an inventory problem. There's a trap I'd flag: a version check on an admin's workstation can show a patched build, while the PHP-FPM pool that actually serves production runs a different, vulnerable binary. So check what each site really executes. Then think about the places that get forgotten: hosting panels and shared hosting with many PHP versions side by side, vendor appliances that bundle PHP, Windows software shipping php-cgi, old intranet dashboards. For detection, Picus gives a useful list. Watch for bursts of worker crashes in the logs, memory errors that say "Unknown on line zero", huge or deeply nested multipart requests, and the session upload progress parameter sent to endpoints that never use it. Most importantly, watch what PHP processes spawn. A web worker launching a shell, curl, wget, or something that looks like a reverse shell, is a very loud signal. Baseline it first, because some legitimate tools like image converters also get launched. And remember the interim hardening: limits on request size, field counts, multipart parts. They reduce exposure, but PHP is clear that only updating is a complete fix.

Kate: I'll push back a bit. Cloudflare saw millions of attempts. Amazon saw one days before disclosure. That sounds like a catastrophe. Is it?

Dade: It sounds like one, but you have to read the word "exploitation" carefully. Cloudflare saw tens of thousands of attempts within forty-five minutes of the announcement, climbing to millions by early Thursday. Amazon reported an attempt on October seventeenth, four days before disclosure. But Sophos published and then retracted a report of successful exploitation, saying it only saw a small number of failed attempts. Google's John Hultquist said they've validated no exploitation in the wild and have no evidence of wide-scale success, although he warned it may have begun in a limited fashion. The PHP Foundation said it has no evidence of successful exploitation before disclosure, or on patched versions. Marcus Hutchins made a useful distinction: some vendors are describing sophisticated, perhaps state-backed actors doing targeted exploitation, while others are simply counting mass attempts with PoCs that don't work. His own evidence matches the second case. The Mirai story fits: Sophos and Arctic Wolf saw attempts to install a botnet variant called Potassium, with a command server and flood attacks aimed at two hosts in a Ukrainian network, but with no success. Hunt.io tested one attacker's list of one hundred twenty-three servers, and none were exploited. So: lots of noise, no confirmed mass compromise yet. But Hutchins also had a warning that I'd give clients. Someone has built a scanner that can remotely identify vulnerable systems, so internet-wide scanning is going on right now. His point was that if a fully weaponized exploit appears, several actors probably already have target lists of reachable unpatched systems ready to go. Cobalt's CISO called this quiet period borrowed time, and said that once a working technique moves from specialist tooling into botnet playbooks, defenders will have days, not weeks, to catch up. So the lack of compromises is not reassurance. It's a window. Then there's the third bug that showed up on Friday, CVE twenty twenty-six, one one five five six zero. The PHP Foundation reserved it for a third remote code execution flaw, but it says it needs a very unlikely combination of configuration and application code. Specifically, an application that sets the session serialize handler to one thing and then switches it to the php handler at runtime, with session upload progress enabled. The Foundation says it doesn't expect this to occur in practice, so no emergency patch. Instead, an informational advisory and a fix in the next regular release, with a mitigation: set session upload progress enabled to zero. And one nuance: that same setting is the partial workaround for the second PHP2Shell bug, so if you've already applied it, you're covered for this one too. But remember, it doesn't cover all variants of the second bug, so it's no substitute for patching.

Kate: So what do we watch in the coming weeks?

Dade: Four things. One, whether a reliable exploit for production-style, ASLR-enabled systems becomes publicly available. VulnCheck has one, an attacker toolkit exists, and the day it lands in a botnet, the clock accelerates. Two, the long tail: unpatched seven point x and eight point one systems, and PHP hidden inside appliances and control panels that get updates slowly or never. Three, the next regular PHP release, which should close the third CVE, plus whatever other variants researchers find, since PHP itself said the confirmed paths aren't the only ones. And four, the governance fallout. Chainguard breaking the embargo has people asking whether projects will trust distributors with embargoed patches again, and whether the companies that depend on PHP will fund it. If I had to give one sentence to a client: patch the supported branches now, plan upgrades for the old ones, and look for PHP in the places you didn't think to look. Don't wait for confirmed breaches, because by the time those are confirmed, you're already late.

Kate: That's a very clear checklist. Thanks, Dade. And thanks to everyone for listening. Enjoy the rest of your weekend, and we'll be back with the daily briefing tomorrow morning. Take care.