PHP Has a Second RCE in Three Days, and No Patch Yet. One Setting Covers It, if It Is Really Off.

01 What changed on 23 October

Three things are still unknown on 24 October: which branches are affected, the severity score, and whether the bug shares a root cause with CVE-2026-109619 [ Astra 2026 ] . No attacks against the new flaw have been reported. The attacks that started on 21 October target PHP2Shell.

02 Who is exposed

PHP2Shell hit every PHP server that took web requests. This one needs three conditions on the same request path [ PHP 2026a ] :

1. The configuration sets session.serialize_handler to php_binary or php_serialize.
2. The application switches it back to php with ini_set() before it calls session_start().
3. Session upload progress is still enabled, which is PHP’s default.

Most applications never touch the serialize handler at runtime, and the PHP project says those can keep upload progress on. The ones that do are usually old: a shared session store between a legacy app and a newer one, a migration that kept both formats readable, a framework patch somebody wrote in 2014. That code tends to sit on the hosts nobody looks at.

03 The setting, and how to prove it is off

The fix for this week is session.upload_progress.enabled=0. It blocks the confirmed session path for CVE-2026-109619 as well, so one change covers both [ PHP 2026b ] . The way you set it matters more than the value.

• PHP-FPM pool: php_admin_flag[session.upload_progress.enabled] = off
• Apache with mod_php: php_admin_flag session.upload_progress.enabled off
• Plain php.ini: session.upload_progress.enabled = 0

Use the php_admin_* form where you can. Application code cannot override it with ini_set(), and the PHP advisory warns against relying on ini_set() or an FPM .user.ini for this setting, because both apply too late in the request [ PHP 2026b ] . Then restart every worker. A reload can leave old workers running with the old value.

04 Where the WAF stops

Cloudflare turned on PHP2Shell rules for free and paid plans at 03:02 UTC on 21 October. Its update of 23 October adds a limit that matters here: customers who changed session.upload_progress.name are not covered by the rule [ Cloudflare 2026 ] . The rule looks for the default field name. Rename the field and the request no longer matches.

A WAF also sees only the traffic routed through it. An attacker who finds your origin IP talks to PHP directly. Treat the edge rule as a second layer under the setting, never the reason to skip it.

05 What this week tells you about next week

Two advisories in three days is a normal pattern after a big disclosure. Researchers who found the first bug keep reading the same code, and the second finding often lands while teams are still patching the first. The teams who set the upload-progress flag on 21 October did nothing on 23 October. The teams who went straight to the version bump and skipped the mitigation now have a second job on a Saturday.

Keep the interim settings from the first advisory in place until the vendor says otherwise, even after you patch. Keep the host list you built for PHP2Shell current, because the next PHP release will ask you to visit every one of those hosts again.

An attacker needs one PHP host where the setting never took. You can find that host first. Your Threat Map maps every web property under your name, flags each unpatched or misconfigured PHP and other critical exposure, and gives you the routes in, proven, with the fix ranked by what each one reaches. Enterprise-grade. Not enterprise-priced.