Critical PHP RCE: What Hosting Providers Should Do Now

Two critical PHP flaws require immediate action

CVE-2026-109618 and CVE-2026-109619 affect PHP servers exposed to the internet. Both are rated Critical, with a CVSS score of 9.2. Exploiting them can let an unauthenticated remote attacker run code on the server.

The vulnerabilities relate to how PHP handles request-owned data and memory:

• CVE-2026-109618: Out-of-memory handling can interrupt PHP while request data is only partially initialized. During cleanup, invalid data may then be treated as valid.
• CVE-2026-109619: Request-owned state can remain after its memory has been freed. A later request handled by the same worker may then use that state.

The affected versions range from PHP 5.4 through 8.5.11. Fixed versions are:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older will not receive an upstream fix. These versions should be treated as end-of-life and migrated to a supported release.

National CERTs, including the UK NCSC and Swiss NCSC, as well as cloud providers, are advising immediate patching.

What hosting providers should do now

1. Upgrade PHP to a fixed release

Identify every web-facing PHP installation and upgrade supported versions to the appropriate fixed release. Do not assume that updating one system covers all shared, VPS or managed hosting environments.

Customers running PHP 8.1 or older should be prioritised for migration to a supported PHP version, because those releases will not receive an upstream fix.

2. Restart PHP workers

After upgrading PHP, restart the relevant PHP workers. This ensures that running worker processes are replaced and the fixed code is active.

3. Inventory end-of-life PHP versions

Review hosting accounts, websites, WordPress installations, other CMSs and control panels for PHP versions that are no longer supported. PHP is widely used across shared, VPS and managed hosting, and customers may not upgrade immediately without provider assistance.

4. Check for signs of compromise and backdoors

Because these vulnerabilities can enable remote code execution, review affected systems for backdoors and other unexpected changes. Patching reduces ongoing exposure, but it does not establish whether a server was already targeted or compromised.

BitNinja rules 410054 and 410055

BitNinja released two WAF rules for WAF2 and WAFPro customers to help reduce exposure while systems are being patched.

Rule 410054 blocks requests linked to exploit-tool traffic targeting these PHP vulnerabilities when either of the following is present:

• The User-Agent starts with php2shell-.

• The multipart boundary matches suspicious scanner names seen in exploit-tool traffic tagged for CVE-2026-109618 and CVE-2026-109619.

Normal browser upload boundaries do not match these patterns, so legitimate uploads should not be affected.

Rule 410055 blocks form fields with names longer than 8 KB. The researcher’s reproduction of CVE-2026-109618 used an application/x-www-form-urlencoded request containing an array-style field name large enough to exhaust memory_limit while PHP parsed the request. Blocking oversized field names removes one practical path to triggering the memory exhaustion condition.

For hosting providers, this protection provides time to patch systems across a large customer base, including environments where upgrading PHP cannot happen overnight. It is especially useful while providers work through EOL PHP versions and coordinate upgrades with customers.

WAF is a mitigation, not a fix

Rules 410054 and 410055 block known exploit patterns and one likely trigger condition, but they do not replace patching. Providers should still upgrade to fixed PHP releases, restart PHP workers, remove or migrate away from EOL versions where possible, and review systems for signs of compromise. Keep the WAF enabled as an extra layer while the upgrades and checks are completed