Scripted attacks on php2shell reached InstaWP-hosted WordPress sites 2 hours 20 minutes after PHP published the technical details of CVE-2026-109618 and CVE-2026-109619 on 21 October 2026, and an exploitation-shaped campaign followed 72 minutes later. None of these attempts succeeded. No PHP worker crashed or ran out of memory at request startup, and no shell was spawned. Every attack wave arrived after a defence was already in place.
This is InstaWP’s read-only analysis of its server logs from 20 to 22 October. The php2shell live status page covers the bugs and what customers need to do. This post covers what attackers sent, and which setting stopped each attempt.
- The first new campaign came 2 h 20 m after disclosure. It probed for session upload-progress, which InstaWP had switched off at about 08:35 UTC.
- The exploitation-shaped wave came 3 h 32 m after disclosure. PHP’s nesting limit, lowered to 32 an hour earlier, discarded its over-nested fields.
- No attempt succeeded. Zero startup out-of-memory errors, zero heap corruption, no worker crash near any attack burst.
- 23% of that campaign’s main wave landed before patched PHP. The mitigation and hardening stopped those alone.
How quickly did attackers start using php2shell?
Within hours. PHP published the technical details at 14:00 UTC on 21 October 2026, the first scripted wave reached InstaWP-hosted sites at 16:20 UTC, and the exploitation-shaped wave followed at 17:32 UTC. By then two of InstaWP’s three defences were live, and patched PHP arrived 21 minutes later.
| When (UTC) | Defence | Attack |
|---|---|---|
| 20 Oct, 20:32 | PHP gives advance notice of the release, with no technical details | |
| 21 Oct, ~08:35 | InstaWP switches off session upload-progress on every managed server and verifies it on the running PHP workers | |
| 21 Oct, 11:42 and 12:19 | Two background multipart sprays (C and D) are already running, before any details are public | |
| 21 Oct, 14:00 | PHP releases the fixes and an advisory with full technical details | |
| 21 Oct, 16:20 | Campaign B, an upload-progress scanner, starts | |
| 21 Oct, ~16:30 | InstaWP lowers max_input_nesting_level to 32 on every PHP pool, and sets fatal_error_backtraces=0 on PHP 8.5 | |
| 21 Oct, 17:32 | Campaign A, a deep-nesting kit, starts. Its main wave runs until 18:30. | |
| 21 Oct, 17:53 | Patched PHP rolled out | |
| 21 Oct 21:00 to 22 Oct 04:00 | C and D roughly triple their rate, B keeps probing, and A trickles on at about one site an hour |
Read it by matching each attack to the defence above it. Campaign B looked for upload-progress, off for almost eight hours by then. Campaign A relied on deeply nested input, capped an hour earlier.
Total upload traffic stayed flat, because real media uploads dominate it. The signal was multipart requests to a site’s homepage, where no upload form lives: overnight they ran at three to four times the pre-disclosure rate.
What did each php2shell campaign try, and what stopped it?
Four scripted campaigns sent multipart POST requests to site homepages: one exploitation-shaped, one fingerprinting, and two background sprays that predate the disclosure. Each met a control that was already live. Payloads are described by behaviour only.
| Campaign | First seen (UTC) | What it did | What stopped it |
|---|---|---|---|
| A: deep-nesting kit | 21 Oct, 17:32 (3 h 32 m after disclosure) | Per site, a short burst of large multipart requests with deeply nested field names, followed by small follow-up requests | The nesting limit of 32 made PHP discard the over-nested fields while parsing. Sites served their normal homepage. |
| B: upload-progress scanner | 21 Oct, 16:20 (2 h 20 m after disclosure) | Uploads sized around common default body limits, checking how the server handles them and whether session upload-progress is exposed | Upload-progress was already off, so there was nothing to find |
| C: background spray | 21 Oct, 12:19 (before disclosure) | Small requests followed by padded multipart bodies that look built to slip past body inspection | No effect. No startup warnings, memory errors or crashes, and normal responses. |
| D: background spray | 21 Oct, 11:42 (before disclosure) | Pairs of fixed-size multipart requests, most likely a generic WordPress plugin exploit sweep | No side effects at all |
Campaign A: the one that looked like exploitation
Campaign A’s traffic matches the memory-exhaustion strategy in PHP’s advisory for CVE-2026-109618 (deeply nested field names), paired with the follow-up requests CVE-2026-109619 needs. It was one tool with a fixed request pattern, run from rented cloud servers that rotated to an almost fresh source address per site. It behaved like a spray that hits each site once. Real heap grooming needs many tries against one PHP worker, and campaign A sent at most two heavy requests to any site.
Sites answered with their ordinary homepage and HTTP 200, the same size as a normal visit, while PHP logged an “Input variable nesting level exceeded 32” warning hundreds of times per request. 98 of the 428 main-wave requests (23%) landed before patched PHP at 17:53 UTC, and the mitigation and hardening stopped those on their own.
Campaigns B, C and D: scanning and background noise
Campaign B identifies itself as an authorized scanner. It is not one of InstaWP’s tools, and the label is only the sender’s claim. It found nothing and was still probing when the analysis closed. Campaigns C and D were running before PHP published any detail, roughly doubled or tripled their rate overnight, and left no side effect in PHP’s logs. D looks like a generic WordPress plugin sweep that happens to use multipart requests.
How does InstaWP know none of these attempts succeeded?
Because every side effect a working php2shell exploit would leave is missing. InstaWP checked each signal PHP’s advisories point to, on every InstaWP-managed hosting server:
- Zero out-of-memory fatals at request startup. Every memory fatal in the window came from ordinary plugin or theme code.
- Zero
zend_mm_heap corruptederrors. - No PHP worker exited within two minutes of an attack burst. The only two signal crashes were nowhere near attack traffic.
- No upload-progress session keys in any request’s query string.
- No suspicious shells, cron jobs or outbound connections. Shells launched from PHP traced to normal behaviour such as sending mail, new cron entries were customers’ own, and outbound connections went only to web and database ports.
- No new PHP files planted through php2shell. Targeted sites were spot-checked for new PHP files. None of these attempts compromised a site.
What can’t InstaWP see?
Quite a lot. InstaWP does not log request bodies, so every campaign here is described from request size, timing, order and the side effects PHP recorded: campaign A matches the advisory’s nested-names strategy, but its payload cannot be proven. InstaWP’s log of multipart requests started at about 11:40 UTC on 21 October, so there is no multipart visibility for 20 October and only a 2 h 20 m baseline before disclosure.
Before about 16:30 the nesting limit was PHP’s default of 64, so a shallower probe earlier in the day would have parsed silently. Requests blocked at the CDN edge never reached the servers, which makes every count here a floor. And the check for new PHP files was deliberately bounded, so a file hidden deep inside a plugin folder with backdated timestamps would be missed.
What should you do if you run PHP yourself?
Patch within hours, and keep the hardening afterwards. These four steps held on InstaWP through the first 14 hours of attacks:
- Apply PHP’s interim mitigations the moment they are published. Set
session.upload_progress.enabled=0inphp.inior the FPM pool and restart every worker. PHP’s advisory for CVE-2026-109619 notes thatini_set()and.user.inido not help. - Add the hardening, not just the mitigation. PHP’s advisory for CVE-2026-109618 suggests limiting input nesting depth. InstaWP lowered
max_input_nesting_levelfrom 64 to 32, which neutralised campaign A. On PHP 8.5, also setfatal_error_backtraces=0. - Keep upload-progress off after you patch. Campaign B was still probing for it hours after the patch.
- Patch fast. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package. 23% of campaign A’s main wave arrived before InstaWP’s patch.
To spot this traffic, watch multipart requests to the homepage, not total POST volume: the attacks were small. If your site is hosted on InstaWP, you don’t need to change anything, because InstaWP applied every layer above. The php2shell status page has the full customer guidance, and the InstaWP guide to configuring PHP covers changing PHP versions.
The verdict
Attackers moved on php2shell within hours of PHP’s 21 October 2026 disclosure, and none of their attempts against InstaWP-hosted sites succeeded. The order of events did the work: upload-progress was off before the details were public, the nesting limit was down before the deep-nesting kit arrived, and patched PHP followed 21 minutes later.
Frequently asked questions
Was php2shell exploited in the wild?
InstaWP saw exploitation attempts within hours of PHP’s disclosure on 21 October 2026, including one campaign whose traffic matches the deep-nesting memory-exhaustion strategy in PHP’s advisory. None of the attempts against InstaWP-hosted sites succeeded.
How soon after disclosure did php2shell attacks start?
On InstaWP, an upload-progress scanner started 2 hours 20 minutes after PHP published the details at 14:00 UTC on 21 October 2026, and the exploitation-shaped deep-nesting campaign started 3 hours 32 minutes after.
Does max_input_nesting_level protect against php2shell?
Lowering max_input_nesting_level to 32 made PHP discard the over-nested fields that the deep-nesting campaign relied on, so it blocked that route on InstaWP. It is hardening, not a fix: install patched PHP as well.
Should session upload-progress stay off after patching PHP?
InstaWP keeps session upload-progress off after patching as extra protection, and PHP recommends keeping the interim measures in place. On InstaWP, a scanner was still probing for the feature hours after the patch was out.
Do InstaWP customers need to do anything about php2shell?
No. InstaWP applied the interim mitigation, the hardening and patched PHP on InstaWP-managed servers on 21 October 2026. The php2shell status page has the full customer guidance.
