PHP2Shell probes and PHP multipart upload vulnerabilities

2026-10-22T00:00:00+11:00

PHP2Shell can let an unauthenticated web request execute code on a vulnerable PHP server. The bugs can be triggered before the website's own code runs. Updating PHP, restarting its workers and blocking known attack patterns are the immediate priorities.

Peakhour's WAF blocks requests containing PHP's default upload-progress field. We are updating protections as new request patterns emerge.

At 03:15:36 AEDT on 22 October 2026, a client at 94.154.43.7 made a GET request to one of our honeypots. About 1.4 seconds later, it sent a multipart POST to / on port 8080. The form had 151 file entries with empty filenames and field names nested 60 bracket levels deep.

The request arrived the day after PHP disclosed two request-handling vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The combination of upload-progress tracking and deeply nested file fields matches a PHP2Shell-style probe.

The request that reached one of our honeypots

The request used plain HTTP. Its user-agent string was Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, and its TCP signature was 1460|7|1|1|64240|0x02.

The captured form included PHP_SESSION_UPLOAD_PROGRESS and PHPSESSID, followed by repeated file entries with empty filenames.

Our WAF logs also showed upload-progress probes earlier that morning. At 08:49 AEDT, requests from 169.58.51.5 triggered blocks for the upload-progress field and forms with too many arguments. We checked the honeypot logs through 10:50 AEDT on 22 October and found no further requests combining upload-progress tracking with deeply nested, empty-filename file entries.

How the request puts pressure on PHP

Three details explain why a form like this matters to PHP.

Upload progress starts early. When PHP's session upload-progress feature is enabled, PHP_SESSION_UPLOAD_PROGRESS makes PHP track the upload and begin session processing while the body is arriving.
Empty files still use memory. PHP's max_file_uploads limit does not count empty-filename entries. On a PHP server, those 151 entries would still create file metadata.
Nested names multiply the work. PHP turns bracketed field names into arrays. With 60 levels of nesting, even empty file entries make PHP build complex data structures in memory.

PHP's advisories explain how bugs in memory handling can allow an attacker to run code on the server. CVE-2026-109618 can leave PHP handling incomplete internal data after it runs out of memory while preparing a request. When PHP cleans up the failed request, it may treat that incomplete data as valid. CVE-2026-109619 can leave a PHP worker pointing to memory that has already been freed. When the same worker handles a later request, PHP may try to use that memory again. We did not observe code execution.

Our assessment

The high attack-complexity ratings describe the work needed to overcome exploit protections. Reliability also depends on the PHP build, memory layout, extensions and request handling. For the stale-state vulnerability, the attacker needs a later request to reach the same PHP worker and act on memory left over from an earlier request.

These conditions make a working exploit harder to develop and reproduce. PHP has already demonstrated unauthenticated code execution against mod_php before application code runs, including with multiple workers. Our view is that automated retries can reduce the practical burden of reaching the required conditions. Repeated multipart probes, memory failures and unexpected worker exits deserve investigation while teams patch. WAF protections can interrupt known request patterns during that rollout. PHP's exploit assessment explains the demonstrated impact and reliability factors.

PHP released fixes on 21 October in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Its release notice identifies Apache mod_php as the highest-risk setup and urges all installations serving web requests to update. Install a fixed release or a vendor package with the fixes, then restart PHP workers. Limits on request size and multipart forms can help reduce exposure while teams install the updates.

This is why WAFs still matter. Attackers can start probing while teams are checking affected systems and rolling out updates. A WAF can block known attack patterns before they reach PHP, giving operators time to patch. As probes change, rules can be updated centrally and request logs can show which patterns need attention. Patching fixes the underlying vulnerability; the WAF adds a layer of protection during the rollout and helps detect further attempts.

PHP configuration while patching

Apply temporary controls in the configuration loaded by your web-serving PHP runtime. Restart every worker and check the effective pool and server settings. Updating PHP remains the complete fix.

For CVE-2026-109619, disable session upload progress in configuration applied before PHP parses requests. In an FPM pool, an administrative setting can look like this:

php_admin_flag[session.upload_progress.enabled] = off

The equivalent php.ini setting is session.upload_progress.enabled = Off. A script-level ini_set() call and FPM .user.ini take effect too late for this mitigation. Also audit early-applied per-request or directory settings for deprecated values, and remove attacker-reachable fatal-error and timeout paths. On PHP 8.5, fatal_error_backtraces = Off addresses the confirmed backtrace path; it is specific to that version.

For the out-of-memory bug, PHP's advisory recommends temporarily enforcing memory_limit = -1 administratively. This removes the predictable PHP memory-limit failure and PHP's per-request memory bound. Plan external worker or container memory controls first: a shared cgroup limit can take down the whole pool. An FPM pool can enforce php_admin_value[memory_limit] = -1; check that pool, directory and application overrides preserve it. Underlying allocation failures can still trigger the bug.

Keep post_max_size conservative: PHP recommends 8M when the application has no uploads and 32M when uploads are needed. Check these sizes against normal application requests before applying them, and set upload_max_filesize below post_max_size. At the edge, cap decoded body size, including chunked requests and requests without a usable Content-Length. Also bound input variables, multipart parts, part headers and nesting depth. max_file_uploads does not count empty-filename entries, although PHP still allocates metadata for them. For unpatched workers, avoid lowering memory_limit or substituting RLIMIT_AS or RLIMIT_DATA: allocation failures can trigger the vulnerable behavior. The official PHP guidance explains these temporary measures.

What to look for in your logs

Compare unusual multipart forms with the application's normal uploads. Look for combinations of empty file entries, deeply nested names, unusually many part headers and upload-progress fields. Check nearby requests too, including a GET just before an upload.

