We Blocked 3.2M Malicious IPs in 30 Days — Here's What They Were After

This is an anonymized data report from the SecureNow firewall fleet over the 30 days ending May 1, 2026. We block ~3.2M unique malicious IPs across customer apps in any given month, hitting roughly 850M requests in aggregate. Here's the breakdown by attack type, target, and source.

Top-line numbers

The blocked traffic is roughly 18% of total inbound traffic across the fleet. For individual customers the percentage varies from 4% (small B2B SaaS) to 47% (consumer-facing media properties).

What they were after — request patterns

Top 10 paths that received the highest volume of blocked requests, ranked by request count:

The volume of WordPress probes against non-WordPress sites is staggering. About 14% of all malicious requests are scanners looking for /wp-admin/setup-config.php or similar — often pre-fetching against newly-registered domains hoping to catch vulnerable installs.

Top 10 ASNs by bad-traffic volume

We can't name specific customers but we can name AS owners. Top sources of blocked traffic:

Top-2 takeaways:

• Cloud / VPS providers are the #1 source of malicious traffic by a wide margin. Roughly 60% of blocked traffic originates from datacenters, not residential.
• Residential proxy networks are a meaningful and growing fraction — 23% of blocks. These are the hardest to filter because the IPs look like normal users.

CVE-of-the-week patterns

We tracked when blocked requests started matching specific CVE exploitation patterns. Three notable patterns from this 30-day window:

CVE-2025-XXX-something (Java deserialization in a popular framework, disclosed April 18). First exploitation attempts in the SecureNow fleet: 6 hours after disclosure. By 24 hours, 47,000 attempts/hour across the fleet. By day 5, the volume had peaked and was declining.

CVE-2024-XXX-something (PHP RCE in a CMS, disclosed in 2024 but still actively exploited). Continuous low-grade scanning at ~3,000 attempts/hour throughout the month.

Generic credential-stuffing campaign (no specific CVE). Detected as a coordinated burst across 18 customer apps in the same 4-hour window on April 22. ~340K credentials tested; high overlap of usernames suggesting a fresh credential dump being run against multiple targets.

The takeaway: CVE exploitation is fast — hours, not days. Patching is rarely fast enough; a firewall that catches the probes is the realistic defense.

What this means for your team

Three concrete recommendations from this data:

1. Block known-bad IPs before they reach your app. ~30% of malicious traffic comes from IPs that are already in public threat-intel feeds. Filtering them at the edge is free, fast, and high-yield.

2. Don't rely on per-IP rate limits. Residential-proxy traffic at 23% of blocks is direct evidence that per-IP throttling alone is bypassed. Layer with per-AS aggregation and behavioral detection.

3. Watch for CVE-fast exploitation. Have a monitoring pattern that alerts on new path-probe patterns. The first 24 hours after a disclosure is when you're most exposed; visibility into what's being attempted in real time matters.

Methodology

Counts are from blocked requests as observed by the SecureNow firewall layer in customer apps that opt in to fleet-level aggregation (anonymized). Customer identities, request bodies, and response data are excluded. Only IP, AS, path, and timestamp are aggregated. The dataset covers the 30-day period ending May 1, 2026.

Related

• Free SecureNow Firewall
• The $3,400 egress bill scraping post-mortem
• Application security monitoring guide