The PHP vulnerabilities: what organisations need to do

You may never have heard of PHP, but it is an open source programming language used to run websites and online services, including platforms such as WordPress, Drupal and Magento. Some estimates suggest it sits in as much as 70 percent of websites on the internet. It may also sit inside products and services supplied to you by third parties. 

Two critical vulnerabilities disclosed this week therefore have wide implications. Organisations need to establish where they rely on PHP, including through suppliers, and ensure that affected systems are secured urgently. They will also wish to consider their obligations to notify their regulator under NIS2 or potentially the EU Cyber Resilience Act, or (where personal data may have been compromised), the GDPR. 

Emergency fixes were released on 21 October. The vulnerabilities, collectively known as “PHP2Shell” (CVE-2026-109618 and CVE-2026-109619), could allow an attacker to run their own code on an affected server without logging in. It goes without saying that this creates a wide range of serious potential risks including data theft, disruption and further attacks within the organisation’s network.

The problem lies in PHP itself. A website or application may therefore be exposed even if there is nothing wrong with its own code. The PHP security advisory calls for immediate updates across installations serving web requests. The risk is sufficiently serious that it needs immediate attention. 

What the security agencies are saying

The UK’s National Cyber Security Centre (NCSC) and the US agencies CISA, NSA and FBI all issued guidance on 21 October. Their central message is consistent: identify affected systems, apply the fixes urgently and (importantly) investigate signs of compromise.

For UK organisations, the NCSC guidance is the natural starting point. It prioritises systems accessible from the internet and highlights products and services that incorporate PHP. Where an update cannot be applied immediately, it points to temporary mitigations and says organisations should consider taking systems offline if those measures cannot be applied, or would take too long. NHS England has also issued a sector alert, assessing future exploitation as highly likely.

The US guidance reinforces the need to deal with older, unsupported software and to preserve evidence. CISA urges organisations to take systems offline if they cannot be updated. The NSA recommends enhanced logging and replacement of unsupported PHP. The FBI advises isolating compromised systems, preserving logs and reporting incidents through its relevant channels.

What organisations should do now (containment) 

The guidance translates into five immediate priorities.

• Find out where PHP is used. Look beyond your websites. PHP may be embedded in software, appliances and services without being obvious to the organisation using them. The Dutch NCSC’s product inventory is a useful cross-check.
• Apply the fixes urgently. Prioritise systems accessible from the internet, but check all affected installations. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Some software distributors provide their own patched packages. Technical teams should also confirm that running services have been restarted so the fixes take effect.
• Address unsupported versions. PHP 8.1 and earlier no longer receive official releases. Limited fixes are available for some older versions, including through certain suppliers, but organisations should establish a route to supported software. Systems that cannot be updated should be taken offline pending remediation.
• Contain the risk where patching is delayed. Consider taking affected systems offline or restricting access while fixes are applied. PHP has published temporary configuration changes, but warns that these address only particular attack routes and do not make an installation safe. Additional firewall rules are also an interim measure.
• Get clear answers from suppliers. Ask hosting providers, software providers and appliance vendors whether their services are affected, what action they have taken and when any outstanding fixes will be applied. Obtain written confirmation rather than assuming the issue is being handled elsewhere.

Patching is not the end of the response (further investigation and notifying regulators)

Applying the fix does not establish whether an attacker has already gained access. Tenable reports that Amazon Threat Intelligence recorded an exploitation attempt on 17 October, four days before disclosure. Investigations should therefore look back at least that far. Systems exposed during that period should be treated as potentially compromised while checks are carried out.

Security teams should look for unusual commands, unexpected files and suspicious connections from affected servers. Preserve web server and PHP logs before routine deletion or overwriting removes them. Those records may be essential to establishing what happened, when it happened and which information or services were affected.

Legal will need to assess whether a regulatory notification is required. Where a personal data breach has occurred, Article 33 UK GDPR requires the controller to notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Organisations within the scope of UK or EU NIS regimes should also check the relevant incident reporting thresholds. Under NIS2, an early warning is required without undue delay and within 24 hours of becoming aware of a significant incident, subject to the applicable national rules.

Where you are a manufacturer of a commercial ‘product with digital elements’ placed on the EU market, if that product contains PHP software, you may be caught by Article 14 of the EU Cyber Resilience Act’s vulnerability reporting obligations. 

Legal and security teams should address these questions alongside remediation. If a system is kept online with temporary safeguards, record why that decision was taken, the risks considered and who approved it. A clear record of the response will matter if the organisation later needs to explain its decisions to a regulator or customer.

Sources

• CISA, Critical Vulnerabilities in PHP Require Immediate Patching (21 October 2026)
• NSA, NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities (21 October 2026)
• FBI Cyber Division, statement on X (21 October 2026)
• NCSC, Critical security issue affecting PHP (21 October 2026); pre-release snapshot (PDF)
• NHS England Digital, Critical Vulnerabilities in PHP (PHP2Shell), CC-4875 (21 October 2026)
• PHP, Security advisory: critical remote code execution vulnerabilities (21 October 2026); GitHub advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL, php2shell operational repository
• Tenable, php2shell FAQ (updated 22 October 2026), for the disclosure timeline and Amazon Threat Intelligence's 17 October observation
• BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws (21 October 2026), for PHP's interim mitigations