Automated scanners do not pre-screen targets for CMS type. They send WordPress probe requests to every IP address they scan, regardless of what is running on the server. A flat-file PHP site on shared hosting receives the same wp-login.php probe requests as any WordPress installation.
This is actually a mild security advantage of the flat-file architecture: probes for WordPress vulnerabilities find nothing, because the targeted endpoints do not exist. The scanner reports a 404 or a BOMB response and moves on. There is no WordPress attack surface to exploit.
The IEO Engine gate classifies WordPress fingerprint probes as BOMB events. The BOMB response is slow-drip connection exhaustion: the gate serves one byte every 30 seconds, keeping the attacker's connection open and consuming their socket without providing content.
A typical WordPress scanner that expects a response in under a second receives one byte, then waits 30 seconds for the next, then another 30 seconds, and so on. The scanner's connection thread is occupied for an extended period before timing out. At scale — the MM deployment logs 6-12 BOMB events daily — this consumes meaningful attacker infrastructure resources.
BOMB event patterns provide security intelligence. A single BOMB event from a random IP is routine automated scanning — millions of sites receive identical probes. Multiple coordinated BOMB events from different IPs targeting the same probe path in a short window suggests targeted reconnaissance.
The MM deployment has logged coordinated WordPress probe waves — multiple IPs from the same geographic cluster hitting the same probe paths within a 90-second window. These events are logged, IP ranges are noted, and persistent coordinated probe sources are added to the FOE IP prefix list in iff_config.json.