PHP2Shell: what you need to know about the leaked PHP flaws

What the NCSC has said

On 21 October 2026 the National Cyber Security Centre (NCSC) published an alert encouraging UK organisations to prepare for immediate updating of any system that uses PHP. The advice is blunt. If you cannot fix an affected system straight away, consider taking it offline until you can.

The alert follows an announcement from the PHP project on 20 October. A security release is scheduled for 14:00 UTC (15:00 BST) on Wednesday 21 October 2026, fixing two critical vulnerabilities that are both rated 9.2 under CVSS v4.0. The PHP team has said it may release earlier if details of either flaw become public, or if there is evidence of exploitation.

At the time of writing, the affected versions, the fixed versions and the CVE identifiers have not been published. They are due with the release itself, so check the PHP project announcement and the NCSC alert for the latest position. We will update this post once the details are out.

Where you might be running PHP

WordPress, Drupal and Magento are all written in PHP, as are many customer portals and booking systems. Hosting control panels, network appliances and vendor web interfaces often include their own copy too, even if the product documentation doesn't say so.

This is why the NCSC asks organisations to watch for updates from third-party vendors as well as patching their own servers. If PHP is built into an appliance, you have to wait for the manufacturer to release an update.

What to do before the release

Once the fix is published, attackers can compare it with the previous version to find the flaw. Internet-facing systems that haven't been updated are most at risk in the days after release, so it pays to prepare now. The NCSC makes five recommendations, and this is how we would apply them.

• Find every PHP system. Start with anything that faces the internet: public websites, microsites, campaign landing pages, customer portals, APIs and remote access gateways. Then work inwards. Include staging and development servers, old sites built by agencies that nobody internally owns, and containers whose base images bundle a PHP runtime.
• Record the version and the owner. For each system, note the PHP version, how it was installed (operating system package, container image, control panel or vendor appliance) and who is responsible for updating it. On release day this tells you whether you are waiting on your own team, your Linux distribution or a supplier.
• Look for end-of-life versions. The PHP project only ships fixes for supported branches. If you are running an older release such as PHP 7.4 or 8.0, there may be no upstream patch for you. Some Linux distributions backport security fixes to the versions they package, so check with your vendor, but plan an upgrade either way.
• Decide now what can go offline. The NCSC is clear that taking a system offline is a reasonable step if it cannot be fixed. Agree in advance which systems you can switch off, who can authorise it and how you will tell customers, so nobody has to make that call under pressure.
• Watch your internet-facing systems. Make sure logs from your PHP web servers reach whoever monitors your environment, and that they know this alert is live.

What to do once the fix is out

• Read the advisory and confirm which of your systems are affected.
• Patch internet-facing systems first, then internal ones. Test where you can, but weigh the risk of a short delay against the risk of staying exposed.
• Restart PHP services after updating. Upgrading the package on its own can leave the old version running in memory under PHP-FPM or the web server.
• Keep checking with your vendors and hosting providers. Bundled copies of PHP will be fixed on their timetable, not yours.
• Scan again afterwards to confirm the patched version is the one running and that nothing was missed.
   

How Claranet can help

Most of what the NCSC asks for comes down to two questions. Do you know where PHP is running? Would you notice if someone used one of these flaws against you? Both are areas where we support organisations every day.

• Finding what you have
  Our External Attack Surface Monitoring service maps the systems you expose to the internet, including the ones that have dropped off your asset register. CREST-accredited analysts validate what is found and report on it every month, which makes it a practical starting point for the NCSC's first recommendation.
• Testing it, then testing it again
  Continuous Security Testing combines round-the-clock vulnerability scanning with manual penetration testing by our security team. Once the details of these vulnerabilities are published and checks for them are available, it gives you a way to see which systems are affected and to confirm your patches have worked. You can read how REaD Group uses Continuous Security Testing to protect client data. Where an application needs a closer look, our CREST penetration testing team can assess it in depth.
• Watching for attacks
  The NCSC asks organisations to monitor internet-facing PHP systems for malicious activity. Our Managed Detection and Response service gives you a CREST-accredited security operations centre, staffed 24 hours a day, every day of the year, on Microsoft Sentinel or SentinelOne. Our analysts investigate suspicious activity and help you respond, which counts most in the window between a patch being released and every system being updated.
• Reducing exposure while you patch
  A web application firewall is no substitute for the update, but it can make attacks harder while you work through your estate. Our DDoS Protection and Web Acceleration service puts a protective layer in front of your web applications. For software vendors, we also offer managed WAF, DDoS and API protection with 24/7 monitoring and tuning.
• Keeping the platform current
  If your websites and applications run on infrastructure Claranet manages through our Managed Public Cloud or Managed Private Cloud services, speak to your service team to confirm how the PHP update applies to your environment.

Beyond this alert

Critical flaws in widely used platforms will keep coming. The organisations that cope best already know what they run, who owns it and how quickly they can change it. If this alert has exposed gaps in any of those, now is the time to close them. Our earlier posts on patching and on the top 10 web application vulnerabilities we found in 2024 are worth reading alongside this one.

If you would like help working out where PHP sits in your estate, or how quickly you could respond to the next alert, get in touch with our team or find out more about our cybersecurity services.

Sources

• NCSC, Critical security issue affecting PHP, 21 October 2026.
• The PHP Group, announcement of the upcoming security release, 20 October 2026.