Customers using Transparent Edge’s WAF are already protected against PHP2Shell without needing to activate anything. Even so, patching PHP is the only complete solution. Here is an overview of what happened, what we have done, and what steps you need to take.
On October 20, details regarding two critical vulnerabilities in the PHP core were leaked ahead of schedule. The PHP security team moved up their public disclosure, and patched versions have been released today.
What are CVE-2026-109618 and CVE-2026-109619?
These are two memory management vulnerabilities in the PHP interpreter, collectively known as PHP2Shell. The PHP security team has assigned each a CVSS v4 score of 9.2.
Both issues occur when an HTTP request terminates abnormally, leaving PHP’s memory in an inconsistent state:
| CVE | Root Cause | Impact |
| CVE-2026-109618 | PHP runs out of memory before initializing certain internal structures and, during cleanup, references them as valid data. | Remote Code Execution (RCE) |
| CVE-2026-109619 | A fatal error leaves dangling references to already-freed memory that a subsequent request can reuse. | Memory disclosure and Remote Code Execution (RCE) |
An attacker does not need authentication to exploit these flaws; sending specifically crafted HTTP requests is sufficient. Because the issue resides directly within the PHP core rather than application-layer code, updating your CMS or plugins will not resolve it.
Who is affected?
Any internet-facing server running PHP 5.4 or later is vulnerable, regardless of the application deployed: WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel, or custom developments.
The issue impacts all PHP server configurations: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The highest risk lies with Apache running mod_php, where full exploitation has been demonstrated under default configurations.
Only actively maintained branches receive an official patch (8.2, 8.3, 8.4, and 8.5). PHP 8.1 and earlier will not receive upstream fixes.
How Transparent Edge’s WAF protects you
From the outset—even before full technical details were released—we deployed specific virtual patching rules across our WAF to mitigate PHP2Shell. A virtual patch inspects and blocks malicious exploit attempts at the edge before they can reach your origin server.
Once the official PHP patches were released, we executed a three-stage response:
- Analyzed source code diffs to map the exact attack vectors.
- Verified in lab environments that exploit payloads are effectively blocked before reaching the origin.
- Fine-tuned rule signatures to ensure legitimate application traffic continues unimpeded.
If you have our WAF active, you are already protected; no manual rule configuration is required. We continue to monitor edge traffic actively and will update inspection signatures as new evasion techniques emerge.
What you need to do
While the WAF shields your application immediately, virtual patching does not replace applying the upstream patch.
- Update PHP to version 8.2.35, 8.3.36, 8.4.27, or 8.5.12. Afterwards, restart all PHP-related processes (PHP-FPM or Apache). Simply installing packages without restarting will leave the vulnerable binary in memory.
- If you run PHP 7.4, 8.1, or earlier, no upstream patch is available. Check whether your OS distribution or hosting vendor provides backported packages, or begin planning an immediate migration to an actively maintained branch.
- Restrict origin access so your servers only accept traffic originating from our edge network. Direct requests to your server’s IP bypass the CDN entirely and will not benefit from WAF filtering.
- Audit your environment post-patching for potential indicators of compromise, such as unexpected webshells, newly added administrator accounts, or modified PHP files.
If you do not currently have our WAF enabled, updating your runtime environment is your only protection. Contact us if you would like to enable edge protection.
Potential impact on your website
To minimize exposure, some WAF rules apply strict validation against PHP mechanisms targeted by this exploit family, such as session-based file upload progress tracking.
If you notice unexpected behavior with complex forms or file uploads, please reach out to us so we can review the triggers. Once you confirm your PHP installation has been patched and restarted, we can adjust these inspection rules for your service.
For any questions or assistance, our support team remains available through your standard support channels.
