The Advice Came At 09:18. Parliament Went Offline At 13:02.

At 09:18 on 21 October 2026 the UK National Cyber Security Centre published an alert on two critical PHP vulnerabilities. It told organisations that where immediate patching was not feasible, they should consider taking the system offline. The patch did not exist yet. It was due at 15:00.

At 13:02, nearly four hours later, European public bodies began pulling services down. The Dutch House of Representatives, the Dutch national cyber security centre, the Dutch data protection authority and the Finnish state IT centre Valtori all withdrew public-facing services, along with universities in Austria and Germany and a meeting system serving roughly 100 Dutch municipalities.

In between those two timestamps, a PHP core developer gave the same advice at 10:21, exploitation attempts were observed in the wild at 11:07, and Cloudflare confirmed early attacks at 11:58.

The option was on the table from breakfast. What took four hours was not working out what to do. It was finding somebody able to authorise it.

Update, 23 October: the difficulty argument has expired

Two days after this briefing was published, the exploitation position has moved in one specific and commercially important way. Successful compromise is still unproven. Reliable exploitation is no longer in doubt.

On 22 October VulnCheck confirmed it had a weaponised exploit for CVE-2026-109618, and its own account of the conditions is the part that matters. The exploit chained a confirmed memory leak into remote code execution and "was successful on x86-64 platforms with ASLR enabled and display_errors=off, the recommended production configuration". By the evening of 22 October it covered PHP 8.4.10 to 8.4.26 with no modifications. VulnCheck says it is "not aware of any other public or commercial exploit that achieves RCE on multiple versions of PHP", and has made it available only to its own threat intelligence customers.

The public code is a separate question and the two are being reported as one. VulnCheck identified at least one public proof of concept that bypassed ASLR, but only on a single version, 8.4.26, with default heap configurations, and in VulnCheck's testing it did not work outside that setup. Hundreds of proof-of-concept repositories have appeared on GitHub and VulnCheck says only a very small number have been legitimate. On ARM64 the memory leak works but remote code execution is not yet functional, although VulnCheck notes that ASLR can be brute-forced relatively easily there.

Attempt volume is now substantial and mostly indiscriminate. Cloudflare recorded tens of thousands of attempts within 45 minutes of public disclosure, hundreds of thousands within two hours and millions by early on 22 October. The payload seen most often tries to enlist servers into Potassium, a Mirai-derived botnet first flagged by Synthient in March 2026, which Arctic Wolf documents carrying 24 flood commands. Sophos, which analysed an expanded variant, says threat actors appear to be struggling to build reliable exploits.

Both of those things are true at once, and holding them apart is the whole operational point. No successful compromise in the wild has been reported. Previdian saw no successful remote code execution and no dropped PHP files, SOCRadar found no shell access on any site it screened, and Wordfence and Dataminr report no known compromises. VulnCheck's own canary hosts recorded a single attempt to plant a webshell through session upload progress, and all ten follow-up reads returned 404. What has changed is not the evidence of compromise. It is that the distance between a scanning botnet and a competent operator is now a question of access to a working exploit rather than a question of research.

What this means for anyone still carrying unpatched PHP. The most common reason given for deferring this patch was that exploitation looked hard and unproven. That reason has now closed, and it was never the strong one: the PHP project said on the first day that no mitigation makes an installation safe. The configuration defence in particular does not hold, because the exploit that works was tested under the production setting most organisations will tell you they run. Any risk acceptance signed in the last two days on the grounds of exploitation difficulty should be re-dated and decided again.

Two further developments belong on the record. Amazon Threat Intelligence reports that its MadPot honeypot observed a php2shell exploitation attempt on 17 October, four days before public disclosure, though Amazon says it is unclear whether the 21 October attempts would have succeeded against real systems. And on 23 October the PHP project published a separate informational advisory recommending that session.upload_progress.enabled=0 be set until the next regular bugfix release, disclosing a further vulnerability, CVE-2026-115560, which it is handling in the normal release cycle. Organisations that applied that setting as a mitigation on 21 October need take no further action.

What happened

On 20 October 2026 the PHP project pre-announced a security release covering two critical vulnerabilities, both rated CVSS v4.0 9.2, after technical detail leaked ahead of the embargo. The release was scheduled for the following afternoon.

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, circulating under the name php2shell. Both allow unauthenticated remote code execution.

The day ran as follows, in British Summer Time, as recorded by Precursor Security's live blog.

At 09:18 the NCSC issued its alert to UK organisations, encouraging them to prepare for immediate updating and advising that where immediate patching was not feasible they should "consider taking the system offline". At 10:21 a PHP core developer gave the same advice publicly. At 11:07 exploitation attempts against both CVEs were observed in the wild. At 11:58 Cloudflare confirmed early attacks. Its chief technology officer Dane Knecht, writing on his own account, said the company was "seeing early attacks emerging" and was updating mitigations as new vectors appeared, and called the available workaround "a STOPGAP only". At 13:02 governments and public institutions began taking web services offline. At 14:48 the patch shipped, twelve minutes ahead of the announced 15:00 release.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which the project says "fix two critical vulnerabilities that can allow unauthenticated remote code execution". Published with that release, and not before it, came the project's assessment of the alternatives: "while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe". The release notices put it shorter: "There are no complete mitigations, updating is the only safe choice."

