What happened—and why it matters
On 21 October 2026, the UK’s National Cyber Security Centre urged organisations to address two critical vulnerabilities in PHP, the server-side language used by many websites and applications. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619 and commonly discussed together as PHP2Shell. NCSC incident advisory.
This is a global software-security emergency with UK consequences, rather than evidence of one coordinated attack against the whole country. CERT/CC explains that specially crafted requests can potentially let an unauthenticated attacker execute code on a vulnerable web service. An attacker does not necessarily need a customer account or administrator password to reach the vulnerable processing path. CERT/CC technical assessment.
For a business owner, the distinction is practical. A website can look normal while its underlying runtime needs urgent attention. Equally, an unavailable website may have been deliberately isolated by its operator. Neither appearance proves whether an intrusion occurred. Availability, vulnerability and compromise must be investigated separately.
The verified timeline
17 OCTOBER
An early exploitation attempt.
Amazon subsequently identified PHP2Shell activity in MadPot telemetry dating to this day. It said how the actor obtained exploit information before disclosure was unclear. Amazon’s account.
21 OCTOBER
Security fixes and coordinated warnings.
PHP released fixes for the two original flaws. The NCSC and European agencies urged rapid remediation. PHP release notice; European joint statement.
22 OCTOBER
A documented UK operational response.
NHS Supply Chain said it had applied the recommended patches, its website remained available and it had no evidence of impact on other customer-facing services at that time. NHS Supply Chain update.
23 OCTOBER
Further advice—not the end of the story.
Ofcom highlighted risks to regulated services. PHP also published a separate session-upload-progress advisory, showing why remediation teams must keep following vendor updates after the first patch. Ofcom notice; PHP follow-up.
How the two flaws work, in plain English
1. A failure while handling a failure
CVE-2026-109618 concerns out-of-memory handling. PHP can be interrupted while preparing internal request data; cleanup can then treat incomplete state as valid. The consequence is memory corruption that may be exploitable for remote code execution. The security team describes a problem in the runtime’s request lifecycle, not simply an insecure page template. PHP’s out-of-memory advisory.
2. State that outlives its memory
CVE-2026-109619 involves request-owned state surviving after the memory supporting it has been freed. A worker handling another request may encounter that stale state before normal initialisation resets it. This is why the precise runtime, worker behaviour and configuration matter when assessing exposure. PHP’s stale-state advisory.
CERT/CC notes that Apache mod_php is at particular risk: demonstrated exploitation can reach the vulnerable path before application code runs. A login screen or an application-level check therefore cannot be assumed to stop every relevant request. CERT/CC impact statement.
What is actually confirmed in the UK?
The UK response spans more than website operators. On 23 October, Ofcom encouraged communications providers and operators of essential services in the digital infrastructure subsector to give urgent consideration to NCSC advice. It also said it would engage with supervised services on remediation in the context of their regulatory duties. This was a sector warning, not a declaration that every regulated service had been breached. Ofcom’s statement.
NHS Supply Chain provides a useful counterexample to sweeping claims of an “NHS hack”. Its 22 October notice reported completed patching and no operational impact, with continued monitoring. That statement applies to NHS Supply Chain and that date; it should not be expanded into a claim about every NHS organisation or treated as permanent assurance. The organisation’s own update.
Amazon’s report supports a serious exploitation risk: it describes early attempts, further activity around disclosure and broad attempts afterwards. It also explicitly says it was unclear whether certain observed attempts would have succeeded against real-world systems. Sensor activity is evidence of attempted exploitation, not proof of a particular UK data theft. Read the findings and limitations.
We have not assigned an attacker, repeated a ransom claim or attached a national cost estimate. The primary evidence reviewed does not support those conclusions. Where an affected organisation publishes a confirmed breach notice, its own account should be assessed on its merits rather than folded into a single national narrative.
Which fixes matter now?
The original two vulnerabilities were fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Treat these as the release floors for those flaws, not a promise that a particular version will remain sufficient indefinitely. Distribution packages may carry vendor backports: check the package advisory rather than relying on the headline version number alone. PHP release details; Red Hat vendor guidance.
The 23 October follow-up describes a separate, unusual session-handling combination associated with CVE-2026-115560. PHP suggests disabling session upload progress until the next regular bugfix release to cover that vector; applications that never change the serialisation handler at runtime may keep the feature enabled. Ask the administrator to assess the exact conditions and current guidance. Do not interpret the first emergency update as permission to stop reviewing notices. PHP’s follow-up advisory.
A practical response for business owners
The NCSC prioritises finding PHP installations, updating exposed systems first, checking bundled third-party products and using vendor mitigation guidance where immediate patching is impossible. Where timely mitigation cannot be achieved, it advises considering taking the system offline. Current UK response priorities.
Our engineering recommendation is to turn that guidance into a short record of decisions and evidence. A useful response should answer who owns each system, what has changed and how the team knows the change took effect. A generic “we are protected” email is less useful than a specific, dated confirmation.
Ask for scope, not reassurance.
Request a list of affected production sites, subdomains, test environments, application containers and bundled services. Record the named owner and the provider responsible for each runtime. A forgotten staging copy should not fall outside the conversation.
Request evidence of the running fix.
Ask the host or maintainer for the relevant package advisory, deployment time and confirmation that the serving workers use the corrected package. A successful software-installation task and a verified running service are separate pieces of evidence.
Test the journeys that earn trust.
After an urgent update, check sign-in, enquiries, search, checkout if present, uploads and scheduled work. Agree what happens if a critical journey fails. Keep the test focused enough to support a fast response rather than turning it into an open-ended redesign.
Keep remediation and investigation distinct.
Fixing exposure does not answer whether the system was accessed earlier. Preserve relevant records and ask the response team to assess the exposure window. Where compromise is suspected, involve a qualified incident-response provider rather than treating a visual check of the homepage as an investigation.
Communicate the known facts.
Give customers the service status, the action taken and the next update time. Separate confirmed data impact from questions still under investigation. Avoid both blanket assurances and speculative breach announcements.
The WordPress lesson: a redesign is not a runtime patch
PHP is a dependency beneath the application. The European joint statement calls for organisations to identify PHP-based applications, coordinate with hosting and service providers and prioritise internet-facing systems. Its scope is not limited to one content-management system or plugin. European response guidance.
For a WordPress owner, that suggests two separate maintenance conversations. One covers the visible website: content, templates, themes, plugins and forms. The other covers the hosting environment that executes it. Changing a page builder, improving a mobile menu or removing an unused plugin does not by itself establish which PHP package the server is running.
A better handover connects both layers. Keep the website inventory alongside the hosting owner, supported runtime branch, maintenance route and recovery plan. When an alert arrives, the team should be able to find the right person and request specific evidence without reconstructing the website’s history from memory.
The longer lesson: make urgent change routine
In May 2026, the NCSC warned organisations to prepare for a wave of vulnerability patches and reduce exposed attack surfaces. It emphasised faster, more frequent updating and the limits of keeping unsupported technology in service. October’s PHP response is a practical reason to revisit that preparation. NCSC patch-wave guidance.
Our assessment is that resilience depends as much on the ability to make a controlled change as on the ability to detect a problem. Clear ownership, a tested recovery route and short verification checks help a team act quickly without guessing. The goal is to reduce the time between credible warning, corrective action and reliable confirmation.
Questions business owners are asking
Does an outage mean a website was hacked?
No. A service may be unavailable because it was intentionally isolated, because maintenance is under way or because of an incident. A confirmed breach requires evidence beyond the outage itself. Check the operator’s dated status notice.
Is a working website proof that everything is safe?
No. A visual check confirms only what the page does at that moment. Ask the responsible provider to verify the deployed runtime and assess whether earlier exposure needs investigation.
Should we copy mitigation settings from a social post?
Use the current vendor advisory and the administrator responsible for the environment. Temporary measures have conditions and trade-offs. They should not be treated as interchangeable with installing the relevant fixes.
Is this article saying Incode’s website was compromised?
No. This article analyses public reporting and engineering lessons. It is not an incident notice about Incode, nor a security assessment of any individual reader’s systems.
Sources and editorial method
This analysis uses primary advisories, technical reports and first-party operational statements checked on 25 October 2026. Reported observations are attributed to their publishers. Recommendations labelled as our assessment are editorial engineering analysis. No exploit was run, no affected system was tested and no private incident data was used.
- NCSC: critical security issue affecting PHP
21 October 2026
- PHP: security release and subsequent session advisory
21 and 23 October 2026
- Amazon Threat Intelligence: PHP2Shell activity in MadPot
21 October 2026
- PHP security team: out-of-memory corruption advisory
21 October 2026
- PHP security team: stale global state advisory
21 October 2026
- Ofcom: PHP cybersecurity risk to regulated services
23 October 2026
- NHS Supply Chain: website security update
22 October 2026
- ENISA and European partners: joint statement
21 October 2026
- CERT/CC: vulnerability note VU#763488
22 October 2026
- Red Hat: PHP2Shell security bulletin
Updated 23 October 2026
- NCSC: preparing for a vulnerability patch wave
1 May 2026
Updates: first published 25 October 2026. Future changes should record the date, the new evidence and any corrected conclusion. Always check the linked live advisories before making an operational decision.