# Patch-to-Exploit Speed Makes Route-Aware Detection Part of Patching ## Claim When attackers weaponize a public patch within hours, an update plan must include request-aware detection and compromise checks rather than treating installation as the finish line. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies to remotely reachable vulnerabilities whose fix or advisory reveals an exploitable path. - Detection must inspect every transport that can express the vulnerable route, including POST bodies and REST batch requests. - Emergency virtual patches reduce exposure but don't prove the site was clean before the rule arrived. ## Evidence [[3. Resources/Readwise/Articles/Ninety minutes watching attackers weaponize the WordPress core RCE]] reports exploitation roughly ninety minutes after release and explains why URL-only rules missed routing data carried in request bodies. ## Links - [[Zet · Infra-only defences miss most WordPress attacks]] — extends: infrastructure controls fail when they cannot see application semantics. - [[WordPress's Compatibility-First Culture Is Now Its Binding Security Constraint]] — applies-in: delayed breaking change raises the cost of emergency defense. - [[Update Signatures Prove Provenance Not Freshness]] — complements: a trusted update says who shipped it, not whether exploitation already occurred. - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — applies-in: the MOC lists this note under Synthesis additions (2026-08-11 — patch-to-exploit response).