Fourteen hundred hours, and the sites already dark
The appointment was precise, which is not how emergencies usually announce themselves. On Wednesday 21 October 2026, at 14:00 UTC, PHP would release a security update for two critical vulnerabilities. The hour was posted to the language's own announce list, picked up by researchers, noted in a post by Dane Knecht, and repeated by outlets telling administrators to brace. Huntress, in a rapid-response note, described leaked critical flaws and gave them numbers: CVE-2026-109618 and CVE-2026-109619. PC Gamer, an unlikely paper of record for a runtime crisis, told web administrators to hold on, and to expect emergency updates that would plug leaked exploits.
By the time that hour arrived, a portion of the web had already chosen darkness. Several major websites had been taken offline because of a critical vulnerability in PHP. The BBC reported websites taken down worldwide as the cyber-security update was issued. These are not quite the same claim as the advice that travelled with them, and the difference is worth keeping. U.S., European and British authorities recommended that websites temporarily go offline until they could be fixed. A recommendation is not an outage. An outage, in the Brussels Times' account and the BBC's, was already the reported fact of the day: sites taken offline amid security fears, sites taken down as the update went out. From the outside, the picture was a patch with an appointment, and a web that had started to dim before the packages could be said to have landed.
In Japan the dimming had names. Gigazine reported that NicoNico, pixiv and various other websites and apps had entered maintenance in order to meet the emergency patch. ITmedia recorded emergency maintenance at CoDMon, Shadowverse: Worlds Beyond, Sakura's rental server, BASE, pictSQUARE, 킴블, X Server and つなぐ. Nothing in those notices, on the material here, is a confession that an intruder was already inside. They read as a judgment that being reachable, through the hours around the fix, had become the riskier state. PHP's security team had warned administrators the day before to prepare for emergency updates addressing two critical vulnerabilities. The team announced the discovery of two severe flaws, and the patches were set for 21 October. Maintainers planned them for vulnerabilities with severity ratings of 9.2 out of 10.
When the packages were published, they had versions. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. The National Cyber Security Centre and the BBC framed the update in the widest terms on offer: a critical issue that may allow attackers to execute commands on any web server running PHP. The episode already had a name, PHP2Shell, and the name was doing the work of a headline. Watchtowr used it. Huntress used it. Amazon used it of an exploitation attempt. Wiz used it of a research find in the core of the language.
The public story was a controlled release at a published hour. The telemetry story was an attempt that did not wait for the announcement.
Amazon Threat Intelligence identified a PHP2Shell exploitation attempt in MadPot telemetry dating to 17 October 2026, four days before the public disclosure of those two CVEs. Between the announce list and that telemetry sits the unease of the week. The people responsible for the language had set a clock. The clock was not the only one running.
Two ways through, and a disagreement about how wide
The vulnerabilities, as PHP's own news archive identified them, are not one bug described twice. CVE-2026-109618 is remote code execution via out-of-memory corruption. CVE-2026-109619 is remote code execution via stale global state. The confirmed impact, on the account that examined the out-of-memory issue, is unauthenticated remote code execution as the web worker account. That last clause does quiet work. It is not a sourced claim of total ownership of a machine. It is a claim that code runs, without a login, as the account the web server already uses to do its job. For a great many sites, that account is the job.
The stale-state flaw has a shape that can be stated without being turned into a procedure. PHP contains various global state — error, session, object and extension state — that is retained by a worker but points to memory owned by one request. A worker, in this arrangement, outlives the request that filled it. The memory does not. What the vulnerability makes of that mismatch is, in the archive's terms, remote code execution. The other flaw reaches a similar destination by the path named as out-of-memory corruption. Two mechanisms, one class of outcome, and a single emergency release built to close both.
The risk, the archive said, is highest for mod_php, with a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs. That is the sentence an operator reads twice. A flaw that waits for a particular corner of an application can be triaged. A flaw reachable by an unauthenticated request, before the application has a chance to be careful, is a different queue. It is why a severity figure of 9.2 out of 10, which Ars Technica reported as the rating on the two vulnerabilities maintainers were about to patch, does not sit on the page as decoration. It is why the security team's message was to prepare for emergency updates tomorrow, not to find a convenient window.
There is a real difference in how far the sources push the blast radius, and it should be named rather than smoothed.
On one side, the BBC and the National Cyber Security Centre framed the update as addressing a critical issue that may allow attackers to execute commands on any web server running PHP. "Any" is a large word. It is the word that turns a runtime bug into something closer to a civil contingency. On the other side, the language's own archive was more specific about where the demonstrated danger sat: highest for mod_php, and reachable, in that demonstrated case, before application code runs. These are not polite synonyms. A reader can hold both — a broad official warning about servers running PHP, and a narrower technical statement about where the risk has been shown to be highest — without pretending they say the same thing. The confirmed impact remains unauthenticated remote code execution as the web worker account. How widely that confirmation travels, beyond the configuration in which it was demonstrated, is the argument the day's advisories did not pause to settle. They patched, and they told people to consider going offline while they did.
The version question has a similar unfinished edge. The vulnerabilities are believed to affect PHP 5, 6, 7 and 8 — believed, not ceremonially confirmed in every line, and the belief is carried by Watchtowr, BleepingComputer, PHP's own security-release note, and Huntress. The versions named as fixing the two critical flaws are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The sources gathered here do not set out a complete map of what, on 21 October, was available for every older line researchers believe to be affected. What they do set out is a gap in the paperwork: a belief about reach that runs back through 5, 6 and 7, and a list of fixes that, in the archive and in the shipping note, is a list of 8.x point releases. For an administrator on a current 8.2, 8.3, 8.4 or 8.5, the instruction was concrete. For anyone still further back, the public record of this episode is a warning without, in these sources, a matching version number.
Wiz Research uncovered multiple critical vulnerabilities in core PHP, and put the exposure at 70 per cent of all websites in the world. The Australian Financial Review, reporting that artificial intelligence had uncovered critical bugs in the language used by most web servers, used the same proportion: 70 per cent of the world's websites at risk. This account has no independent census. The figure belongs to those two tellings, and it is the figure against which the day's behaviour becomes intelligible. If even a serious fraction of that share were right, an unauthenticated path to code execution on the worker would not be a specialist story. It would be a reason for a government department to spend a morning on the telephone, which is what the Australian reporting describes.
A flaw from 2024, an agreement from 2026
The emergency has a prehistory, and it is the least flattering part of the record.
The PHP Foundation found a critical flaw in 2024 but could not agree on a fix until 2026. The Next Web's account is specific about the narrowness of that sentence: PHP knew about one of the flaws in 2024, and the obstacle was not ignorance. It was agreement. The sources do not say which of the two October CVEs that finding was, or who argued for which remedy, or what a rejected fix would have cost. They say a critical flaw was found, that a fix could not be agreed, and that the agreeing took until 2026.
Two years is a long time to leave a critical flaw in a language that Wiz and the Australian Financial Review both associate with roughly seven in ten websites. It is longer when the eventual release is not a scheduled point version with a fortnight's notice, but an emergency patch, announced for a Wednesday afternoon in UTC, with administrators told the day before to be ready. The distance between "we have found it" and "we have agreed how to close it" is, in ordinary software, a workshop argument. In a runtime this widely embedded, on those accounts, the same distance is a public exposure window. The October record does not prove what moved through that window. It does show that the window was real, and that by the middle of the month it was no longer only a matter of governance.
There is a temptation to treat the failure to agree as a moral. The material will not support the moral in any detail. It will support a chronology. A critical flaw, known to the Foundation in 2024. No agreed fix until 2026. Then, in a few days of October, a cluster of things that usually arrive in sequence arrived almost on top of one another: a research disclosure associated with Wiz, and with reporting that credited artificial intelligence; a warning from the security team; a published hour; patches for four current version lines; and, already in a cloud provider's telemetry, an exploitation attempt dated 17 October, before the public disclosure of the two CVE numbers.
The leak, if that is the word, is itself a sourced framing rather than a settled mechanism. Huntress headlined leaked critical vulnerabilities. PC Gamer wrote of leaked exploits, and of administrators bracing for the updates that would plug them. The official announce was of an upcoming critical security release, timed to 21 October at 14:00 UTC. Nothing in these sources describes how any leak occurred, who held the details, or whether the 17 October attempt used the same information that researchers and headline-writers would later call leaked. What the sources allow is a harder, smaller claim. The attempt precedes the public disclosure. The public disclosure was managed as an emergency with a clock. And at least one of the underlying flaws had been inside the Foundation's knowledge, unresolved by agreement, since 2024.
They did not fail to see it. On one of the flaws, they failed to agree a fix — from 2024 until 2026.
That distinction changes the kind of reassurance a patch can offer. A bug found on Monday and fixed on Wednesday is a process working at speed. A bug found in 2024 and shipped, under emergency conditions, in October 2026 is a process that eventually worked, after a delay that, on The Next Web's account, consensus could not close. The patches of 21 October do not erase the delay. They end it.
It is worth noticing what kind of release this became, once agreement finally arrived. Not a quiet commit. A security update with a published hour, trailed on the announce list, severe enough that the security team spent the previous day telling administrators to prepare, and severe enough that the ratings attached to the two flaws sat at 9.2 out of 10. PHP's own note on the day carries, in its title, a promise to say how the project is strengthening its security. The content of any longer reform is outside these sources. The fact of the emergency is not. What is visible, in the material actually to hand, is a decision to ship, at a named hour, fixes for two flaws the project was no longer willing to leave until a convenient release.
The day the ordinary web switched itself off
Outages are usually narrated from the outside: a site fails, a user notices, a status page catches up. This one was narrated, in several places, as a choice.
The Brussels Times reported major websites going offline as the vulnerability triggered security fears, and the claim underneath is direct. Several major websites were taken offline because of a critical vulnerability in the language. The BBC's scale was wider still: websites taken down worldwide as the cyber-security update was issued. Neither account itemises the method — what was stopped, by whom, for how long — and it would be a fiction to supply the missing operations. They fix the cause to the PHP issue. They fix the response, in more than one country's reporting, as absence rather than a quietly applied hotfix.
The official advice gave that choice a sponsor. U.S., European and British authorities recommended that websites temporarily go offline until they could be fixed. It is difficult to overstate how rarely that sentence is the responsible one. Taking a site down is, in ordinary times, the outcome an attacker wants and an operator fears. Here, three sets of authorities treated temporary absence as the safer state, for as long as the fix was not yet applied. The National Cyber Security Centre's notice of a critical security issue affecting PHP sits in the same weather, even where this record does not quote the Centre as issuing the offline recommendation in those words. What the Centre is cited for, alongside the BBC, is the substance: a critical issue that may allow attackers to execute commands on any web server running PHP, and a security update published to address it.
Australia's version of the morning was a scramble to patch. The Australian Financial Review reported that artificial intelligence had uncovered critical bugs in the programming language used by most web servers, and that government agencies were scrambling to patch vulnerabilities in websites. That detail pulls the story out of the usual theatre of consumer outages. Named services going to maintenance is one kind of harm: a public that cannot reach something it uses without thinking. A government agency patching in a hurry is another. The same language, embedded in sites that are not optional in the same way. The AFR's frame was the 70 per cent figure, and the discovery. The operational frame was simpler. The bug was in the language. The language was in the sites. The sites had to move.
Japan supplies the most concrete list, and therefore the most useful corrective to abstraction. It is easy to say "the web" and mean a diagram. It is harder to dismiss a maintenance notice that names CoDMon, Shadowverse: Worlds Beyond, Sakura's rental server, BASE, pictSQUARE, 킴블, X Server and つなぐ. Add NicoNico and pixiv, as Gigazine did, and the list stops being a metaphor. Hosting is the multiplier hiding in those names. A vulnerability in a single application is a vulnerability in that application. A vulnerability in the language, on a rental server or on X Server, is a queue of customers who did not choose the bug and cannot, in any meaningful sense, patch around it themselves. These sources do not count those customers. They show the hosts treating the patch as urgent enough to take the service into emergency maintenance.
The security team had asked for preparation, and the timing shows the shape of what was asked. The warning was to prepare for emergency updates tomorrow. The release was set for 14:00 UTC on the 21st. The patches, once shipped, were the four point releases already named. What filled the hours around that appointment was not, on this record, a single coordinated blackout. It was a patchwork: some sites taken offline amid security fears, some taken down as the update went out, some put into named maintenance, some scrambled over by Australian government agencies whose problem was the patch itself. The common element is the language, and the judgment that waiting for a convenient evening was no longer the conservative choice.
Severity helps explain the judgment without explaining it away. Two vulnerabilities, each carrying a rating of 9.2 out of 10, is not a pairing that invites a staged rollout over a quiet weekend. Unauthenticated reach, in the demonstrated mod_php case, before application code runs, is not a pairing that invites confidence in whatever checks an application might later perform. Put those next to a warning that the issue may allow command execution on any web server running PHP, and the advice to go offline until fixed stops looking like theatre. It looks like the residual option, once the flaw is understood to sit in the runtime rather than in a corner an operator can simply switch off.
None of this required the vulnerabilities to be new to everyone. It required them to be newly undeniable. The Foundation's 2024 knowledge, and its inability to agree a fix until 2026, belongs in the same breath as the maintenance notices. The sites that went dark on 21 October were living inside a delay they did not vote on. That is the political fact inside a release-engineering fact. A language used, on the Wiz and AFR telling, by something like 70 per cent of the world's websites is not a private codebase, even when its governance is a private argument. The cost of an unagreed fix is paid by people who do not attend the meeting.
Who knew, and who was already trying
There are two firsts in this story, and they answer different questions.
Wiz Research uncovered multiple critical vulnerabilities in core PHP. The company's account, and the Australian Financial Review's, both put artificial intelligence in the discovery. Wiz framed the find as AI uncovering critical remote-code-execution vulnerabilities affecting 70 per cent of the internet. The AFR reported that AI had discovered a bug putting 70 per cent of the world's websites at risk, and that Australian government agencies were scrambling. How any model was used, what it was shown, what a human researcher still had to prove: none of that is in the material here, and it would be a fiction to supply it. What is in the material is the attribution. A research effort associated with Wiz, and described in more than one place as the work of AI, surfaced multiple critical flaws in the core of the language. On that telling, this was not a misconfiguration in a popular extension. It was PHP itself.
The other first is not a discovery. It is an attempt. Amazon Threat Intelligence identified a PHP2Shell exploitation attempt dating to 17 October 2026, in MadPot telemetry, four days before the public disclosure of CVE-2026-109618 and CVE-2026-109619. An attempt is not a breach census. These sources do not say how many servers answered, what was taken, or whether the attempt succeeded in any durable way. They say it was identified, that it was dated to the 17th, and that public disclosure of the two CVEs came four days later. In a week of large claims — any web server, 70 per cent of websites, worldwide takedowns — the Amazon sentence is almost austere, and it is the one that most changes the temperature. Someone was not waiting for the FAQ.
Laid flat, the sequence is this. A critical flaw known to the Foundation since 2024, without an agreed fix. An exploitation attempt on 17 October 2026, seen in Amazon's MadPot telemetry. A warning from the PHP security team to prepare for emergency updates the next day. An announced release at 14:00 UTC on 21 October, carried on php.announce and corroborated by Huntress, by PC Gamer's account of administrators bracing, and by Dane Knecht's post. Patches shipped the same day, as 8.5.12, 8.4.27, 8.3.36 and 8.2.35, closing two critical vulnerabilities that allow unauthenticated remote code execution. Around that shipment: sites offline, sites in maintenance, agencies scrambling, authorities recommending darkness as a temporary control.
What this chronology will not support is a single plot running from a 2024 disagreement to a 17 October probe. Nothing here connects the Foundation's unpublished failure to agree with the MadPot attempt, or that attempt with the research disclosure, or the research disclosure with a named operator. The honest picture is of several clocks, not one conspiracy. A governance clock that ran for two years. A research clock that ended in a public uncovering attributed to Wiz and to AI. A defensive clock set, very deliberately, to 14:00 UTC on a Wednesday. And an offensive clock that, on Amazon's account, had already struck on the 17th.
The leaked-exploit framing sits awkwardly across those clocks, and the awkwardness should be left visible. If Huntress and PC Gamer are right that the vulnerabilities, or the exploits, had leaked, then the emergency release is in part a response to a loss of control over the information, not only a response to a bug. If the announce list is read on its own, the release is a planned critical security update with a start time. Both can be true: a plan, and a plan conducted where others were already describing a leak. The sources do not adjudicate. They show a project choosing a public hour, researchers describing leaked flaws, and a cloud provider's sensors recording an attempt before the CVE numbers were public. That is enough to reject the comforting version, in which the first anyone outside heard of the flaws was a polished advisory and a set of packages.
It is also enough to be careful about success. "Exploitation attempt" is the phrase Amazon's account supports. "May allow" is the phrase attached to command execution on any web server running PHP. "Demonstrated" is the word the PHP archive uses for the mod_php path, where an unauthenticated request can trigger the attack before application code runs. "Confirmed impact" is unauthenticated remote code execution as the web worker account. Stacked carelessly, those sentences become a sense of general compromise already accomplished. Read as written, they are more precise, and the precision is the news. There is a demonstrated path. There is a confirmed class of impact. There is a recorded attempt before disclosure. There is a warning broad enough to cover any server running the language. There is not, in this material, a published tally of intrusions.
What four version numbers can close
The packages are the part of the story with version numbers, and version numbers are a mercy. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. Four branches, four point releases, one afternoon. For the operators on those branches, the emergency had an ending that could be downloaded. The security update was not only promised at 14:00 UTC. It was published, to address a critical issue that may allow attackers to execute commands on any web server running PHP. That is the sentence the National Cyber Security Centre and the BBC leave in the record, and it is the sentence against which the maintenance windows were opened, and against which they can close.
What the packages do not automatically close is the argument about scope.
They do not, on the face of these sources, answer the administrator whose PHP is 7, or 5, or 6, all of which sit inside the set of versions believed to be affected. Belief is not a patch. The belief is well attested — four sources, including the project's own security-release writing and a specialist FAQ from Watchtowr. The fixes that are named are not a matching set. To pretend otherwise, for the sake of a clean ending, would be to invent a backport these clusters do not contain. The clean statement is the untidy one. Current 8.2, 8.3, 8.4 and 8.5 have named fixes. Older lines are, in the judgment of those four sources, inside the believed blast radius, and this record stops there.
Nor do the packages dissolve the difference between "any web server running PHP" and "highest for mod_php". An operator whose setup is not the one the archive marked as the highest risk can read the official warning and the technical note and not know which governs the night. The archive's demonstrated case is the one in which an unauthenticated request triggers the attack before any application code runs, and it attaches that demonstration to mod_php as the highest risk. The broader warning does not wait on the distinction. Authorities in the United States, Europe and Britain recommended temporary offline status until sites could be fixed, and that recommendation does not read as limited to a single server module. If there is a dispute in this episode, it is not a shouting match between vendors. It is this: a wide institutional description of who is exposed, and a narrower technical description of where the danger has been shown at its highest, published into the same week, about the same two CVEs. Both are in the record. Neither cancels the other.
The impact statement has its own boundary, and the boundary is worth keeping. The confirmed impact is unauthenticated remote code execution as the web worker account. That is severe, and it is specific. Command execution, in the BBC and NCSC formulation, is the power being warned about. The account named in the impact confirmation is the worker's. A careful reader does not trade one up for the other. Code execution as the worker is enough, on the sourced claim, to matter enormously: it is the website's own hands. It is not, on this evidence, a sourced claim of automatic control beyond that account. The day's fear was calibrated to the claim the sources actually make, and that claim was already enough to empty homepages and to justify, in three sets of authorities' judgment, a temporary disappearance.
There is a further boundary around the word "attempt". Amazon saw a PHP2Shell exploitation attempt on 17 October, before disclosure. The patches of the 21st cannot unsee it. They can close the bugs such an attempt would have needed, on the versions they cover, for the operators who apply them. They cannot say how many attempts of that kind were never seen, or how many succeeded in places without telemetry of MadPot's sort. The absence of a victim list in these sources is not evidence of a quiet week. It is evidence that this record is about the flaw, the fix, the advice, and one identified attempt — not about a completed accounting of harm.
And there is the boundary around 2024. The patches agree a fix. They do not explain the disagreement that delayed one. The Next Web's finding stands as the static under the release notes: one of the flaws was known in 2024; a fix could not be agreed until 2026; the agreement, when it came, came as an emergency, trailed the day before and rated 9.2 out of 10. Anyone who wants a story about a sprint from discovery to patch will have to start the clock in October. Anyone who starts it where The Next Web starts it will see a two-year argument, and then a Wednesday.
PHP2Shell is a good enough name for a week. It is a poor name for the condition the week exposed. The condition is that a flaw in this language can be known, and unagreed, and then suddenly everyone's; that the patch, when it comes, can be real and still not cover, in the sources we have, every version researchers believe to be in scope; that the official warning and the technical note can both be careful and still not say the same thing. The sensible instruction, for a day, was not to be cleverer than the bug. It was to be offline until the packages with those four numbers were no longer a promise for 14:00 UTC, but a file that had actually shipped.
The web, in the accounts of that Wednesday, did not fall over on its own. Parts of it were put to sleep on purpose, by operators and hosts who had read the warning and preferred a maintenance page to a worker executing someone else's commands. That is not a small story about a point release. It is the story of how much ordinary life now sits inside a PHP process — a share that Wiz and the Australian Financial Review both put near 70 per cent of the world's websites — and of how little room that leaves when a worker can no longer be trusted to keep one request's memory from lingering as the next request's state. The fix, on the lines it covers, is four version numbers and an afternoon. The delay that made the afternoon an emergency was two years long.