Post by @ifin@infosec.exchange

2026-10-22 06:02 UTC

After reviewing the "evidence" of exploitation of #PHP2Shell and finding it wanting, we have removed the "EITW" tag from our story. Our standard for "exploited in the wild" is not sprays against targets. It is direct observables from successful exploitation. That's a higher bar to clear, but for such a scary vulnerability, hardly impossible. So far however, we have not seen that level of evidence.

Replies (3)

@herbz@cyberplace.social 2026-10-22 06:49

@ifin@infosec.exchange with the breadth of vulnerable systems and utilization of the vulnerability by many different actors, I wonder how transferable exploitation evidence will be? Especially for post exploitation activity (which for systems with terrible logging will likely be the only findable evidence) 🤔

Open ##5215642
@brib@bribstodon.xyz 2026-10-22 09:01

@ifin@infosec.exchange Thanks, I was wondering about this. A lot of security organisations saying attacks have been attempted but no information as to whether said attacks were successful

Open ##5215647
@Spartan_1986@infosec.exchange 2026-10-22 15:22

@ifin@infosec.exchange My corporate pen tester ran the exploit against clones of servers and purple team analyzed the telemetry and here are the IOCs we've settled on: IOCs - User-Agent: Mozilla/5.0 (php2shell-test/1.0.0) and /2.0.0 - multipart field PHP_SESSION_UPLOAD_PROGRESS = "pwn" - PHPSESSID sent as a form field with a single NUL byte (that's the leak-A trigger, never seen in legit traffic) - a multi-MB "big" field in the body (7-24MB, the OOM primer) - 1000+ fields f0000/f0001/... (trips max_input_vars) - response Set-Cookie: PHPSESSID= longer than ~32 chars (up to 512 URL-encoded bytes = the ASLR heap leak itself) - if it lands: id>/tmp/, uid=33, FIRE_OK We have found no evidence of compromise with these (other than the pen test) so we have no evidence of exploitation in the wild, but posting nonetheless in case there is something other's can use. #php2shell

Open ##5215648