Summary
- Thirty-two UK government services are offline and four partially unavailable amid precautionary security work following the disclosure of two critical PHP vulnerabilities.
- Amazon and Cloudflare have detected exploitation attempts, although no compromise of the affected UK government systems has been confirmed.
- Experts warn that legacy software, embedded PHP components, and third-party dependencies could complicate remediation and prolong exposure.
Thirty-two UK government services have been taken offline and another four are partially unavailable as authorities respond to two critical vulnerabilities in PHP, a programming language underpinning much of the internet.
Technology minister Baroness Lloyd of Effra confirmed the figures in the House of Lords on Thursday, explaining that most of the disruption resulted from precautionary action while security updates and mitigations were applied.
Downing Street said no major public-facing critical services had been affected, although some government websites had been temporarily disabled. Officials have not identified every affected service and stressed that taking systems offline does not mean they have been compromised.
The disruption follows warnings from the National Cyber Security Centre (NCSC) about two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both carry a critical severity score of 9.2 under CVSS v4.0 and could allow unauthenticated attackers to execute malicious code on vulnerable servers.
The Office for Budget Responsibility was among the public bodies to take its website offline, prompting questions about the security of information ahead of next week’s Budget. Scottish Secretary Douglas Alexander said he had received no indication that Budget security had been breached.
Oxford City Council and South Ribble Borough Council also temporarily suspended websites as a precaution. Similar disruption has affected public bodies elsewhere in Europe, reflecting the extensive use of PHP across public and commercial digital infrastructure.
Exploitation attempts intensify after disclosure
PHP is widely used to generate dynamic website content and support applications, including those built on WordPress, Drupal, and Joomla. Unlike vulnerabilities confined to an individual application, PHP2Shell affects the underlying runtime, potentially exposing multiple services that depend on the same software.
The two flaws involve errors in memory management and request handling that, under certain conditions, allow an attacker to interfere with PHP’s internal state. Successful exploitation could enable remote code execution or access to sensitive information held in server memory.
The PHP development team issued emergency updates on 21 October, releasing fixed versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Organisations running older, unsupported branches may require vendor backports or migration to supported versions.
However, evidence suggests attackers began attempting to exploit the vulnerabilities before the fixes became public.
Amazon Threat Intelligence identified an exploitation attempt against its MadPot honeypot infrastructure on 17 October, four days before public disclosure. Further attempts were observed around the release, with Amazon subsequently reporting broader exploitation activity. It remains unclear whether the earliest attempts would have succeeded against production systems.
Cloudflare has also observed attackers modifying their techniques in attempts to evade web application firewall protections. Although these findings demonstrate active malicious interest, they do not establish that UK government systems have been successfully compromised.
Samuel Hassine, CEO and co-founder of cybersecurity company Filigran, supported the decision to suspend services rather than maintain potentially vulnerable systems online.
“Taking a website offline for a day is a far cheaper decision than explaining a breach for a year.”
Hassine said organisations must extend their response beyond immediately visible infrastructure, identifying PHP installations embedded in third-party products and checking for evidence of unauthorised access during the period of exposure.
His assessment reflects the NCSC’s guidance, which advises organisations to update affected systems promptly, consider taking services offline where adequate protection cannot be applied, and examine potentially exposed installations for signs of compromise.
Legacy systems complicate emergency remediation
The vulnerabilities also expose a longstanding problem in enterprise security: software inventories frequently fail to capture components embedded within older applications, vendor appliances, and infrastructure maintained outside central IT management.
Sai Molige, senior manager of threat hunting at Forescout, warned that the scale of the problem could resemble the response to Log4Shell, although the underlying operational challenges differ.
“PHP2Shell has the potential to become a Log4Shell-scale event, but for a different reason. With Log4j, the main problem was finding a library you didn’t know you had. With PHP, much of the forgotten infrastructure will be found, but won’t have an upstream fix.”
The comparison remains a warning about potential exposure rather than an assessment of confirmed compromise. Molige identified several environments where PHP installations may escape conventional patching processes, including network appliances with web administration interfaces, bundled software runtimes, older container images, development tools, and websites inherited through acquisitions.
Some systems depend on vendors to provide fixes, while others use unsupported versions that cannot be updated without wider application changes. An otherwise current server may also contain an older, vulnerable PHP runtime inside a container or commercial software package.
Such dependencies create a gap between identifying a vulnerable component and being able to remediate it. Where a direct update is unavailable, organisations may need to restrict network exposure, isolate affected systems, or introduce temporary controls while awaiting a permanent fix.
Molige also pointed to the importance of examining systems for suspicious activity rather than treating patch installation as proof that an earlier compromise did not occur. External exposure assessments, software inventories, container analysis, and network monitoring can help establish where vulnerable PHP implementations remain in use.
AI discovery raises further security questions
The incident has also drawn attention to the growing role of artificial intelligence in vulnerability research.
Researchers working with AI systems helped establish practical exploitation paths for weaknesses in PHP’s memory handling. The PHP Foundation has acknowledged that developers identified signs of the underlying problem during security work in 2024, but struggled to resolve it before researchers demonstrated the potential for remote exploitation.
The Foundation attributed the delay partly to technical compatibility concerns, limited specialist resources, and difficulties reaching decisions within its security team. It has since outlined changes to its security processes intended to improve remediation and coordination.
Meanwhile, AWS has warned that AI-assisted analysis could shorten the time between vulnerability disclosure and the appearance of working exploits, increasing the pressure on organisations to act before traditional patching schedules can be completed.
The consequences are already visible across public services. Emergency shutdowns have limited potential exposure but also interrupted access to government information and online services, while organisations dependent on legacy software face more complicated recovery decisions.
As of Thursday afternoon, the government had not published a complete list of affected services or confirmed when all 36 services would become fully available. The NCSC continues to monitor the vulnerabilities’ impact on UK organisations while advising operators to identify, update, and assess their exposed PHP systems.
