PHP2Shell: Two Critical PHP Flaws Let Attackers Run Code Without Logging In

On October 21, 2026, the PHP project shipped emergency security releases for two critical flaws in the PHP runtime itself. Nicknamed PHP2Shell, they allow an unauthenticated remote attacker to run code on a server with a single crafted request. If you run PHP anywhere that serves web traffic, this is a patch-today item.

• CVE-2026-109618: an out-of-memory flaw in PHP.
• CVE-2026-109619: a flaw in session upload progress handling.
• Both are rated 9.2 on CVSS v4.0. A figure of 10.0 that circulated after a leak was not PHP's rating.
• Affected: PHP versions from 5.4 through 8.5.11.
• Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• CISA has urged immediate patching.

These are not bugs in a plugin or a framework. They sit in PHP's core, so a well-written, fully patched application can still be exposed if the runtime underneath it is vulnerable.

The risk depends on how PHP is deployed:

• Apache `mod_php` is the highest risk. A demonstrated exploit needs one unauthenticated request and triggers before your application code runs.
• PHP-FPM behaves differently, because the worker shuts down when a request fails early in setup. PHP's own analysis says FPM is susceptible to CVE-2026-109619, but a complete FPM exploit has not been shown. Do not read that as safe: the path can depend on what the running application does.
• Other web-facing setups, including php-cgi, FrankenPHP and LiteSpeed, are in scope too.
• Even without code execution, researchers note an attacker may be able to read worker process memory, which could expose passwords, tokens, API keys and certificates.

Reporting is still developing, and sources differ.

• watchTowr reported active exploitation attempts against both CVEs on October 21.
• Cloudflare reported early attack attempts before the patch and said attackers changed payloads to evade its firewall rules.
• As of the reporting we reviewed, no source had confirmed a successful break-in of a specific server, and neither flaw had yet been added to CISA's Known Exploited Vulnerabilities catalog.

Treat "attempts, not confirmed compromises" as a reason to move fast, not a reason to wait.

1. Patch. Upgrade to the fixed release for your branch:

2. Restart everything. After updating, restart Apache, PHP-FPM and any long-running PHP workers. An updated binary on disk does not help while old workers are still running.

3. Check your distribution. Linux vendors backport fixes without changing the version string, so check your package changelog for the CVE IDs rather than relying on the version number.

4. Plan for end-of-life branches. PHP 8.1 and older no longer receive project updates. If you are still on them, you need either a vendor extended-support build or an upgrade. Source backports exist for 7.4, 8.0 and 8.1.

5. If you truly cannot patch yet, reduce exposure. PHP states that only updating fully protects a server, so treat these as stopgaps:

• For CVE-2026-109618: set memory_limit=-1 so applications cannot override it, keep post_max_size low, and enforce request size limits at your web server or proxy. Avoid RLIMIT_AS and RLIMIT_DATA, which PHP warns can trigger the same path.
• For CVE-2026-109619: set session.upload_progress.enabled=0 and restart workers. On PHP 8.5, also set fatal_error_backtraces=0. This blocks the confirmed session paths, not necessarily every variant.

After patching, note that the fix adds a hard memory limit. Hitting it ends the process, so review your memory settings.

Researchers suggest watching for:

• unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses,
• oversized PHPSESSID cookies in responses,
• PHP workers restarting without explanation.

If you see these on an unpatched server, assume you may be compromised and rotate any secrets the server could reach.

The flaws were reported by Wiz Research, Calif and OpenAI's Codex Security team, who worked with the PHP security team and Google's Gemini team on the fix. A leak on October 20 pulled the release forward by a day, from October 22 to October 21.

If you are unsure which of your servers run affected PHP builds, or you are stuck on an end-of-life branch, our team can run a rapid exposure audit and plan a safe upgrade path. Contact us.