21 October 2026

PHP2Shell: What you need to know about the recently disclosed PHP vulnerabilities

We have informed all our Managed Services customers who use PHP about PHP2Shell. If you use these services, you will already have heard from us.

The BACS advises the immediate installation of the security updates

On 21 October 2026, the Federal Office for Cyber Security (BACS) issued a warning about two critical vulnerabilities in PHP. Attackers can exploit these to execute malicious code on affected servers without logging in. The vulnerabilities are listed under the identifiers CVE-2026-109618 and CVE-2026-109619.

The recommendation is clear: affected systems should be updated immediately. In addition to web servers, applications and devices that use PHP as an integrated component should also be checked.

The security updates are now available. The vulnerabilities are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Install the patched version for your respective version line or the relevant security update from your operating system or product provider. You can find the latest information in the PHP Project’s announcement, the BACS advisory and on the BACS Cyber Security Hub (CSH).

PHP isn’t just in your websites

WordPress, Drupal and Magento are written in PHP, as are many customer portals and booking systems. Management interfaces for hosting environments, network appliances and web interfaces for manufacturers’ products also frequently include their own PHP installation. This applies even if the product documentation does not mention it.

Therefore, it is not enough simply to update your own servers. The BACS advises checking with software suppliers and service providers to clarify which products are affected and which updates are required. If PHP is integrated into an appliance, you must wait for the manufacturer’s update.

What you should do now

The BACS recommends identifying affected systems, installing the updates immediately, restarting any running PHP services, verifying that the issue has been resolved, and checking the systems for any anomalies. Priority should be given to systems accessible from the internet, as well as applications with access to particularly sensitive data or critical business processes. Here’s how to implement this in practice:

  • Identify all systems running PHP. Start with anything accessible from the internet: public websites, microsites, campaign landing pages, customer portals, APIs and remote access gateways. Next, check the internal systems. Also take into account staging and development servers, older agency websites not under internal management, and containers whose base images contain a PHP runtime environment.

  • Document the version and who is responsible. For each system, record which version of PHP is running, how it was installed and who is responsible for updates. The installation may, for example, have been carried out via an operating system package, a container image, a management interface or a vendor appliance. This will tell you whether your own team can take action or whether you need to wait for an update from your Linux distribution or a vendor.

  • Check for versions whose support has expired. The PHP project only provides security updates for supported version branches. If you are using an older version such as PHP 7.4 or 8.0, you may not receive a patch directly from the PHP project. Some Linux distributions incorporate security fixes into existing package versions. An unchanged PHP major version therefore does not automatically mean that a patch is missing; the exact package version and the provider’s specifications are decisive. For older versions, the BACS advises asking the provider for security fixes or switching to a supported version.

  • Decide which systems you can take offline. If an immediate update is not possible, the BACS recommends restricting access to the affected applications to only those people and systems that actually need it. For critical applications, you should check whether a temporary disconnection from the internet or a shutdown is necessary. Determine which systems you can shut down, who authorises this, and how you will inform your customers. This ensures that no one has to make this decision under time pressure.

  • Monitor your systems that are accessible from the internet. Ensure that the log data from your PHP web servers is forwarded to those responsible for monitoring your environment and that they are aware of the current security alert.

What you should do after the update is released

  • Read the security advisory and check which of your systems are affected.

  • Update the systems accessible from the internet first, followed by the internal ones. Test the updates wherever possible. When doing so, weigh up the risk of a brief delay against the risk of remaining vulnerable.

  • Restart the PHP services after the update. If you only update the package, the old version may still be running in memory under PHP-FPM or the web server. Containers may need to be rebuilt and redeployed.

  • Check regularly with your vendors and hosting providers. When integrated PHP installations are updated depends on their schedule, not yours. The BACS recommends obtaining confirmation that the fix has been applied for hosting services and vendor products.

  • Then carry out another scan. This will allow you to check that the updated version is actually running and that no installation has been overlooked.

How Claranet can support you

The BACS’s recommendations essentially boil down to two questions: Do you know where PHP is running on your systems? And would you notice if someone were to exploit one of these vulnerabilities against you? We support businesses with both of these tasks on a daily basis.

  • Inventorying systems
    Our External Attack Surface Monitoring service identifies the systems within your organisation that are accessible from the internet. This also includes systems that are no longer listed in your IT inventory. CREST-accredited analysts review the results and report on them monthly. This makes the service a practical starting point for comprehensively identifying all PHP systems.
  • Testing systems and re-checking them after updates
    Continuous Security Testing combines round-the-clock vulnerability scans with manual penetration tests carried out by our security team. As soon as details of the vulnerabilities are published and appropriate testing procedures are available, you can use them to determine which systems are affected and whether your patches were effective.
    Read also about how REaD Group protects customer data with Continuous Security Testing.
  • Detecting attacks
    The BACS advises examining logs and affected systems for unusual requests, crashes, modified files and unexpected processes, as an update does not remedy a compromise that has already occurred. Our Managed Detection and Response service provides you with a CREST-accredited Security Operations Centre (SOC). It is staffed 24 hours a day, every day of the year, and works with Microsoft Sentinel or SentinelOne. Our analysts investigate suspicious activity and support you in your response. This is particularly important during the period between the release of a patch and the updating of all systems.
  • Limiting the attack surface during updates
    A Web Application Firewall (WAF), which filters traffic to web applications, is no substitute for an update. The BACS also emphasises that interim measures only reduce individual attack vectors and that a WAF alone is not sufficient. However, it can make attacks more difficult whilst you update your systems in stages. Our DDoS Protection and Web Acceleration service provides a layer of protection for your web applications. For software providers, we also offer Managed WAF as well as DDoS and API protection, with round-the-clock monitoring and adjustment of protective measures. DDoS refers to attacks designed to overload services by flooding them with a large number of distributed requests.
  • Keeping your platform up to date
    If your websites and applications run on infrastructure operated by Claranet as part of Managed Public Cloud or Managed Private Cloud, please contact your service team. Work with them to clarify which measures are required for the PHP update in your environment.

What remains important beyond this security advisory

Critical vulnerabilities in widely used platforms will continue to arise in the future. Organisations that are best equipped to deal with this are those that already know which systems they are running, who is responsible for them, and how quickly they can implement changes. If this security advisory has highlighted gaps in any of these areas, now is the time to address them.

Would you like to find out where PHP is used in your IT landscape, or how quickly you could respond to the next security alert? Contact our team or find out more about our cybersecurity services.

Sources

Speak to our experts about your needs today