Toxic combinations: when small signals add up to a security incident

When harmless signals converge into a breach

A single request to a login page at 3 AM rarely raises alarms. Neither does an occasional ?debug=true parameter appended to a URL. But when the same source combines those seemingly innocuous actions with probing across multiple hosts and paths, a pattern emerges that looks less like noise and more like reconnaissance for an attack.

Security teams typically evaluate individual requests in isolation, relying on point defenses like WAFs, bot detection, and API protection to score each interaction's risk on its own. That approach misses the bigger picture: real incidents often have no obvious payload, no clean signature, and no single event that screams "attack." What they do have is a convergence of context — a toxic combination where minor misconfigurations and overlooked anomalies compound into a genuine vulnerability.

Cloudflare's position on the network edge allows it to observe requests across entire application stacks and correlate signals that might otherwise remain siloed. The detections it builds around these toxic combinations shift the analytical focus from individual request risk to broader attacker intent, combining several contextual signals:

• Bot signals indicating automated traffic
• Application paths, particularly sensitive ones like admin, debug, metrics, search, and payment flows
• Anomalies such as unexpected HTTP codes, geo jumps, identity mismatches, high ID churn, and distributed rate-limit evasion
• Vulnerabilities or misconfigurations including missing session cookies, absent auth headers, and predictable identifiers

How prevalent are toxic combinations?

Analysis of a 24-hour window of Cloudflare data reveals that roughly 11% of hosts examined showed susceptibility to these patterns, though that figure is heavily skewed by WordPress installations. When WordPress is excluded, only 0.25% of hosts demonstrated signs of exploitable toxic combinations. While the absolute numbers are small, each affected host represents a potential compromise vector.

To categorize findings, researchers break detections into three attack stages:

• Estimated hosts probed: Unique hosts where HTTP requests targeted sensitive paths such as /wp-admin
• Estimated hosts filtered by toxic combination: Hosts that met the specific criteria for a toxic combination
• Estimated reachable hosts: Hosts that actually responded successfully to an exploit attempt — the "smoking gun." Paths were validated to filter out noise from authenticated routes, redirects, and origin misconfigurations that serve success codes improperly

Detection queries alone are not sufficient to confirm a finding; reachability testing is required to eliminate false positives. Cloudflare Log Explorer allows these queries to run against unsampled logs for more accurate results.

Exposed admin endpoints under automated probing

Automated tools frequently scan for common administrative login pages — WordPress panels at /wp-admin, database managers, and server dashboards. The risk extends beyond the obvious: successful brute force attempts can turn a compromised host into a botnet member that probes additional targets.

Beyond direct compromise, publicly accessible admin panels enable two downstream threats:

• Exploit scanning: Attackers fingerprint software versions (Tomcat, WordPress, etc.) and then target known CVEs
• User enumeration: Admin panels often leak valid usernames through error messages, strengthening subsequent phishing or credential-stuffing campaigns