What your rules could miss

A rule for PHP_SESSION_UPLOAD_PROGRESS must match the name configured on the server. PHP uses this name by default, and administrators can change it with session.upload_progress.name. PHP documents the setting. Check the server's configuration before blocking the field.

Set limits that allow the uploads your application needs. Good WAF tuning also checks what happens when a request is too large or malformed for the WAF to inspect fully. Monitor those parsing errors so suspicious requests do not pass unnoticed. The PHP advisories also describe attacks through other features. Those paths need additional protections and the PHP update.

Watch for evolving attacks

This request combined an upload-progress field with many nested file entries. Future scanner versions could use different multipart layouts or target other PHP parsing paths. Review new patterns as they appear and check that your rules still match the PHP configuration.

Patch PHP first. Set body-size and multipart limits that fit the application, then review parser errors when tuning those limits.

Connection fingerprints

We calculated these JA4H values from saved HTTP headers using FoxIO's reference implementation. The final entry is from the honeypot. The others are from WAF probes. The entries below include the TLS fingerprints recorded in each probe group. Use these fingerprint groups to search for similar clients in your own logs.

WAF probe group one

HTTP JA4H  po11nn060000_84bafeeaa541_000000000000_000000000000
Observed TLS JA4  t13d131100_f57a46bbacb6_ab7e3b40a677

WAF probe group two

HTTP JA4H  po11nn060000_4ea4093e6290_000000000000_000000000000
Observed TLS JA4  t13d131200_f57a46bbacb6_9249cab70c77

WAF probe group three

HTTP JA4H  po11nn060000_5c15dc981d69_000000000000_000000000000
Observed TLS JA4  t13d911100_0d5420ba6086_ec21bdc2dd35

WAF probe group four

HTTP JA4H  po11nn050000_197af124696f_000000000000_000000000000
Observed TLS JA4  t13d171200_ab0a1bf427ad_ecd0401ec68b

Honeypot request

HTTP JA4H  po11nn060000_d09ed10a732b_000000000000_000000000000
TLS JA4    not applicable; plaintext HTTP

Two WAF probes, from 160.187.210.214 and 169.58.51.5, shared the honeypot's TCP settings but had different HTTP fingerprints. Several other WAF records shared the same declared body size, headers and browser string. One used the user-agent Mozilla/5.0 (php2shell-check/1.0). These details can help with log searches. Our guide to recognising vulnerability scanners shows how to combine these clues across source addresses.

Observed source addresses

These addresses appeared in upload-progress probes between 00:00 AEDT on 21 October and 09:00 AEDT on 22 October 2026, or in the honeypot request at 03:15 AEDT on 22 October. Use them to search logs and review each request before blocking an address.

2.27.152.153  13.143.120.218  23.27.75.120  23.27.203.212
23.236.222.100  24.144.109.162  31.56.137.245  31.56.138.52
31.58.9.242  31.58.20.52  31.58.148.208  31.59.27.195
34.87.183.75  38.154.233.215  43.229.11.209  45.38.92.232
45.38.114.219  45.39.7.39  45.39.7.227  45.39.27.153
45.39.123.39  45.41.171.199  45.41.176.106  45.41.177.11
45.43.67.111  45.43.82.93  45.61.98.240  45.61.100.180
45.61.123.134  45.67.0.207  45.67.3.53  45.147.187.214
45.151.163.80  45.159.53.193  45.249.59.5  45.249.59.123
46.202.248.133  46.203.154.134  46.203.202.8  46.203.212.201
62.105.202.173  62.105.203.138  64.64.118.134  64.137.8.237
64.137.73.58  64.137.100.131  64.137.101.226  64.137.108.41
67.227.1.14  67.227.37.59  68.167.47.41  68.183.138.186
82.21.221.119  82.21.248.189  82.22.215.207  82.22.234.160
82.22.249.84  82.23.227.154  82.24.212.115  82.25.235.118
82.27.247.49  82.29.233.5  82.29.245.108  89.45.125.116
89.249.192.235  91.211.87.239  92.112.91.92  92.112.143.195
92.112.170.208  92.113.119.3  92.113.236.71  92.113.246.14
94.154.43.7  94.177.5.146  102.212.90.53  103.47.53.192
103.99.34.177  103.101.90.134  103.105.76.121  104.168.118.192
104.252.49.100  104.253.50.139  104.253.81.55  104.253.91.46
107.172.163.190  107.174.194.247  108.165.205.76  136.0.108.192
136.0.184.80  140.99.189.141  140.99.193.124  140.99.203.75
142.111.44.12  142.111.216.8  142.147.129.75  142.147.132.10
145.223.41.159  145.223.45.93  145.223.50.100  148.135.254.33
148.135.254.73  148.135.254.118  151.245.204.165  151.245.204.214
151.245.205.41  151.245.206.59  152.232.81.206  154.9.177.66
154.29.25.85  155.254.39.35  160.187.210.214  166.88.34.50
166.88.64.163  168.199.209.224  168.199.244.14  169.58.51.5
172.120.112.207  172.120.119.224  173.214.177.173  185.101.252.60
192.95.91.217  192.177.87.44  192.186.186.222  198.12.112.116
198.20.191.165  198.46.148.181  198.46.202.184  198.46.241.29
198.89.123.223  198.105.100.102  208.70.8.237  212.42.207.214
213.169.211.115  216.10.27.39  217.117.165.104

Peakhour.IO - PHP

PHP2Shell probes and PHP multipart upload vulnerabilities

The request that reached one of our honeypots

How the request puts pressure on PHP

PHP configuration while patching

What to look for in your logs