If your organisation runs a website, a customer portal or an internal web app, there's a good chance PHP is working away underneath it. On 21 October 2026, the PHP project released urgent security updates for two critical vulnerabilities in PHP itself, known together as PHP2Shell (CVE-2026-109618 and CVE-2026-109619).

Both carry an official CVSS 4.0 score of 9.2, and early attack traffic has already been publicly reported. We're advising clients and partners to treat this as a priority. In this post, we'll explain what PHP2Shell is in plain English, who's affected, and what you should do now.

What is PHP2Shell?

PHP2Shell is a pair of flaws in the PHP interpreter, the engine that runs PHP code on a web server. Successful exploitation can let an attacker run their own code on the server, with the same privileges as the PHP web worker. The demonstrated attacks don't require the attacker to log in first.

Think of a PHP server as a busy kitchen, where the same cooks handle order after order. Each order should start on a clean workstation. These bugs mean that, in certain conditions, the workstation isn't properly cleared. One flaw (CVE-2026-109618) can leave things half set up when the server runs out of memory mid-request. The other (CVE-2026-109619) can leave scraps from a previous request lying around for the next one. A skilled attacker can deliberately create that mess, then send a follow-up request that tricks the server into doing what they want.

The vulnerabilities may also expose sensitive data held in PHP process memory, which is a quieter risk that doesn't need full code execution.

Who is affected?

Because the flaws sit in PHP itself, this isn't just a WordPress, Drupal or Joomla problem. Laravel, Magento, Moodle, bespoke applications and other services running on an affected PHP version may also be at risk.

How exposed you are depends on how PHP is deployed. Apache with mod_php presents the clearest demonstrated risk. PHP-FPM is also affected, although exploitability depends on your PHP version, configuration, application behaviour and architecture.

These are the fixed releases for each supported PHP branch:

PHP 8.1 and earlier are end of life upstream. If you're on an older version, check whether your operating system or long-term support vendor has supplied a backported fix, or plan an upgrade to a supported branch. It's also worth knowing that Linux distributions such as Debian, Ubuntu, RHEL and SUSE often backport fixes without changing the main version number. An old-looking version isn't necessarily vulnerable, so check the full package version against your vendor's advisory.

Is it being exploited?

Researchers have demonstrated successful exploitation, and early attack traffic targeting PHP2Shell has been publicly reported. That doesn't mean every attempt has led to a compromise. But with technical details and proof-of-concept material now available, wider exploitation is increasingly likely, and the window to patch calmly is closing.

A web application firewall (WAF) can help by blocking known request patterns, and several providers have published rules. It isn't a substitute for patching, though. Different exploitation paths and changing request patterns may slip past narrow signatures, so treat a WAF as time bought to patch, not as the fix.

What should you do now?

Applying the official fix is the only complete remediation. Configuration changes can reduce exposure to specific attack paths, but none fully protects an unpatched server. We recommend working through these steps:

1. Identify every system running PHP, including software that bundles it without making it obvious, and start with anything internet-facing.
2. Apply the fixed upstream release or your vendor's patched package.
3. Restart PHP-FPM, Apache and any other long-running PHP workers, then confirm your applications are using the newly patched binaries.
4. Review web server, PHP, reverse proxy and WAF logs for unusual multipart requests, fatal errors, memory exhaustion and unexpected worker behaviour.
5. Hunt for web server or PHP processes launching shells, downloaders or unexpected administrative tools.
6. If you suspect a compromise, preserve evidence, isolate or rebuild affected systems, and rotate any credentials the PHP application could access.

If you're on shared hosting, select the newest PHP version in your control panel and ask your host to confirm their build includes the fix.

How Cyber Vigilance can help

Patching only closes the gap when every affected instance has been found and updated. For most teams, the hard part isn't applying the fix. It's being confident they've found everything, and proving the fix actually worked.

As a Horizon3.ai partner, we use the NodeZero autonomous security platform to safely test environments the way a real attacker would. That shows you what's genuinely exploitable, rather than what's theoretically vulnerable, and lets you re-test after remediation to confirm the door is closed.

We're working closely with Horizon3 on its NodeZero Rapid Response for PHP2Shell. Please complete the form below for support from Cyber Vigilance.

In the meantime, our in-house technical team can help you:

• Identify systems running affected PHP versions across your estate
• Prioritise remediation based on exposure and business risk
• Hunt for signs of suspicious activity
• Validate that your fixes have worked

Speak to us

Not sure whether you're exposed, or want a second pair of expert eyes on your remediation? Speak to the Cyber Vigilance team today and we'll help you find, fix and verify.

Sources

• Horizon3.ai: PHP2Shell, CVE-2026-109618 and CVE-2026-109619
• PHP Security Advisory
• PHP advisory: CVE-2026-109618
• PHP advisory: CVE-2026-109619
• PHP2Shell Response Guide FAQ (independent)

‍