Two critical flaws in PHP can let an attacker run code on a web server. The PHP team has proved that remote code execution is possible. Fixed releases are available now.
If PHP serves web requests, update it now. Do not wait for proof of attacks in the wild.
PHP's rating for both flaws
An attacker may not need a login
Released 21 October 2026
PHP runs much of the web. These flaws sit inside PHP itself, below the website or application that people see. An attacker can send specially prepared web requests that corrupt the PHP worker's memory.
An attacker forces PHP to run out of memory while it is still processing request data. Cleanup can then use invalid memory. With careful preparation, that memory corruption can run attacker-controlled code.
PHP workers handle many requests. In some cases, data from one request can remain after PHP has freed its memory. A later request can reuse that stale data, leak memory and run code.
PHP pre-notified Linux distribution and long-term-support vendors so they could prepare fixes.
Four supported branches received fixed releases. Source backports were supplied for some older branches.
Working exploitation has been demonstrated. There is no complete workaround that replaces updating.
RoboShadow now checks specifically for these vulnerabilities. You can also use the manual checks below to find where PHP is present across your environment.
This is a specific vulnerability result, rather than a general warning that PHP may be present.
When will it appear in your account? The update cannot change existing results immediately. RoboShadow must first receive fresh data from your External Scanner, LAN Scanner, OWASP Scanner or device scans. You may need to run a rescan or recalculate your results before the new detection appears.
Use the LAN Scanner, External Scanner and OWASP Scanner to find web services that disclose PHP or show a vulnerable route.
Agent inventory can find PHP packages on managed devices, including command line, CGI and FPM packages.
Compare the full package build with its Linux or LTS vendor advisory. A backported fix may keep an older PHP version number.
Before the specific detection update went live, we contacted users whose existing evidence showed that PHP may be present. That email was a prompt to investigate, not a claim that the organisation had been compromised.
RoboShadow can identify the vulnerability. It cannot tell you that an attacker has used it. Vendor backports can also retain an older PHP version number, so check the full package build against the vendor's advisory.
PHP says updating is the only safe choice. Temporary configuration changes can reduce exposure, but they are not complete fixes.
Include internet-facing and internal services. Check mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.
PHP considers mod_php the highest risk path because unauthenticated code execution was demonstrated before application code runs.
Use the fixed upstream version or a package that your Linux or LTS vendor confirms contains the backported fix.
Restart workers after patching so no process continues to run the old code or hold unsafe state.
Run the relevant External, LAN, OWASP or device scan again, then recalculate if needed. Record the vendor package build when the banner still reports an older upstream version.
PHP 8.1 and older are unsupported upstream. PHP 8.2 reaches end of life on 31 December 2026.
Older Linux package numbers may still be safe if the vendor has backported the fix. Confirm against the vendor's security advisory.
PHP's security team has demonstrated working unauthenticated remote code execution. As of 22 October 2026, CISA has not listed either CVE in its Known Exploited Vulnerabilities catalogue, and we have no official confirmation of attacks in the wild. That does not mean attacks are not happening.
No. Risk depends on whether an attacker can reach the service. An internal service can still be exposed through a compromised device, another network segment or an unsafe proxy route.
No. It is useful evidence, but it can be stale, hidden or changed. Linux vendors can also add the security fix without changing the upstream PHP version shown in the banner.
PHP published several ways to reduce exposure, including changes to memory limits, multipart request handling and worker state. PHP is clear that these are incomplete. Use the official advisory for emergency mitigation details and patch as soon as possible.
Find reachable services and installed PHP packages, then focus your team on the systems that need verification first.
Start free