Blog

Critical vulnerabilities in PHP: What you need to do

Two critical vulnerabilities in PHP, known as PHP2shell (CVE-2026-109618 and CVE-2026-109619), could allow an attacker to execute code on a web server without logging in. All PHP installations handling web traffic are affected. Update immediately, prioritising internet-facing systems.

• Five actions to prioritise
• Requirements for effective protection
• Suspect a breach?

What happened?

PHP powers a large part of the web, from WordPress and Drupal to custom-built systems. On 21 October, the PHP project released emergency security updates for two critical vulnerabilities, known as PHP2shell. Details had leaked the day before, ahead of the planned disclosure.

What is the risk?

An attacker can execute arbitrary code on a web server with a single HTTP request, without logging in. The code runs with the permissions of the web service. From there, an attacker could gain access to data, passwords and keys handled by the service, and potentially move further into the environment.

How easy is it to exploit?

The vulnerabilities are in the PHP core itself, not in the application. The attack takes place before any application code is executed. This means that having an up-to-date WordPress or Drupal installation is not enough if the underlying PHP version is vulnerable. Code claiming to exploit the vulnerabilities is already circulating publicly.

How serious is it?

Critical, CVSS 9.2. The vulnerable code has been present since PHP 5.4. Palo Alto Networks has identified more than 22 million exposed instances. Cisco Talos estimates that around half of all PHP systems are running unsupported versions.

Is it being exploited?

Security companies are reporting exploitation attempts, but there is not yet any official confirmation. The vulnerabilities are not listed in CISA’s Known Exploited Vulnerabilities catalogue. Follow the status here: CISA Known Exploited Vulnerabilities Catalog. At least one European authority has taken its website offline as a precautionary measure.

Update now. Do not wait for official confirmation.

Summary
Vulnerabilities	CVE-2026-109618 (RCE via out-of-memory corruption), CVE-2026-109619 (RCE via stale global state)
Severity	Critical, CVSS v4.0 9.2 for both
Affected environments	PHP installations handling web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Highest risk for mod_php.
Fixed in	PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
Exploitation	Attempts have been reported but are not officially confirmed. Not yet in CISA KEV.
Workaround	No complete workaround. Updating is the only reliable remediation.

Five actions to prioritise

1. Identify where you are running PHP
   Inventory web servers, applications, containers, hosting environments, appliances and third-party products with embedded PHP. PHP is often not visible in asset inventories. Document the version, exposure and responsible owner. Start with internet-facing and business-critical systems.
2. Update and verify
   Install a fixed version from PHP or your vendor. Linux distributions and LTS providers received the patches in advance. Restart all PHP workers. Check the version in the environment that is actually serving web traffic, as the command-line version may refer to a different installation.
3. Address unsupported versions
   PHP 8.1 and earlier no longer receive fixes from the PHP project. Upgrade, preferably to 8.4 or 8.5, as PHP 8.2 reaches end of life on 31 December 2026. If an immediate upgrade is not possible, ask your vendor for backported fixes and assign an owner and a target date.
4. Limit exposure until the update is complete
   Remove unnecessary public access and isolate services that cannot be updated immediately. The PHP project describes temporary hardening measures that reduce some attack vectors but do not provide complete protection. Setting session.upload_progress.enabled=0 alone is not sufficient.
5. Monitor and investigate
   Look out for recurring PHP crashes, out-of-memory errors, unexpected processes, new executable files and unusual outbound connections. Retain logs from the period before the update as well.

→ Read more: PHP project security advisory and technical instructions 

Compensating controls in the meantime

Patching takes time, particularly for older systems. In the meantime, IPS and virtual patching at the firewall can reduce the risk for published PHP applications. They are not a substitute for updating.

Palo Alto Networks

• Frontier Virtual Patching (ATP Plus) on PAN-OS 12.2.4 or later: Threat ID 543004, published on 20 October, ahead of the public release.
• Threat Prevention: Threat IDs 543004, 97622, 97623, 97624 and 97625. Requires Applications and Threats content version 9162 or later.

Cisco Secure Firewall

• Snort SIDs 67359, 67360 and 67375, also available in the Snort Community Ruleset.

Requirements for effective protection

An enabled signature does not necessarily mean that the application is protected. Check the following:

• Traffic passes through inspection. Traffic to the application must pass through the firewall or rule where the protection is applied.
• Encrypted traffic is inspected. Without inbound TLS decryption, or inspection after TLS termination, the firewall cannot see the attack. Most web applications use HTTPS.
• Protection is blocking. The signatures must be enabled with the action set to block or reset in the profile or policy applied to the rule.
• Content is up to date. The content and rule versions must match those specified by the vendor.
• Effectiveness is verified. Check the logs to confirm that traffic is being inspected and that the signatures can trigger.

Vendors state that their protections provide coverage against the vulnerabilities. It is too early to say how comprehensive that protection is. Enable it, but continue patching.

Cisco & Palo Alto Networks

The vulnerabilities may also affect vendors’ own products. We are monitoring Cisco and Palo Alto Networks particularly closely. Vendor advisories are the source for current product status and are updated on an ongoing basis.

Palo Alto Networks

PAN-OS and Panorama are affected. Fixed versions have not yet been released. Prisma Access and Cloud NGFW are not affected.

The risk is highest if the management interface is accessible from the internet. This should never be the case. Restrict access to trusted internal addresses, preferably via a dedicated jump host. Palo Alto specifies additional configuration requirements for Threat Prevention to protect management traffic.

→ Read more: Palo Alto Networks Security Advisory

Cisco

Cisco is investigating which products and cloud services are affected. No products are currently confirmed as vulnerable. Products under investigation include ISE, Catalyst Center, Catalyst SD-WAN Manager, Expressway, Secure Access and Umbrella.

“Under investigation” means that the assessment has not yet been completed.

→ Read more: Cisco Security Advisory

Suspect a breach?

Patching does not remove an attacker who has already gained access. Our Incident Response team can help investigate suspicious activity and contain the damage.

Sources

• PHP: Security advisory, update now
• Palo Alto Networks Security Advisory CVE-2026-109618
• Unit 42 Threat Brief
• Cisco Security Advisory
• Cisco Talos: Two critical RCEs in PHP core
• CERT-EU Security Advisory 2026-018
• CISA Known Exploited Vulnerabilities Catalog

Have questions?

Get in touch. We’re here to help.

Contact us

About the author