Temporary BunkerWeb filters for PHP2Shell (CVE-2026-109618 and CVE-2026-109619)

[TheophileDiot]

Update, 23 October: we missed the request shape the published exploit uses, so the input-limits config now ends with two more rules, 78183 and 78184. We also got the reporting wrong. BunkerWeb doesn't recognize the custom tx.bunkerweb_reason values we used. With the default deny status, our 403 blocks normally showed up in Reports as unknown, without the rule ID, and detect-mode matches could be missing from Reports. Every deny rule now sets tx.bunkerweb_reason=modsecurity and the variables that carry the rule ID and message. If you copied either config earlier, replace both with the versions below. Changing the reporting actions doesn't change what a rule matches or blocks.

PHP shipped the fixes for both PHP2Shell vulnerabilities on 21 October: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with source backports for 7.4, 8.0 and 8.1. Updating PHP is the fix, and PHP's own advisory calls it the only safe choice. If you can't patch every PHP worker today, the two custom configs below cut down what reaches PHP through BunkerWeb in the meantime. They don't make an unpatched PHP safe, and they do nothing for traffic that reaches your origin without going through BunkerWeb.

The first one covers CVE-2026-109619. PHP confirmed the session upload-progress field as the entry point, so the config rejects PHP_SESSION_UPLOAD_PROGRESS in parsed field names, including the dot, space and array forms PHP turns into the same key. It also checks the raw multipart part headers, in case ModSecurity and PHP read a name differently. It doesn't cover the other stale-state paths in the advisory.

# CVE-2026-109619: block the default upload-progress field and multipart aliases.
# BunkerWeb custom config type: modsec. Requires libmodsecurity >= 3.0.8.
# Custom session.upload_progress.name values require matching rule changes.
# Other stale-state paths and direct origin access remain exposed; patch PHP.
# Remove after every PHP worker runs a fixed release or vendor backport.

SecRule ARGS_NAMES|FILES_NAMES "@rx ^php[ ._]session[ ._]upload[ ._]progress(?:\[|$)" \
    "id:78161,phase:2,t:none,t:urlDecodeUni,t:lowercase,deny,status:403,log,msg:'PHP2Shell upload-progress field blocked',setvar:'tx.bunkerweb_reason=modsecurity',setvar:'tx.bunkerweb_unique_id=%{UNIQUE_ID}',setvar:'tx.bunkerweb_rules=%{tx.bunkerweb_rules} %{rule.id}',setvar:'tx.bunkerweb_msgs=%{tx.bunkerweb_msgs}|%{unique_id}|%{rule.msg}'"

# Check raw part headers too; do not rely only on the WAF's parsed field names.
SecRule MULTIPART_PART_HEADERS "@rx php[ ._]session[ ._]upload[ ._]progress(?:[\[\x22\x27;\s]|$)" \
    "id:78162,phase:2,t:none,t:urlDecodeUni,t:lowercase,deny,status:403,log,msg:'PHP2Shell upload-progress multipart header blocked',setvar:'tx.bunkerweb_reason=modsecurity',setvar:'tx.bunkerweb_unique_id=%{UNIQUE_ID}',setvar:'tx.bunkerweb_rules=%{tx.bunkerweb_rules} %{rule.id}',setvar:'tx.bunkerweb_msgs=%{tx.bunkerweb_msgs}|%{unique_id}|%{rule.msg}'"

The second one covers CVE-2026-109618 the way PHP's advisory suggests for proxies: it caps the number of fields and multipart parts, and the JSON nesting depth. It also caps field names nested 8 levels or deeper at 100: PHP builds the whole name hierarchy up to six times for every nested multipart control, empty file controls included, and the exploit sends many of them. With the field and part budgets alone, anything from 51 to about 4,999 of them got through. The deny rules don't rely on CRS anomaly scoring, so they apply with CRS v4, CRS v3 or CRS off.

