SLEDGE HAMMER aka Edge Carpet Bombing: Exploiting CDN Infrastructure for Attack Amplification

How Attackers Can Turn a CDN’s Own Infrastructure Against the Origin

Modern Content Delivery Networks (CDNs) and reverse proxy services (like Cloudflare or Myra) are widely used as a first line of defense against DDoS attacks and abuse. They absorb traffic, apply rate limiting, and hide the origin server’s real IP address. However, a subtle but powerful technique exists that allows attackers to significantly amplify their attack traffic against the origin by abusing the CDN’s own edge infrastructure.

This method does not require compromising the CDN or finding origin IP leaks. Instead, it exploits how many CDNs handle connections from their own edge nodes to customer origins.

With this idea and a bit of vibecoding, we created a testing-toolkit and tested global and european DDoS and CDN providers using this attack technique. All of them were vulnerable, with amplification factors ranging from 50 to 5,000, with the majority falling between 100 and 200. And when we used POST requests to bypass caching (which most providers did not prevented), we always reached the origin server and delivered a much higher payload with Edge Carpet Bombing than if we had only used the IPs determined by DNS resolution.

The following infographic displays the workflow and impacts of the attack preparation and attack itself

How Normal CDN Traffic Flow Works

Under normal operation, a user’s request follows this path:

1. DNS resolves the domain to one (or a few) CDN edge nodes (usually via Anycast).
2. The edge node receives the request.
3. The edge node forwards the request to the origin server (origin pull).
4. The origin responds back through the same (or another) edge node.

CDNs typically apply rate limiting per edge node or per customer configuration. Because traffic is distributed across the CDN’s global network, individual edge nodes usually see only a fraction of the total traffic.

The Attack Technique: Multi-Edge Origin Access

The core issue is this:

Many CDNs allow any of their edge nodes to reach a customer’s origin server, not just the ones currently assigned by DNS.

An attacker who discovers this can do the following:

1. Enumerate a large number of edge node IP addresses belonging to the CDN (often publicly known or easily scraped).
2. Test which of those edge nodes can successfully reach the origin (by forcing the connection through a specific edge IP while setting the correct Host header).
3. Once a set of reachable edge nodes is identified, distribute attack traffic across all of them.

Instead of sending all malicious requests through the few edge nodes returned by DNS, the attacker routes requests through many different edge nodes in parallel.

Attack Amplification Example

Let’s say a target has the following protection in place:

• Rate limit: 1,000 requests per second per edge node
• The domain normally resolves to 2 edge nodes

Under normal circumstances, an attacker is limited to roughly 2,000 RPS before triggering rate limits.

However, if the attacker finds that 100 different edge nodes can reach the origin directly, they can now distribute their traffic:

• 1,000 RPS × 100 edge nodes = 200,000 RPS toward the origin

This is effectively a 100x amplification of the attack throughput without triggering per-edge rate limits on most nodes. And if the requests are multiplexed in such a way that every attacking bot cycles through the list of edge nodes with each request, the attack remains completely undetected.

Because each individual edge node only sees 1,000 RPS, the traffic can remain under the detection threshold of the CDN’s DDoS protection systems for longer - especially if the attack is distributed and does not look like classic Request Flood DDoS from a single source.

This technique is referred to as "CDN Edge Carpet Bombing" or "Multi-Edge Origin Flooding".

Why This Works

Several factors make this possible:

• Lack of strict edge-to-origin binding: Many CDNs do not enforce that only "authorized" edge nodes may connect to a customer’s origin. As long as the Host header is correct and the connection comes from a known CDN IP range, the request is often accepted.
• Asynchronous edge nodes: Edge nodes usually operate with limited real-time communication between each other regarding rate limiting and attack detection, especially during the early stages of an attack.
• Flexible origin connectivity: CDNs are designed to be flexible (e.g., for customers using multiple origins or during failover), which creates opportunities for abuse.

This behavior affects not only smaller reverse proxy providers but also major global CDNs, although the severity varies between providers.

How Easy Is It to Discover This Behavior?

Surprisingly easy. In terms of the DRS skill level, this attack falls under DRS 5 and higher. You will not find this attack-method offered in a booterservice, but any attacker who understands how the infrastructure works and is capable of creating their own toolkit can carry out this attack as soon as they encounter a target that uses CDN/reverse proxy technology. Together with Claude, we spent 3-4 hours vibecoding to create a toolkit that allows us to test every CDN provider for this vulnerability.

An attacker (or security researcher) only needs a relatively simple script that does the following:

1. Takes a list of edge node IPs or CIDR ranges.
2. For each IP, forces a connection to the target hostname through that specific IP (by patching getaddrinfo).
3. Sets the correct Host header.
4. Records whether the origin responds successfully.

Such a script can be written in Python in just a few hundred lines (using the requests and socket libraries). It can automatically expand CIDR ranges, perform fast TCP pre-checks, and support resuming interrupted scans — making it practical even against CDNs with thousands of edge nodes.

Once the list of "working" edge nodes is obtained, the attacker can use this list to distribute attack traffic across many nodes simultaneously.

Screenshots from our toolkit:

Impact and Implications

This technique has several concerning implications:

• Rate Limit Bypass/Amplification: Significantly increases the amount of traffic an attacker can push toward the origin.
• Complete Evasion / Slower Detection: Because traffic is spread across many edge nodes, it can take longer for the CDN to detect and mitigate the attack.
• Reduced Effectiveness of Per-Edge Protections: Many rate limiting and bot protection mechanisms lose effectiveness when traffic is intentionally distributed.
• Reconnaissance is Cheap: Discovering reachable edge nodes can be done with low resources and can be automated.

This is particularly dangerous against origins that rely heavily on the CDN for protection and have relatively weak direct rate limiting or authentication at the origin level.

CVE / CVSS Calculated 7.5

Since this security vulnerability is a system-wide issue affecting every vendor, a global CVE number cannot be assigned, and we see no point in applying for a CVE number for each vendor individually.

However, a CVSS score still can be calculated.

Conclusion

While CDNs remain one of the most effective layers of protection for most organizations, they are not immune to architectural abuse. The ability to reach origins through multiple (or many) edge nodes creates an amplification vector that can dramatically increase the power of application-layer attacks.

This is not a traditional vulnerability in the sense of a bug that can be easily patched in one place. It is more of an architectural behavior that exists across many reverse proxy and CDN providers. Defending against it requires a combination of stricter origin access controls, better coordination between edge nodes, and origin-level protections that do not solely rely on the CDN’s edge-based rate limiting.

As tooling to discover and exploit this behavior becomes more accessible, organizations relying on CDNs for DDoS and abuse protection should evaluate how many of their provider’s edge nodes can actually reach their origin — and whether that number is larger than expected.

If you have questions regarding our research, feel free to send us an email via "research@zero.bs" or click the button below and fill out the contact form on our cmpanys website

Disclaimer 1: this technique isnt new to us, we used it 10 years ago, together with a golden-ticket-bypass vs cloudflare, and it worked like charm. But nowadays, with all the CDNs and reverse proxies rolled out, its worth it to look at this attackmethod again, especially when you do redteaming

Disclaimer 2: this post, as well as the toolkit and graphics, was in large part produced by AI

• code: claude
• text: grok
• imagery except screenshots: notebooklm