The toxic combination here pairs bot automation with exposed management interfaces including /wp-admin/, /admin/, /administrator/, /actuator/*, /_search/, /phpmyadmin/, /manager/html/, and /app/kibana/. A templatized version of the detection query can be executed in Cloudflare Log Explorer.

Mitigation for exposed admin endpoints follows standard hardening practices:

1. Implement Zero Trust Access so administrative interfaces require authentication before reaching the origin
2. If an endpoint must remain public, deploy a challenge platform to add friction for bots
3. Use IP allowlists at the WAF or server level so admin paths are reachable only from corporate VPN or office addresses
4. Cloak admin paths by renaming default URLs (e.g., change /wp-admin to a unique string)
5. Apply geo-blocking if administrators operate only from specific regions
6. Enforce MFA at every administrative entry point

Unauthenticated APIs with enumerable records

A more insidious finding involves API endpoints that are openly accessible without any authentication layer — a direct violation of OWASP API2:2023 (Broken Authentication). The danger compounds when these endpoints identify records using simple, sequential integers rather than random identifiers, enabling the OWASP API1:2023 Broken Object Level Authorization pattern.

This creates a "zero-exploit" vulnerability: no hacking skill required, no payload injection needed. An attacker simply increments a number in a URL to walk through an entire database. The consequences include:

• Mass data exposure: Complete customer datasets scraped without ever visiting the website's front end
• Secondary attacks: Exfiltrated data fuels targeted phishing and account takeover attempts
• Regulatory risk: PII exposure triggers serious GDPR/CCPA compliance failures
• Fraud: Competitors or malicious parties gain visibility into business volume and customer base

The toxic combination pairs missing security controls with automated traffic targeting specific API endpoints. Detection queries check for bot scores and predictable identifiers, while additional validation examines high cardinality, stable response sizes, and missing authentication.

Immediate remediation steps include:

1. Require a valid session or API key for affected endpoints — never allow anonymous access to PII or business data
2. Implement proper authorization checks (IDOR validation) so the backend confirms the authenticated user has permission for each requested record
3. Replace sequential integer IDs with UUIDs to make record guessing computationally infeasible
4. Enable API Shield features including Schema Validation and BOLA Detection

Debug parameter probing as a recon signal

The opening scenario — a lone IP appending ?debug=true across multiple hosts — represents a quieter but equally telling toxic combination. While debug flags don't directly steal data, they hand attackers a detailed map of internal infrastructure that substantially increases the odds of follow-on attacks succeeding.

What exposed debug endpoints reveal:

• Hidden data fields: Sensitive internal information never intended for user visibility
• Technology stack details: Exact software versions allowing attackers to research known exploits and SQL injection techniques
• Logic hints: Stack traces and verbose error messages that reveal how application code operates

The detection combines automated probing with misconfigured diagnostic flags across multiple hosts and paths. Validation on sampled traffic examines repeated probing behavior, response sizes, and schema disclosure.

Hardening against debug parameter abuse involves several layers:

1. Set all debug and development environment variables to false in production configurations
2. Strip known diagnostic parameters (?debug=, ?test=, ?trace=) at the WAF or API gateway edge before requests reach application servers
3. Configure web servers like Nginx or Apache to serve generic error pages instead of detailed stack traces
4. Audit Firebase or NoSQL database security rules to restrict .json path access so public users cannot dump entire schemas

Toxic combinations aren't exotic exploits that evade detection through sophistication — they materialize from mundane signals amplified across a stack. The practical takeaway: hardening shouldn't focus solely on blocking individual attack vectors. It must also surface the intersections where small omissions become a coherent path to compromise.

Monitoring and Search Endpoints Left Open to the Internet

Attackers are actively scanning for internal infrastructure exposed through overly permissive access controls. Three findings stand out: publicly reachable health check and monitoring dashboards, unauthenticated search endpoints, and successful SQL injection attempts on application paths.

Exposed Monitoring Dashboards Provide a Reconnaissance Playbook

Health check and monitoring dashboards—including paths like /actuator/metrics—are responding to any request from the Internet. The templatized query below detects this exposure:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '%/actuator/metrics%' // an example
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

These endpoints rarely expose customer credentials directly, but they give attackers a blueprint for a targeted attack. Real-time CPU and memory telemetry lets attackers time a Denial of Service (DoS) attack for when systems are already strained. The logs also expose internal service names, dependency versions, and environment hints, which help attackers pinpoint known vulnerabilities and chain exploits to bypass security controls or escalate privileges.

Evidence of the issue comes from a toxic combination of misconfigured access controls and automated reconnaissance focused on the paths /actuator/metrics, /actuator/prometheus, and /health:

Immediate mitigation steps:

1. Block via WAF: Create a firewall rule denying external traffic to any path containing /actuator/ or /prometheus.
2. Restrict binding: Reconfigure application frameworks to serve these endpoints only on localhost (127.0.0.1) or a private management network.
3. Add authentication: If web access is required, enforce at minimum complex Basic Auth or mTLS.
4. Disable unused features: Turn off any Actuator (Spring Boot) endpoints not required for production monitoring.

Unauthenticated Search Endpoints Enable Direct Index Dumps

Search endpoints such as Elasticsearch or OpenSearch are reachable from the public Internet without any authentication:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
AND clientRequestPath like '%/\_search%'
AND NOT match(extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$')
GROUP BY
  clientRequestHTTPHost

This vulnerability requires no technical skill to exploit yet carries a high impact. Attackers can dump entire indices in minutes, map out your stored data to identify further high-value targets, and—depending on permissions—modify or delete the search index, causing a service outage.

The finding combines misconfigured exposure with automated enumeration targeting /_search, /_cat/indices, and /_cluster/health. The query below checks for bot score and paths; signals like repeated query patterns, response sizes, and schema disclosure were validated against a sample of matching traffic:

Recommended fixes:

1. Restrict network access: Update firewall or security group rules so search ports (e.g., 9200, 9300) and paths are reachable only from internal IPs.
2. Enable security features: Turn on authentication (Shield, Search Guard, or the built-in security module) for every API call to the cluster.
3. Deploy WAF rules: Block public requests containing /_search, /_cat, or /_cluster.
4. Audit for exfiltration: Inspect database logs for large "Scroll" or "Search" queries from unknown IPs to determine the extent of any data loss.

Successful SQL Injection Attempts on Application Paths

Attackers are sending SQL injection payloads designed to trick databases, and the applications are returning HTTP 200 success codes:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
AND wafmlScore<30
  AND edgeResponseStatus = 200
AND LOWER(clientRequestQuery) LIKE '%sleep(%'
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

Because these requests return a success status, they are easy to miss among legitimate traffic. An attacker can use trial and error to refine payloads until one bypasses filters, then slowly extract database contents or sensitive data (such as API keys) present in URLs. Automated alerting that only flags denied attempts will not catch a successful exploit.

This finding arises from a combination of automated bot signals, anomalies, and application-layer vulnerabilities across multiple paths:

Immediate actions:

1. Virtual patch: Update WAF rules to block the identified SQL patterns, including time-based probes.
2. Sanitize inputs: Refactor backend code for affected paths to use prepared statements or parameterized queries.
3. Stop secret leakage: Move sensitive data from URL parameters to request bodies or headers; rotate any exposed keys.
4. Forensic review: Examine database logs around the HTTP 200 responses to assess whether data extraction succeeded.

Toxic Combinations on Payment Flows

Card testing and card draining are common fraud tactics. An attacker buys a batch of stolen credit card numbers, tests them with small transactions on a site, and then uses the valid ones to buy gift cards or other goods. Two detection patterns capture this behavior on payment paths such as /payment, /checkout, and /cart.

Suspected Card Testing

In this scenario, either the hourly request volume from bots or the hourly payment success ratio spiked by more than 3 standard deviations from the prior 30-day hourly baselines. Such a spike can indicate an attacker validating stolen cards. Marketing campaigns can cause request spikes and payment outages can cause success ratio drops, so those factors must be ruled out:

A drop in payment success ratio coinciding with a request spike—in the absence of a campaign or outage—could signal a card-testing run. The detection combines bot signals and anomalies:

To mitigate, set the 30-day hourly request volume baseline for payment paths as the rate limit for all requests with bot scores below 30 on those paths.

Suspected Card Draining

Here, the hourly request volume from humans (or bots impersonating humans) or the hourly payment success ratio spiked by more than 3 standard deviations above the 30-day baseline. This could mean attackers are purchasing goods with valid but stolen cards. Marketing spikes are again possible, so checking typical request density per IP address is essential context:

Success ratio spikes combined with high request density per IP—absent a campaign or other factor—could indicate fraudulent purchases. Each successful transaction is a direct revenue loss or an impending chargeback. Detection again relies on bot signals paired with anomalies:

Mitigation steps:

• IP-based rate limiting: Apply rate limits to requests with bot score greater than or equal to 30 on payment endpoints, based on IP density.
• Success ratio alerts: Alert when the success ratio for human traffic (bot score >= 30) on payment endpoints deviates by more than 3 standard deviations from its 30-day baseline.
• Challenge suspicious activity: Trigger a challenge when a high bot score request hits a payment flow more than 3 times in 10 minutes.

Planned Integration and Remediation

These toxic combination detections are being integrated into the Security Insights dashboard for immediate visibility. The roadmap also includes AI-assisted remediation, where the dashboard will propose the specific WAF rule or API Shield configuration needed to neutralize a detected risk—beyond simply flagging it.