The project's description of who was at risk is unusually plain. At risk are "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed". It considers the risk highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs".

That last clause is the commercially significant one. Nothing an organisation wrote, bought, configured or tested at the application layer sits in front of it.

In the Netherlands, according to NOS, the organisations that went offline included the Tweede Kamer, the government services MijnOverheid.nl and DigiD, the website of NCSC-NL itself, the Autoriteit Persoonsgegevens, and NotuBiz, a meeting system used by roughly 100 municipalities. Several higher education systems followed, along with RTL's news service, the technology title Tweakers and the ANP news agency. In Finland, Yle reported that the state IT centre Valtori began shutting down public-facing central government web services in the early afternoon, and that the National Land Survey website and the Finnish Film Foundation had already gone down. Universities in Vienna and Freiburg switched off websites, webmail and learning platforms.

Every one of those shutdowns was reported as precautionary. Valtori said of the Finnish shutdowns that the outage was not caused by exploitation of the vulnerability or by any breach of the services, and that the purpose was to protect them. Vienna described its own as purely a precautionary measure, and Freiburg took its intranet, learning platform and student webmail off the network on the same basis. No organisation named above has reported a compromise.

Why the gap is the story

A critical vulnerability is normally a race. Apply the fix before somebody finds you, and manage the gap with compensating controls. For most of 21 October that race was not available, because there was nothing to apply until 14:48.

That leaves one option, and everybody had it in writing by 09:18.

The usual explanation for a slow response is that the picture was unclear. It does not hold here. By 11:07 exploitation attempts were being observed, and by 11:58 a major infrastructure provider had said publicly that attacks were emerging. The information position at noon was better than most organisations ever have during an incident. The first public bodies still did not act until 13:02.

What sits in that gap is not analysis. It is authorisation. Taking a parliament's website, a national identity service or a university's learning platform offline is a decision with immediate, visible, attributable cost, and in most institutions the people who can see the risk first are not the people who can authorise that cost. The organisations that moved at 13:02 are not remarkable for having better intelligence. They are remarkable for having somebody who could say yes.

It is worth being precise about what the NCSC did and did not do. It did not declare downtime acceptable, and it did not characterise service withdrawal as a legitimate risk decision. Action 4 is conditional operational advice: if you cannot apply the temporary mitigations, or applying them would take too long, "consider taking the system offline until it can be fully mitigated". What changed is narrower than a shift in doctrine, and more useful. The uncomfortable option is now written down by a national authority, which makes it an option a board can be asked about afterwards.

The NCSC was not alone or first in substance. CERT-EU recommended isolating internet-facing resources from public networks "until the fix is applied and verified", Reuters reported CERT-EU urging those unable to patch immediately to consider taking affected sites offline, and a PHP core developer said the same thing at 10:21. The advice was abundant. Acting on it was not.

The exposure nobody has mapped

The NCSC advisory carries one instruction that will cost most organisations more time than the patching. Action 6 tells them to "continuously monitor for security updates from third-party software vendors, including for appliances and services that may bundle PHP". The same action points them at NCSC-NL's "inventory list of software products with a PHP dependency potentially affected by the vulnerabilities".

PHP inside something an organisation bought is not PHP that an organisation knows it runs. It does not appear in a developer's dependency file. It does not appear on an asset register that lists the appliance by vendor and model. It is not what a supplier questionnaire asks about, and it is not what a patch compliance report measures. The organisations still exposed in December will not be the ones that failed to patch. They will be the ones that never knew they were running it.

The scale is estimated rather than known. Security researcher Silas Cutler put a rough figure of over 1.3 million internet-exposed hosts as potentially vulnerable. A Shodan search by Henk Poley counts over 1.9 million internet-exposed hosts running PHP. Both measure exposure, not compromise, they count different things, and neither counts PHP running inside a product whose vendor has not yet published an advisory.

The fix does not reach everyone either. PHP 8.1 and older no longer receive updates from the project, although the security team published minimal source backports for 7.4, 8.0 and 8.1 for those building from source or without an LTS vendor. Those are source patches rather than releases, and somebody competent has to apply them. PHP 8.2 reaches end of life on 31 December 2026, so for anyone on that branch, 8.2.35 buys about ten weeks rather than a year.

The commercial exposure for UK organisations

Regulatory. NCSC advice is not law and does not itself create a legal obligation. Its effect is evidential. An organisation that saw action 6, decided to keep a vulnerable internet-facing service running, and was subsequently compromised, is in a materially different position from one that cannot show the question was ever put. Under UK GDPR the accountability principle requires a controller to be able to demonstrate compliance with the data protection principles, and a dated risk decision with a named owner is one of the more useful pieces of evidence towards that.