# CVE-2026-109618: reduce input amplification; this does not fix PHP OOM handling.
# BunkerWeb custom config type: modsec. Use BunkerWeb 1.6+ / libmodsecurity 3.0.13+.
# Pair with MAX_CLIENT_SIZE=8m (no uploads) or 32m (uploads), never 0.
# Application allocations, other parsers and direct origin access remain exposed.
# Remove temporary CVE rules after every PHP worker is patched; retain useful limits.

# Keep the parser ceiling ABOVE the deny threshold: truncation can be silent.
SecArgumentsLimit 6000
SecRequestBodyJsonDepthLimit 64

# Direct deny does not depend on the CRS anomaly threshold or require CRS.
SecRule &ARGS "@gt 5000" \
    "id:78180,phase:2,t:none,deny,status:403,log,msg:'PHP2Shell input field budget exceeded',setvar:'tx.bunkerweb_reason=modsecurity',setvar:'tx.bunkerweb_unique_id=%{UNIQUE_ID}',setvar:'tx.bunkerweb_rules=%{tx.bunkerweb_rules} %{rule.id}',setvar:'tx.bunkerweb_msgs=%{tx.bunkerweb_msgs}|%{unique_id}|%{rule.msg}'"

# Aggregate raw header lines also bound parts, including repeated/empty file parts.
# Each parsed part needs at least one Content-Disposition line; files need more.
SecRule &MULTIPART_PART_HEADERS "@gt 5000" \
    "id:78181,phase:2,t:none,deny,status:403,log,msg:'PHP2Shell multipart header and part budget exceeded',setvar:'tx.bunkerweb_reason=modsecurity',setvar:'tx.bunkerweb_unique_id=%{UNIQUE_ID}',setvar:'tx.bunkerweb_rules=%{tx.bunkerweb_rules} %{rule.id}',setvar:'tx.bunkerweb_msgs=%{tx.bunkerweb_msgs}|%{unique_id}|%{rule.msg}'"

# Explicit fail-closed handling even if the built-in body error rule was customized.
SecRule REQBODY_ERROR "!@eq 0" \
    "id:78182,phase:2,t:none,deny,status:400,log,msg:'PHP2Shell request body parsing failed',setvar:'tx.bunkerweb_reason=modsecurity',setvar:'tx.bunkerweb_unique_id=%{UNIQUE_ID}',setvar:'tx.bunkerweb_rules=%{tx.bunkerweb_rules} %{rule.id}',setvar:'tx.bunkerweb_msgs=%{tx.bunkerweb_msgs}|%{unique_id}|%{rule.msg}'"

# Nested-name budget (added 2026-10-21): PHP builds the name hierarchy up to six
# times per nested multipart control, empty file controls included. Count names
# nested 8+ levels and reject more than 100; real forms have a handful.
SecRule ARGS_POST_NAMES|FILES_NAMES "@rx ^[^\[]*(?:\[[^\]]*\]){8}" \
    "id:78183,phase:2,t:none,pass,nolog,setvar:'tx.php2shell_deep_names=+1'"

SecRule TX:php2shell_deep_names "@gt 100" \
    "id:78184,phase:2,t:none,deny,status:403,log,msg:'PHP2Shell nested field budget exceeded',logdata:'%{TX.php2shell_deep_names} names nested 8+ levels',setvar:'tx.bunkerweb_reason=modsecurity',setvar:'tx.bunkerweb_unique_id=%{UNIQUE_ID}',setvar:'tx.bunkerweb_rules=%{tx.bunkerweb_rules} %{rule.id}',setvar:'tx.bunkerweb_msgs=%{tx.bunkerweb_msgs}|%{unique_id}|%{rule.msg}'"

SecArgumentsLimit has to stay above the deny threshold. Past its limit ModSecurity stops counting without raising an error: set to 2000, it saw 2000 of 3000 fields and PHP still received all 3000. We started at 1000 fields, and that blocked saving a 300-item WordPress menu (3608 fields), hence 5000. A smaller app can go lower with SecArgumentsLimit 2000 and both @gt 5000 changed to @gt 1000. Real forms have a handful of names nested that deep. If one of your forms has more than 100, run detect mode first and look for 78184 in the logs.

