My concern with the upcoming PHP RCE disclosure is how many systems could remain exposed long after patches become available. Roughly a third of PHP websites still run PHP 5 or 7. Some operators will need to migrate old applications before they can move to a supported release. Even on supported versions, plenty of systems won't be patched immediately. Some owners won't notice the advisory; others can't deploy an update that quickly. We still need the technical details to understand the actual exposure. If reliable, unauthenticated exploitation works across common deployments, I'd expect automated mass exploitation very quickly. AI-assisted exploit development and payload adaptation could shorten the response window further. For detection teams, I'd prepare now for the activity that follows. I expect plenty of familiar shells, downloaders, webshells and persistence mechanisms, even though the entry point is new. I've published a process-watcher guide with PHP configurations to record descendant processes and their command lines, with optional termination rules for shells, interpreters and known payload patterns: github.com/Neo23x0/process-w… Short-lived commands can still be recorded, even when they finish before the kill response arrives. Activity entirely inside the PHP worker remains a blind spot. THOR Lite already includes relevant detections. We'll also review internally what additional post-exploitation coverage we can make publicly available. After patching, check for compromise. An update doesn't remove an existing webshell or invalidate stolen credentials.