php2shell: How to Check if Your Business Is Exposed to the Critical PHP Vulnerabilities

Information about two critical PHP vulnerabilities circulated publicly on 20 October 2026, ahead of the coordinated release of security updates. PHP released fixes on 21 October, and Cloudflare reported attack traffic targeting the vulnerabilities before the official release.

If your organisation runs a website, customer portal or business application built on PHP, identify which systems use it and confirm that the security fixes have been applied. The UK’s National Cyber Security Centre is urging organisations to identify PHP installations and update affected systems, prioritising those exposed to the internet.

PHP is used by about 70% of websites whose server-side programming language is known, including sites built with WordPress, Drupal, Joomla and Magento. These vulnerabilities affect the PHP runtime, so updating a website’s plugins or application code alone will not resolve them.

This guide explains how to check your systems, confirm whether they are patched and deal with older PHP installations.

What are CVE-2026-109618 and CVE-2026-109619?

They are two vulnerabilities in PHP’s core, both rated Critical, with a CVSS v4.0 score of 9.2:

• CVE-2026-109618: out-of-memory corruption. PHP can leave internal request data partly initialised when a memory allocation fails. Subsequent cleanup can then use that invalid data.
• CVE-2026-109619: stale global state. A PHP worker can retain references to memory that has already been freed. A later request handled by the same worker may access that stale state.

Under suitable conditions, an unauthenticated attacker can exploit these flaws to execute code with the permissions of the PHP worker. The consequences can include data theft, changes to application files and further attacks against accessible systems. Depending on the attack path, the flaws can also expose sensitive information from process memory or disrupt services.

The timeline

Date	What happened
20 October 2026	Information about the vulnerabilities circulated publicly. PHP brought forward its advance notice and the planned security release.
21 October 2026, before the official release	Cloudflare reported observing attack traffic targeting the vulnerabilities.
21 October 2026	PHP’s accelerated security release delivered fixes in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
21 October 2026	Distribution maintainers, including Ubuntu and AlmaLinux, published patched packages, including backports for older PHP branches.

The PHP Foundation’s account of the release explains the disclosure timeline. Package availability is documented in the Ubuntu and AlmaLinux notices.

Exploitation attempts have been reported. Apply the fixes promptly and review exposed systems for suspicious activity.

Which PHP versions contain the fixes?

The first fixed upstream releases are:

Your PHP branch	First fixed upstream release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 and older	No normal supported upstream release; see the guidance on older branches below.

These numbers apply to releases supplied by the PHP project. Some distributions and hosting providers backport fixes to packages that retain an older PHP version number.

For example, Ubuntu identifies 8.1.2-1ubuntu2.28 and 8.3.6-0ubuntu0.24.04.13 as patched packages for Ubuntu 22.04 and 24.04 respectively. An earlier-looking version number does not, by itself, prove that a vendor-maintained package remains vulnerable. Check the vendor’s security notice and full installed package revision.

Use the fixed release for your branch, a later release containing the fixes, or a vendor-confirmed backport addressing both CVEs.

Who is exposed?

Treat all PHP installations serving web requests as potentially at risk until you apply the relevant fixes. PHP’s advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Practical exploitability depends on the PHP version, server configuration and application behaviour. PHP identifies Apache with mod_php as the highest risk, because demonstrated attacks can trigger vulnerable behaviour before application code runs, without authentication. PHP-FPM can also be affected through application-level attack paths.

Check the systems you actively maintain and those that may be easier to overlook:

Where to look	What to check
WordPress, Drupal, Joomla and Magento sites	Confirm the PHP runtime and patch status for each site.
Shared hosting and control panels such as cPanel and Plesk	Check every domain and PHP runtime, including sites managed by an agency.
Customer portals, booking systems and custom applications	Identify who maintains the application and its underlying PHP installation.
Vendor appliances and Windows software	Ask whether the product bundles PHP, including php.exe or php-cgi.exe, and whether a vendor update is required.
Staging, test and campaign websites	Include old or infrequently used environments in your checks.

Prioritise internet-facing systems, while also including internal applications and bundled PHP installations in your inventory.

How to check your PHP version

The quickest method depends on your access:

1. On the server: run php -v to identify the command-line PHP version. Also check the runtime used by each website or service, because it can differ from the command-line version.
2. In your hosting control panel: check each domain’s PHP settings. In cPanel, look for MultiPHP Manager or Select PHP Version, depending on the hosting setup. In Plesk, open the domain’s PHP Settings.
3. In WordPress: go to Tools → Site Health → Info → Server and find PHP version. This is the route documented by WordPress.
4. Through your provider: ask your host, agency or software vendor which PHP runtime and package build each service uses, whether both CVEs have been fixed, and whether any restart or redeployment is outstanding.

The PHP version alone may not establish patch status. Where a provider backports fixes, compare the complete package revision with its security advisory. AlmaLinux, for example, explicitly advises checking its package revision instead of relying on php -v.

Avoid uploading a publicly accessible phpinfo() page to check a live site. It can disclose detailed configuration information. Use a local or access-controlled method and remove any temporary diagnostic page afterwards.

External vulnerability scanning can help identify exposed services and signs of outdated PHP. Combine the results with your asset inventory and provider confirmation: a remote scan cannot reliably establish the PHP version or patch status of every system. PHP can suppress identifying information, and vendor backports can make version-based checks misleading.