Add both as modsec custom configs, globally or on your PHP services, from the web UI or on the scheduler:

CUSTOM_CONF_MODSEC_php2shell-upload-progress: |
  # paste php2shell-upload-progress.conf here
CUSTOM_CONF_MODSEC_php2shell-input-limits: |
  # paste php2shell-input-limits.conf here

They need BunkerWeb 1.6.0 or later. On the PHP services, keep USE_MODSECURITY=yes, MODSECURITY_SEC_RULE_ENGINE=On and SECURITY_MODE=block, because in detect mode these rules only log. Keep MODSECURITY_SEC_REQUEST_BODY_LIMIT_ACTION=Reject too, because ProcessPartial lets the end of a large body through uninspected. Set MAX_CLIENT_SIZE to 8m without uploads or 32m with uploads, never 0. That limit applies to chunked bodies too, but a location's REVERSE_PROXY_MAX_CLIENT_SIZE, numbered instances included, can raise it or set it to 0, so check those. Keep REVERSE_PROXY_MODSECURITY=yes on every PHP location, numbered instances included, so these rules run there. With CRS enabled, whitelisted clients skip ModSecurity; with CRS off, these rules still run for them. 1.6.17 already caps request headers at 100 with MAX_HEADERS, a setting 1.6.0 doesn't have.

If you changed session.upload_progress.name, put your name in both patterns in place of php[ ._]session[ ._]upload[ ._]progress, in lowercase, with each _ written as [ ._] and any other regex metacharacter escaped, and test the rules before you deploy them. On the PHP side, session.upload_progress.enabled=0 in the startup config, followed by a restart of every worker, is the stronger stopgap for CVE-2026-109619.

We tested both on BunkerWeb 1.6.17~rc2 with CRS v4, CRS v3 and CRS off, in front of PHP 8.4. That covered 26 multipart and encoding variants of the field (none that PHP could see got through), the field, part, depth and size boundaries, and a real WordPress: install, login, Gutenberg saves, a media upload, the 300-item menu and comments. The upload-progress filter also reads raw part headers, so an upload whose filename contains the token gets a 403 as well. We tested the nested-name rules on BunkerWeb 1.6.17 with CRS v4: 100 nested names pass and 101 get a 403, whether they're empty file controls, plain fields, file parts or a URL-encoded body. Nothing in the WordPress set above tripped them, and neither did uploads of 1 to 51 files, Nova forms nested 5 levels, single forms nested 11 and 12 levels, or JSON 30 levels deep.

To check the upload-progress filter, from an IP that isn't whitelisted:

curl -s -o /dev/null -w '%{http_code}\n' -F PHP_SESSION_UPLOAD_PROGRESS=x -F a=b https://your-site.example/
# 403

Then look for 78161 in the BunkerWeb logs or in Reports, because another protection can also return 403. This doesn't test the input-limits config.

Keep the upload-progress config until the next regular PHP release runs on every PHP worker, even after the 21 October fixes, because of CVE-2026-115560. The input limits are reasonable hardening to keep if they don't get in your way.

[TheophileDiot]

PHP published an informational advisory today that changes the removal advice above. The upload-progress path can still lead to code execution on the fixed releases when an application sets session.serialize_handler to php_binary or php_serialize in its configuration, switches it to php with ini_set() before session_start(), and leaves session upload progress enabled. It's CVE-2026-115560, fixed in the next regular PHP release, and until then PHP recommends:

session.upload_progress.enabled = 0

So keep php2shell-upload-progress.conf (rules 78161 and 78162) in place even on a patched PHP until that release reaches every worker, or set the line above on all of them. If you already took the config out, put it back from the original post, it hasn't changed. Few applications switch the serialize handler at runtime, and the filter only blocks a field they never send, so there's nothing to gain from removing it early.

The input-limits config isn't affected by this.