Emergency PHP updates, precautionary website shutdowns and coordinated government warnings show how a flaw in shared software can disrupt public services—even without a confirmed breach.
HLS.Today | October 26, 2026
Two critical vulnerabilities in PHP, the software that runs the server-side logic of many websites and applications, have triggered an international patching emergency. U.S. and European authorities are urging organizations to identify exposed systems, install security updates and investigate suspicious activity.
The incident, known as PHP2Shell, has also interrupted access to public services. But “vulnerable,” “offline” and “breached” describe different conditions. Some organizations deliberately disconnected websites to protect them while fixes were applied. That action does not establish that attackers stole information or took control.
The latest evidence also includes an important correction: on October 25, security researchers withdrew an earlier attribution of a European government intrusion to these particular vulnerabilities. A careful assessment must account for that update alongside the urgent technical risk.
For readers following HLS.Today’s cybersecurity coverage, this is a story about shared software dependencies, emergency response and the shrinking time available to defend public-facing systems.
What is PHP2Shell?
PHP is a server-side programming language. It helps websites process forms, communicate with databases and generate pages before content reaches a visitor’s browser.
The two principal vulnerabilities are CVE-2026-109618 and CVE-2026-109619, both rated critical at 9.2 under CVSS version 4.0.
The first concerns memory corruption when PHP handles an out-of-memory condition. The second concerns internal information left pointing to memory that has already been freed, which a later request can encounter.
Under exploitable conditions, these errors can allow an unauthenticated attacker to execute code. In plain language, the attacker may not need an account or password to make a vulnerable server run unauthorized instructions.
The UK National Cyber Security Centre’s explanation describes the underlying problems and urges organizations to identify PHP throughout their infrastructure—not only installations already considered obsolete.
What could attackers do?
The potential consequences extend beyond an altered homepage.
New York’s Department of Financial Services warns that the vulnerabilities could permit unauthorized access to server files and databases. New Zealand’s NCSC identifies possible takeover or disruption of websites, servers and web services.
Depending on the application’s privileges and connections, a successful intrusion could expose sensitive information or provide a foothold for further activity. The precise impact depends on the affected environment; these are potential consequences, not a claim that every exposed organization suffered them.
An outage also has an independent cost. People may lose access to online information or transactions while administrators secure the system, even when no attacker has established control.
Sources: New York DFS alert; New Zealand NCSC.
How AI helped expose the danger
The description “found by AI” needs context.
According to the PHP Foundation’s account, signs of the out-of-memory problem emerged during work following a 2024 security audit. The possible danger was recognized, but a concrete exploitation path had not been established.
The Foundation says technical trade-offs, limited specialist resources and its decision-making process delayed resolution. In 2026, reports from Calif researcher Ryan A, OpenAI and Wiz demonstrated the seriousness of the issue and made remediation a priority.
AI-assisted research and validation helped this process, but human researchers and maintainers remained responsible for evaluating reports and developing patches. The Foundation also describes using AI to group related findings and help validate submissions.
The lesson is broader than one model finding one bug. AI can help expose consequences that were previously difficult to demonstrate, while engineering teams still need the resources and authority to deliver a dependable fix.
Why the response became urgent
On October 20, the PHP security team publicly announced an imminent critical release. Emergency fixes followed on October 21.
Government agencies then issued guidance across jurisdictions. CISA’s October 21 alert called for immediate patching, prioritizing internet-facing systems. The agency also warned that PHP can be embedded in other software and therefore difficult to identify through a simple website inventory.
CISA said it had not observed exploitation at the time its alert was published. That is a dated observation, not a continuing guarantee that exploitation is absent.
The NSA’s October 21 advisory emphasized identifying PHP-dependent hardware and software services, following vendor updates and maintaining vigilance in the weeks ahead. It also said it was prioritizing identification of malicious actors seeking to exploit the flaws.
These actions demonstrate the practical role of public authorities: alerting operators, coordinating technical information and helping organizations act before exposure becomes compromise.
Which systems are affected?
The risk is not confined to a particular website design or content-management system.
The Dutch NCSC’s operational PHP2Shell repository identifies web-serving deployments including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It also warns about PHP embedded in appliances, management interfaces, network devices and other vendor products.
The highest-risk deployment described by PHP is Apache with mod_php, where a demonstrated attack can occur before application code runs. Other environments must still be assessed.
For a WordPress or similar website, this distinction matters: updating a theme, plugin or content-management application does not itself prove that the underlying PHP runtime has been repaired. The hosting provider’s PHP package and the runtime actually serving each site require verification.
Likewise, a product appearing in an exposure inventory is not automatically a confirmed victim. Organizations should check the vendor’s product-specific status and fixed package.
The PHP versions that address the original two flaws
CERT-EU identifies these fixed upstream releases:
| PHP branch | First fixed upstream release for the original two CVEs |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Earlier releases in those branches require an update or a verified vendor backport.
PHP 8.1 and older no longer receive normal upstream security support. CERT-EU notes that some distribution and long-term-support vendors provide backported fixes, and that minimal source backports were published for PHP 7.4, 8.0 and 8.1.
Consequently, an older-looking version number alone cannot settle the status of a vendor-maintained package. Conversely, selecting “PHP 8.3” in a hosting panel is not enough: the exact patched build matters.
Source: CERT-EU Security Advisory 2026-018.
Which European public services actually went offline?
Official statements provide a firmer picture than broad lists circulating online.
United Kingdom: 32 services unavailable on October 22
In the House of Lords on October 22, minister Baroness Lloyd of Effra reported that 32 government services were unavailable and four were partially unavailable.
She said the disruption largely resulted from precautionary measures while security updates and mitigations were applied. She also stated that the government was not then aware of confirmed compromise of central government systems resulting from these vulnerabilities.
The minister described coordination between the Government Cyber Coordination Centre, NCSC and departments, and reported 50,000 proactive notifications to the wider economy.
These figures are an October 22 snapshot. They should not be presented as the number still offline on October 26.
Source: Official parliamentary record.
Netherlands: websites restored; DigiD authentication stayed available
Logius, the Dutch government’s digital-services organization, provides an especially useful distinction.
It confirmed temporarily taking MijnOverheid.nl, Logius.nl and DigiD.nl offline on October 21 as a precaution. Its October 22 notice said the websites had returned after changes were implemented and tested.
Crucially, the DigiD app and underlying DigiD service remained available throughout. A temporary outage of the DigiD.nl website was therefore not a shutdown of the entire authentication service.
Source: Logius restoration notice.
| Officially documented impact | What can safely be concluded |
|---|---|
| UK: 32 unavailable and four partly unavailable government services on October 22 | A dated service-disruption count, largely attributed to preventive measures |
| Netherlands: MijnOverheid.nl, Logius.nl and DigiD.nl temporarily offline | Logius confirmed restoration on October 22 |
| Netherlands: DigiD app and underlying service | Logius said these remained available |
An unavailable website does not, by itself, prove a denial-of-service attack, data theft or compromise of the institution’s internal operational systems.
Europe’s coordinated response
The European Commission, ENISA, CERT-EU, Europol’s European Cybercrime Centre and the national CSIRTs network issued a joint statement on October 21.
They urged organizations to identify PHP applications, coordinate with hosting providers, prioritize exposed systems and consider isolating public-facing applications when immediate remediation was not possible.
The statement also directed operators toward the Dutch NCSC inventory of third-party products. France’s CERT-FR separately published affected-version guidance and, in its October 22 update, acknowledged proof-of-concept code for particular deployments.
A national advisory establishes that an authority is responding to a threat. It does not establish that every government website in that country was attacked or disconnected.
Sources: ENISA joint statement; CERT-FR alert.
Were attackers already exploiting the flaws?
Public reporting requires careful attribution here.
Amazon Threat Intelligence reported an attempted exploit in its MadPot honeypot telemetry dating to October 17, before public disclosure. It also described subsequent attempts involving multiple sources. Amazon cautioned that it was unclear whether the pre-disclosure attempts would have succeeded against real-world systems.
This is primary industry research, rather than a government finding. It supports investigating exposure before October 21, but does not identify a confirmed list of breached public services.
An additional development is particularly important for today’s assessment. On October 25, Unit 42 retracted its October 23 update associating observed post-compromise activity at a European government agency with PHP2Shell. It said it could not confirm that the initial access involved these specific CVEs.
The incident at that agency should therefore not be reported as a confirmed PHP2Shell breach.
Sources: Amazon Threat Intelligence; Unit 42 corrected threat brief.
The October 23 development: a third vulnerability
The response did not end with the first emergency updates.
On October 23, PHP published an informational advisory concerning CVE-2026-115560, a separate potential remote-code-execution path involving session upload progress.
PHP describes it as requiring an unusual combination of application behavior and configuration, including changing the session serialization handler at runtime. Applications that never change that handler at runtime do not need to disable the feature for this particular issue.
PHP recommends setting:
session.upload_progress.enabled=0
until the next regular bugfix release where appropriate; organizations that already applied that setting should retain it. The October 21 updates address the original two vulnerabilities and should not be presented as fixing this separate issue.
At the time of this review, the published notice still described a forthcoming regular-release fix.
Source: PHP’s October 23 informational advisory.
What organizations should do now
The response should cover remediation, investigation and safe restoration.
- Identify exposure. Include production websites, internal applications, hosted services, containers and vendor products. Ask service providers which PHP-dependent systems they operate and which fixes they have installed.
- Verify the exact fixed build. Confirm an appropriate upstream release or a documented vendor backport. Record the CVEs covered, rather than relying on a general assurance that the server is “up to date.”
- Apply updates and verify running services. Follow the provider’s deployment instructions, including required process restarts. Check the PHP runtime serving each application, rather than assuming a command-line version represents every website.
- Isolate systems that cannot be secured promptly. New York DFS explicitly warns that web application firewalls offer limited protection against certain paths and should not replace patching or isolation.
- Investigate suspicious activity. The FBI’s October 23 alert recommends watching for unexpected PHP processes launching shells or downloading files. If compromise is suspected, isolate the system, preserve web-server and PHP logs and report the incident.
- Treat recovery separately from patch installation. New Zealand’s NCSC warns that patching does not remove an existing compromise. An incident-response team may need to investigate persistence, validate system integrity and address exposed credentials before normal operation resumes.
- Track subsequent advisories. Include CVE-2026-115560 and updates for appliances or products that bundle PHP.
Sources: FBI/IC3 advisory; New York DFS; New Zealand NCSC; NCSC-NL operational guidance.
Status on October 26: fixes available, verification still essential
The original two vulnerabilities have published fixes. Several public-service disruptions were preventive, and Logius has confirmed restoration of its affected websites.
Nevertheless, the existence of a patch is not evidence that every installation has received it. Embedded products, older deployments and incomplete inventories can extend the remediation period. The Dutch NCSC’s product-status repository was still being updated on October 26.
This review found no authoritative, comprehensive count of successful PHP2Shell breaches or a complete current list of services still unavailable. The UK figures remain dated to October 22, while Unit 42’s October 25 correction narrows what can responsibly be claimed about a European government intrusion.
For government leaders and website operators, the practical priority is to establish three facts: whether the system is exposed, whether the running software is fixed, and whether there is evidence of prior compromise.
The wider homeland-security significance is clear. Public-service resilience depends on maintaining the shared software beneath everyday digital services—and on being able to repair it without losing the ability to serve the public.
Sources and further reading
This article draws on a broad review of relevant U.S., European, UK, Dutch, French, Australian and New Zealand official notices, supplemented by original technical reporting from PHP and security researchers. It is not an exhaustive inventory of every government notice worldwide. Publication dates and observation periods differ.
Government and intergovernmental sources
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching — October 21
- CISA: Official bulletin copy
- NSA: Critical Patches Recommended for PHP Vulnerabilities — October 21
- FBI/IC3: Critical Vulnerability Alert — October 23
- New York DFS: Cybersecurity Alert — October 22
- ENISA and EU partners: Joint Statement — October 21
- CERT-EU: Security Advisory 2026-018 — updated October 23
- UK NCSC: Critical Security Issue Affecting PHP
- UK Parliament: Government Response and Service Disruption — October 22
- Dutch Government: NCSC Warning on PHP
- Dutch NCSC: Live Operational and Product Inventory
- Logius: Websites Restored After Preventive Security Measures — October 22
- France CERT-FR: PHP Vulnerability Alert — updated October 22
- Australian Cyber Security Centre: Critical Vulnerabilities in PHP
- New Zealand NCSC: Immediate Patching Advice — October 22