Financial. For the organisations that acted on 21 October the cost is measurable, immediate and sits in revenue rather than remediation: a portal closed, a self-service route withdrawn, a transaction channel stopped. That is precisely the difficulty. The cost of switching a service off is visible, instant and attributable to the person who authorised it. The cost of compromise is larger, later and spread across people who were not in the room. Organisations do not under-weight this decision because they misjudge the numbers. They under-weight it because of who carries each cost.

Contractual. Most availability commitments were drafted on the assumption that downtime is a failure. Few carve out voluntary withdrawal of service on security grounds. An organisation that follows action 6 may breach a service level commitment by doing the defensible thing, and an organisation determined not to breach it may stay exposed as a direct result. That clause is worth reading now rather than during the next event.

Governance. The practical measure of resilience is not the recovery time objective. It is the distance between the moment the advice is published and the moment somebody can act on it. On 21 October, for the institutions that moved at all, that distance was just under four hours. Most organisations have never measured it.

What leaders should do now

1. Measure your own gap. Take today's timeline and ask what time your organisation would have acted. If the answer is after the patch landed, the patch saved you and the process did not.
2. Name the individual who can authorise service withdrawal, and the deputy. Give the role a stated financial threshold above which it escalates, and below which it does not. An authority that exists only in principle is not an authority.
3. Ask for the bundled PHP position, not the PHP position. The first answer will be about servers and applications. Send it back and ask which purchased appliances and managed services contain PHP, and which of their vendors have published an advisory for these two CVEs.
4. Separate the population that has a fix from the population that does not. Anything on 8.1 or older needs a decision, not a patch. Anything on 8.2 needs a migration plan dated before 31 December 2026.
5. Read the availability clause in the five contracts that matter most. Establish whether security-driven withdrawal of service is a breach, and if it is, open the conversation before you need the answer.

Three questions for leadership

1. On a day like today, what time would we have taken a customer-facing service offline, and who would have had to approve it?
2. Which of our suppliers' appliances and managed services contain PHP, and which of those suppliers have published an advisory for these two CVEs?
3. When the answer to the next event is again that no configuration is safe, what is our pre-agreed position?

The strategic takeaway

Every organisation reading the NCSC alert at 09:18 had the same information as the Dutch parliament. The difference between those that acted before lunch and those that waited for the patch was not insight. It was whether a named person could make an expensive decision quickly, and whether anyone knew which services the decision applied to.

Both are governance properties, not technical ones. Neither can be bought during an incident, and neither appears in a patch compliance report. The uncomfortable option is now written down by a national authority, which means the question after the next event will not be whether you patched in time. It will be what time you could have acted, and who was waiting for permission.

Confidence note

Confirmed. The PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026 at 14:48 BST, twelve minutes ahead of the announced 15:00 release, addressing CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. The project states that all PHP installations serving web requests are at risk, that the risk is highest for mod_php, and that updating is the only complete solution. PHP 8.1 and older receive no project updates, with minimal source backports published for 7.4, 8.0 and 8.1. PHP 8.2 reaches end of life on 31 December 2026. The NCSC advisory sets out six priority actions, states that this security issue has now been fixed and that organisations using any version of PHP are affected, and in action 4 advises considering taking the system offline where the temporary mitigations cannot be applied or would take too long. The advisory has been revised since first publication and carries no change log, so every quotation from it here is taken from the text as it stands on 23 October. The timings in this briefing are as recorded in Precursor Security's live blog of 21 October 2026, with the exception of the patch release time, which is corroborated by that blog's pinned 14:48 entry, by Patchstack's reference to the 13:52 UTC release and by Help Net Security publishing its patch notice at 13:51 UTC. NOS and Yle reported the Dutch and Finnish shutdowns named above, all described as precautionary, and Valtori confirmed its shutdowns were a precaution rather than a response to a breach.

Assessed. Exploitation attempts against both CVEs were observed in the wild from 11:07 BST and are now counted in the millions by Cloudflare. Cloudflare's chief technology officer Dane Knecht said the company was seeing early attacks emerging. Patchstack logged an entry at 07:34 UTC reporting "multiple active exploitation incidents reported to Patchstack by hosting partners", but published no supporting indicators and later the same day recorded "only probing attacks, with no hard evidence of breaches yet", so we carry that claim as unverified third-party telemetry rather than as evidence. watchTowr told BleepingComputer on 20 October that it believed it had reproduced CVE-2026-109618 and subsequently reported reproducing both. Tenable, whose page was last revised on 23 October, still says of the exploit code circulating publicly that it has "not verified that any of it works against CVE-2026-109618 or CVE-2026-109619", which remains accurate of public code and does not cover the non-public exploit described in the update above. We assess reliable exploitation as demonstrated, exploitation attempts as confirmed and widespread, and successful compromise as unproven.

Not known. Whether any organisation has been compromised through either CVE. Whether either CVE will be added to the CISA Known Exploited Vulnerabilities catalogue, which as at its 21 October 2026 revision lists three older vulnerabilities in PHP itself and neither of these. Whether any of the precautionary shutdowns will later prove to have been breach-driven. How much of the installed base sits inside vendor appliances with no advisory yet published. Why the interval between the 09:18 advice and the first shutdowns was what it was in any individual organisation.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and beyond.