By Cyber Defense Technologies October 22, 2026 5 min read
On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which researchers have nicknamed PHP2Shell. Both can allow unauthenticated remote code execution, and both sit in PHP itself rather than in any particular application. CISA issued an alert the same day urging organizations to patch immediately.
As of October 22, 2026, this is a fast-moving issue. The details below come from the PHP project's security advisory and CISA alert, and may change as more is learned.
What the vulnerabilities are
CVE-2026-109618 (RCE via out-of-memory corruption). Out-of-memory handling can interrupt PHP while internal request data is only partly initialized. Request cleanup may then treat that invalid data as valid.
CVE-2026-109619 (RCE via stale global state). Internal state owned by one request can survive after its memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it. The PHP advisory says this can lead to code execution with the privileges of the web worker.
The PHP project's GitHub advisories rate both as critical, with a CVSS v4.0 score of 9.2. Other scores have circulated online. Use the official advisories when prioritizing work and reporting risk.
Who is affected
According to the PHP project, all PHP installations that serve web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is highest for mod_php, where the project reports a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs. Keeping an application such as WordPress or Laravel up to date does not help here, because the flaws are in the PHP runtime underneath it.
CISA said that, at the time of its alert, it had not observed exploitation, but it warned that unpatched systems remain at risk.
Find every copy of PHP
CISA recommends starting with an inventory of every system running PHP, including PHP embedded in other software where it may not be obvious. Places to look:
- Web servers and application hosts, including servers that run more than one PHP version side by side.
- Container images that bundle their own PHP. Patching the host does not fix the image; it must be rebuilt and redeployed.
- Vendor appliances and commercial products that ship PHP internally, such as admin consoles and web front ends.
- Hosted and managed platforms, where you may need to confirm the provider's patch status.
Check the version the web server is actually running, not just the command-line version, since the two can differ. If you use Linux distribution packages, check your vendor's advisory: the PHP project says distributions and long-term-support vendors received patches in advance, and packaged versions may not carry the same version numbers as upstream.
Patch, then restart
- Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's fixed package. The PHP project states that updating is the only safe choice.
- Prioritize internet-facing systems, as CISA recommends.
- Restart every PHP worker and confirm the running process reports the fixed version.
- Plan for unsupported versions. PHP 8.1 and older no longer receive updates from the PHP project. Some vendors provide backported fixes, and the project has published minimal source backports for PHP 7.4, 8.0 and 8.1. Upgrading to a supported release remains the real fix.
If you cannot patch right away
CISA advises taking PHP-based systems offline until they are updated if you cannot patch immediately, or if you are still running PHP 8.1 or older. Where that is not possible, the PHP advisory lists interim measures that reduce exposure but do not make an installation safe:
- Disable session upload progress (session.upload_progress.enabled=0) in php.ini, the FPM pool or server configuration, not through application code, then restart every worker.
- On PHP 8.5, set fatal_error_backtraces=0 and restart workers.
- Follow the advisory's memory and request-size guidance, and enforce limits on request size, field counts and nesting depth at the web server or proxy.
- CISA notes that a web application firewall may offer some protection in the meantime.
Watch for signs of compromise
CISA recommends monitoring for suspicious activity such as PHP worker processes launching shells or downloading tools. Web server processes rarely have a legitimate reason to start a command shell, so alerts on that behavior are a useful signal. Review PHP error logs for unusual crashes, and treat any confirmed hit as a potential compromise of the host, including any credentials or keys it stored.
What to tell leadership
Keep it short: critical flaws in PHP, a widely used web programming language, can let an unauthenticated attacker run code on affected servers. Fixes are available. Report how many systems run PHP, how many are internet-facing, how many are patched, and what remains, with a date for each. Flag any end-of-life PHP versions as a separate risk that needs a decision.
How CDT can help
CDT helps organizations respond to urgent vulnerabilities. Our managed security team can help inventory and monitor exposed systems, our hardening engineers can apply and verify fixes and interim controls, and our incident response team can investigate if you suspect a server was compromised.