Is my WordPress site affected?

Potentially. WordPress runs on PHP, so the runtime underneath the site needs to contain the fixes. Keeping WordPress, themes and plugins updated remains important, but those updates alone do not resolve these PHP vulnerabilities.

Work through the following:

• Check the PHP version under Tools → Site Health → Info → Server.
• Confirm that the site uses a fixed upstream release from the table above, a later release containing the fixes, or a vendor-confirmed backport addressing both CVEs.
• If you use managed WordPress hosting, check the host’s security updates or contact support for confirmation.
• Confirm that the update has reached every relevant site and that the patched runtime is actually running.
• If an old plugin or theme prevents a PHP upgrade, arrange the compatibility work and ask your provider about a patched package or temporary access restrictions in the meantime.

Cloudflare’s guidance also makes clear that the PHP runtime itself needs updating. A website security plugin does not establish that the underlying PHP installation has been fixed.

Running PHP 8.1 or older?

PHP 8.1 and earlier have reached the end of support from the PHP project. They do not receive normal supported upstream releases. However, because of the severity of these vulnerabilities, the PHP security team supplied minimal source backports for PHP 7.4, 8.0 and 8.1.

Some distributions and hosting providers also maintain patched packages for older branches:

• Ubuntu has published fixes for its supported releases, including older PHP packages. Availability depends on the Ubuntu release and its support arrangements.
• AlmaLinux has released patched packages for every PHP stream on AlmaLinux 8, 9 and 10, including retired streams.

Check the Ubuntu notice, AlmaLinux notice, or your own provider’s advisory for the exact package you need.

A backported fix can address these vulnerabilities, but it does not restore upstream PHP support. Confirm whether your distribution or hosting provider will continue supplying security updates for that package. Plan an upgrade where ongoing support is unavailable.

When moving to a newer PHP branch, check application compatibility on a staging copy. If the system is no longer needed, retire it and remove its public access.

What if you cannot patch immediately?

The NCSC’s current guidance recommends following PHP’s temporary mitigation advice where immediate updating is not possible, and considering taking affected systems offline if those mitigations cannot be applied or would take too long.

Until the security fixes are installed:

1. Follow the official temporary mitigation guidance. Ask your administrator or hosting provider to assess and apply the measures in the PHP security advisory. These reduce exposure to particular attack paths; they do not provide a complete fix.
2. Reduce access where practical. Remove public access or restrict the service to trusted users through a VPN or network allowlist.
3. Consider taking the affected system offline if effective interim measures cannot be applied promptly. This may be necessary even when the system is still needed.

A web application firewall with protections specifically covering these vulnerabilities can provide an additional temporary measure. It does not replace the PHP update. Ensure that public access cannot bypass the WAF or other access controls by connecting directly to the origin server.

Cloudflare has published details of its PHP2Shell protections and continues to recommend patching PHP.

Your PHP2Shell action checklist

Work through these steps, starting with internet-facing systems:

• List every system that uses PHP, including vendor software, containers, internal applications and old microsites.
• Record the PHP runtime used by each application and the full package revision where applicable.
• Apply the appropriate fixed PHP release, a later release containing the fixes, or a vendor-confirmed backport addressing both CVEs.
• Restart every affected PHP runtime, including PHP-FPM, Apache with mod_php and other long-running processes. For containerised deployments, rebuild or obtain images containing the fixes and redeploy the affected services.
• Verify that each website and service is using the patched build.
• Confirm ongoing security support for older PHP packages; upgrade or retire systems where support is unavailable.
• Ask your web agency and hosting provider to confirm in writing that the relevant systems are patched.
• Review available web server and security logs for suspicious activity, and monitor for unexpected behaviour such as PHP launching command shells or download tools.
• If you cannot update or disable a system immediately, assess it for evidence of compromise and installed backdoors.
• If compromise is suspected, isolate the affected system, preserve logs and other evidence, and get specialist help before rebuilding.

Installing an update can leave existing processes running the old interpreter until they are restarted, as Ubuntu’s update guidance explains. Applying the fixes also does not remove any backdoor installed before patching; the NCSC recommends checking for evidence of compromise where updating or disabling the system cannot happen immediately.

How Sencode can help

Forgotten websites and bundled PHP installations can be easy to miss during patching. Establishing what you run, who maintains it and whether the fixes have been applied gives you a practical starting point.

Sencode is a CREST-accredited penetration testing company. We can help through:

• External vulnerability scanning, which helps identify exposed services and potential weaknesses so you can prioritise checks and remediation with your hosting provider or IT team.
• Web application penetration testing, which examines how an attacker could compromise your applications and what they could access.

Use external assessment alongside your asset inventory and provider confirmation to establish PHP patch status.

A note for charities

Charities with limited IT resources may need help checking which PHP versions their websites and software use. Start by asking your hosting provider or web agency to confirm whether the fixes for both vulnerabilities have been applied.

The checks in this guide apply equally to charities. Sencode also offers:

• Free attack surface reviews for registered charities based in or serving the North East of England, subject to availability. Applications are currently open for reviews in January–March 2027.
• 20% off any Sencode service for registered charities across the UK.

Contact your hosting provider promptly to confirm patch status while arranging any further assessment.