The biggest security story of the month is also the most confused one. It has a nickname by now, “Black October,” which tells you more about the mood than the facts. Here’s what actually happened, what’s confirmed, what isn’t, and what you personally need to do, which is less than the headlines suggest.
The story in five sentences
On October 21, 2026, the PHP programming language shipped emergency patches for two flaws that could let a stranger take over a web server without any password. Attackers started probing servers before the fixes were even released, and one security company counted millions of attempts in a few days. Governments took websites offline as a precaution, and the mainstream press covered it like the end of the internet. Meanwhile, the US cyber security agency, CISA, wrote one quiet sentence that most coverage left out: as of October 23, it had not observed successful exploitation of either flaw in the wild. The bugs are genuinely serious, the confirmed damage so far is close to zero, and the honest story is in between.
If you only read one paragraph, that was it. The rest is the detail behind each claim and a short guide to what to do.
First: what is “Black October”?
The name stuck this week. Nobody coined it deliberately; by Saturday the Guardian and 404 Media ran it in headlines. It bundles the PHP disclosures with a cluster of other October incidents, an Indian certificate authority, Node.js, GitLab, Plex, a cloud provider, into a single thesis: AI has changed the pace at which dangerous bugs get found, and the industry is not ready.
The name spread on what executives said more than on what happened. Sam Altman, quoted by the Guardian on Friday:
“I no longer think we’re going to be able to patch all bugs.”
Anthropic’s deputy chief information security officer, Jason Clinton, predicted a “vulnerability tsunami” with “not enough time to patch critical infrastructure.” Salesforce’s Marc Benioff called it a “code red.” Cloudflare’s Matthew Prince:
“It’s going to feel like the sky is falling.”
Notice the tense. Every one of those sentences describes next month. This week’s verified damage record, laid out below, still has close to zero confirmed victims. Black October is a forecast that got introduced as an event. The forecast deserves real attention. The event deserves verification. That distinction is most of this article.
What is PHP and why should anyone care?
PHP is a programming language that runs behind the scenes of an enormous share of the web. By one widely cited industry measurement, roughly seven in ten websites whose technology is visible disclose using it. It powers WordPress, which by the same class of measurement builds about four in ten websites, plus Drupal, Joomla, and plenty of custom business software. You have almost certainly submitted a form to a PHP page this week without knowing it.
A useful way to picture it: if a website is a storefront, PHP is the electricity and plumbing in the walls. Normally you never think about either. But when a fault is found in the wiring code itself, it doesn’t affect one store. It affects every building wired that way, everywhere, until someone fixes each one.
That is why two flaws in PHP, announced on a Wednesday, ended up on the front pages by Friday. This was not one company’s data breach. It was a defect in shared infrastructure.
What the bugs actually do, without the jargon
Every time a visitor opens a PHP page, the server does a small routine: it wakes up, handles the request, cleans up, and waits for the next visitor. Both flaws are mistakes in that routine, in the parts that have existed, in one form or another, for most of PHP’s modern life. The PHP Foundation, which funds the language’s development, says the issues trace back to architecture decisions made more than a decade ago.
The first flaw behaves like a fire drill gone wrong. When a server runs out of memory, PHP aborts the current request and skips to the cleanup phase. Researchers found ways to trigger that panic at the exact moment some internal setup was half finished, leaving behind a confused state that the cleanup step then acts on. With a carefully crafted sequence of ordinary-looking requests, an attacker can turn that confusion into running their own code on the server.
The second flaw is a forgotten sticky note. The server keeps some working notes between one visitor’s request and the next, and they’re supposed to be erased and rewritten every time. Under certain conditions, an old note survives pointing at memory that’s been given back and reassigned. The next request reads the stale note and follows instructions about something that isn’t there anymore. Crafted carefully, that also lands an attacker in control.
The serious part is where these bugs live. They are not in one website’s code; a perfectly built site on a vulnerable PHP installation is still exposed. They can be reached from outside, over the ordinary web, without logging in. And PHP’s own security team demonstrated full server takeover on one common server configuration with nothing changed from its defaults, and confirmed code execution on the modern standard configuration through specific application-level paths. PHP scored both flaws 9.2 out of 10. The US government’s vulnerability database scored them 9.8 and 8.1 under its older scale. These are among the highest ratings software regularly receives.
Millions of attacks is not the same as millions of victims
This is where most of the confusion lives, so it deserves the slow version.
A request is an attempt. When Cloudflare, which sits in front of a large slice of the internet and blocks bad traffic for its customers, reports “millions of attacks,” it is counting attempts its system stopped. That is the digital equivalent of people jiggling car door handles across a huge parking lot. Jiggling handles is not a stolen car.
Here is the confirmed record, from primary sources, as of October 24:
- Cloudflare’s CEO reported thousands of exploitation attempts in the ten hours before the public announcement, tens of thousands within 45 minutes of it, hundreds of thousands within two hours, and millions accumulating after that.
- Amazon’s honeypot network (servers planted purely to attract and record attackers) logged someone trying the exploit on October 17, four days before the patch existed and three days before the release was even announced. Someone had the details early.
- CISA published an alert on October 21 urging immediate patching, and added detection rules on October 23. The same alert states that CISA had not observed successful exploitation in the wild as of that revision.
- Neither flaw appears in CISA’s Known Exploited Vulnerabilities catalog, the list the US government maintains of bugs with confirmed real-world exploitation. Absence there is not proof of nothing, but it is the closest thing the industry has to a “verified breach” stamp, and right now neither bug carries it.
- The UK government told Parliament on October 22 that 32 government services were unavailable and four partially unavailable, describing this as largely precautionary, with no confirmed compromise. Agencies switched themselves off while patching. That is the responsible response to an unpatched dangerous bug, not evidence of a loss.
- Banking trade press reported no early damage to financial institutions.
So: demonstrated, yes. Attempted at scale, absolutely. A documented, confirmed compromise of a real victim that a neutral authority has validated, not yet, by the public record.
None of this minimizes the bugs. Unauthenticated remote code execution is the big one. It means the correct sentence right now is: a serious flaw under active, mass attack, with defenses so far ahead of the attackers, and that balance can change.
Why the coverage was so loud anyway
A few honest reasons, none of them sinister, all of them worth knowing about.
- The discovery story is a marketing story too. The flaws were found this summer by researchers using OpenAI models (part of an OpenAI program called Patch the Planet) and independently by Wiz Research, with frontier AI models doing much of the heavy analysis. That is genuinely newsworthy. It also serves the commercial interests of exactly the parties telling it, which is why phrases like “a turning point for the AI era” and comparisons to Heartbleed and Log4Shell appear in coverage. Those comparisons are the discoverers’ framing, not a neutral verdict. Skepticism about marketing framing is not skepticism about the bugs; the bug reports themselves check out against PHP’s own advisories.
- “Threat” and “damage” collapse into each other in a 24-hour news cycle. Attack attempts are countable and photogenic. The absence of confirmed victims is a paragraph nobody screenshots. The counting itself is noisy: Patchstack, the security coordinator for the largest PHP ecosystem, recorded 11,334 “new vulnerabilities” in the WordPress world in 2025 and judged only about a third of them an actual threat, with just six in WordPress core, all low priority. Vulnerability counts reward volume, not danger. The executives’ forecasts quoted above get cited as though they described last week, when they described the months ahead.
- Old and adjacent stories blur together. In the past six months alone there have been at least three genuinely separate incidents: an exploited flaw chain in WordPress core that CISA confirmed and catalogued in July, nicknamed wp2shell; an April authentication failure in cPanel, the control panel behind much of shared hosting, which did involve ransomware; and now this PHP one. The nicknames were chosen for memorability, not clarity. PHP2Shell, wp2shell, and WP2 (a product name, related to neither story) sound like one ongoing PHP catastrophe. They are not. Readers absorb a single undifferentiated “PHP horror stack” and cannot separate the verified from the recycled. Treat any PHP scare headline with a fuzzy pedigree as unverified until you can match it to a CVE number.
There’s also a structural reason for low trust in vulnerability claims generally. In July 2026, JFrog researchers exposed a GitHub repository that had pushed more than fifty fabricated CVEs, apparently written wholesale by AI chatbots. Six of them claimed critical SQLite flaws citing functions that don’t exist in the code, and one collected a perfect 10.0 severity score from a reputable rater before anyone checked. MITRE, which issues the numbers, rejected the entire batch, saying the system “operates on the honor system.” That’s why any PHP scare headline deserves a two-second check against the CVE number and the source. This story survives that check. Many don’t.
What genuinely does deserve attention
Two things in this story are more important than the panic or the reassurance.
- The long tail of unpatchable software. Fixes exist only for versions 8.2 and newer, released in the last few years. The PHP project publishes nothing more for older branches; a handful of large hosting companies maintain their own emergency patches for some of them, so ask your host rather than assume, but the default answer for old versions is no fix. WordPress’s own statistics page puts roughly a third of WordPress sites on PHP versions that are “end of life,” most of them on PHP 7.4, retired in 2022. A security vendor’s scan claims roughly 2.24 million directly reachable PHP hosts, most on those dead versions. Treat that as the vendor’s own estimate, unaudited. But the shape is right, and this is the quiet problem in every major bug: the first week is dramatic, and the months after are attrition against software that structurally cannot be fixed. EOL software behind a good firewall or a content-delivery network is a manageable risk. EOL software sitting directly on the open internet is where the eventual damage will concentrate.
- The barrier to attack is falling fast. The first working exploits required unusual conditions, and a defensive feature called ASLR (which randomizes a program’s memory layout) was considered a major barrier on hardened servers. Days after disclosure, the security firm VulnCheck announced an exploit that defeats it, sold privately to its subscribers. Attackers were also seen mutating their payloads in flight to dodge web firewall rules, apparently learning from what got blocked. This is a bug whose “difficulty” rating is depreciating weekly. What is unexploitable today, with a niche configuration, is a script-kiddie tool in a few months. If your response is “it hasn’t been exploited yet,” you are making a bet against that trend.
One smaller wrinkle: a third related flaw, published October 23 and tracked as CVE-2026-115560, will not get an emergency fix. PHP’s position is that it requires a configuration combination unlikely to occur in practice, and it can be closed with a settings change today. Reasonable triage, but it’s a reminder that the advisory list may not be finished.
The AI angle, honestly
The part of this story most worth keeping, stripped of press-release gloss, is simple and cuts both ways.
Defenders got there first. AI models spent the summer finding a flaw that had hidden in one of the web’s most-used languages for over a decade. By the time details leaked, Cloudflare’s protections were live about nine hours ahead of public disclosure, patches were tested, and government alerts were drafted. That sequence, called a “defender’s window” by OpenAI, is the good case: AI finds the bug, defenders get a head start, the public is mostly protected by the time the exploit spreads.
But everything that helped defenders helps attackers once it’s public. The same kind of tooling is being used to mutate payloads and hunt adjacent bugs; one researcher said attackers were clearly “spending time and tokens” on it. The realistic reading is not that AI makes software suddenly unsafe. Old code has always had these bugs; what’s changing is how quickly someone proves them exploitable, which shrinks your reaction time from months to days. For anyone who runs software, the practical implication is one habit: update fast, and prefer systems that update themselves.
What to do, by who you are
- If you just use the internet: nothing. This bug does not put visitors at risk of visiting a website. No browser update is involved. Bank accounts are not draining because you read a news article.
- If you have a website (WordPress, an agency-built site, anything): ask whoever built or hosts it one question: “what version of PHP is my site running, and is it patched for PHP2Shell?” The correct answer is a version number of 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer, or a named plan with a date. “We’ll get to it” is the answer to escalate. If you’re on shared hosting and can’t choose, confirm you’re behind Cloudflare or an equivalent, which covers most attempts at the default settings, and push your host on the EOL question.
- If you run a business that uses vendor software: the same question, one level up, plus a second: “is anything you run for us on a PHP version that no longer receives security updates?” That second question is the one vendors hate and the one that protects you in the next five years.
- If you’re technical: patch, disable session upload progress if you can’t patch today, check which SAPI you actually run, and watch for a KEV addition, which would mean confirmed exploitation and turn this from a fire drill into a known fire.
What plainworks will be watching
Three signals will tell us which history this becomes.
- If the KEV catalog adds these CVEs, the “no confirmed compromise” sentence has aged out and we’re in a real incident.
- If reports of successful intrusions arrive from neutrally verifiable sources (hosting providers publishing cleaned forensic write-ups, ransomware gangs advertising PHP2Shell initial access), the scale question answers itself.
- And if quiet attrition on EOL hosts produces worm-like spread the way older PHP eras did, the long tail is confirmed as the real story.
If none of those happen in a month, we’ll have gotten a free preview of how AI-era vulnerability discovery behaves, with the defenders holding, which would be the most useful outcome available.
A fourth, softer signal: the name itself. Disaster nicknames either get earned with confirmed damage or quietly vanish. Which one it becomes is the most honest poll of all this.
The bugs are real. The exploitation attempts are real. The confirmed victims, so far, are not. Patch anyway, on the day the patch exists, because every number in this story that matters has been moving in the wrong direction all week.
Plain-language glossary
- CVE: a public, numbered entry in the global catalog of known software flaws. A CVE number is a claim of a bug, not proof of a breach.
- Remote code execution (RCE): an attacker can make the server run whatever they want. The worst ordinary outcome.
- Memory safety bug: the program mixes up which part of its own memory belongs to whom. PHP is written in the C language, where the programmer manages memory by hand and mistakes are possible.
- Patch: the released code fix. You install it by updating the software.
- End of life (EOL): nobody will ever fix this version, supported or otherwise.
- PoC (proof of concept): published exploit code. “Public PoC” means code exists somewhere on the internet claiming to work; quality varies enormously, and some in this incident were later discredited by their own authors.
- WAF (web application firewall): a filter in front of a site that blocks suspicious traffic. Cloudflare and others deployed rules for this bug; it’s protection, not immunity.
- KEV catalog: the US list of flaws with government-confirmed real-world exploitation. Getting on it is bad news with receipts.
- Black October: a nickname from press chatter in October 2026, covering the PHP disclosures and the fear of an AI-driven wave of bug discoveries. It names a forecast. When a headline uses it, check whether the article delivers a damage report.
Ready when you are.
- Run FlowHealth: find the first system worth installing.
- Book a diagnostic: walk the leak with us and leave with a clear next step.
it just plainworks.