The 'CDN Tsunami' Attack Turns a Trickle of Traffic Into a Flood at the Origin

Researchers show how the way big content delivery networks translate modern HTTP/3 requests into older HTTP/1.1 can multiply a small attack stream by up to 350 times against the website behind them.

ThreatVectr Newsdesk· 4 min read
Full-frame 16:9 photoreal editorial image of a dimly lit server rack in a data center, focused on a single rack unit with a glowing amber status LED, shallow de
Share

Key points

  • Researchers disclosed two denial-of-service attacks, collectively called CDN Tsunami, that abuse how large content delivery networks convert HTTP/3 traffic into HTTP/1.1 requests to the origin website.
  • The technique amplifies a low-bandwidth request stream by up to 350 times against the origin server behind the CDN.
  • The attacks were tested against Alibaba and Baidu, two of the largest CDN operators in China.
  • The problem sits in the translation layer between protocol versions, not in HTTP/3 itself.
  • Ordinary internet users are not the target, but websites hidden behind affected CDNs could be knocked offline by a single attacker with modest resources.

Security researchers have published details of a pair of denial-of-service attacks, meaning attacks designed to knock a website offline by overwhelming it with traffic, that turn the big infrastructure companies protecting websites into unwitting amplifiers.

The technique is called CDN Tsunami. It was first reported by The Hacker News.

Here is the short version. A content delivery network, or CDN, is a company that sits in front of a website, absorbs the traffic, and forwards genuine requests to the actual server. Think of it as a very large receptionist for the internet. The researchers found that when a CDN receives requests in the newest web protocol, HTTP/3, and then rewrites them into the older HTTP/1.1 format that many origin servers still expect, an attacker can craft the incoming traffic so the outgoing version is vastly larger. A small trickle in, a torrent out.

How much larger? Up to 350 times, according to the write-up.

What is actually being exploited?

The translation step between protocols, not HTTP/3 itself. HTTP/3 is the newest version of the web's core protocol and is designed to be faster on flaky connections. Origin servers, the machines that actually host a site's content, often still speak the older HTTP/1.1. The CDN acts as an interpreter between the two.

The two attacks abuse features of HTTP/3 (compact headers, request multiplexing, that sort of thing) that balloon in size once the CDN rewrites them for the older protocol. The attacker sends a modest stream. The origin sees a tsunami.

If that pattern sounds familiar, it should. Amplification attacks are one of the oldest tricks in the denial-of-service playbook, going back to DNS reflection in the 2000s. What is new here is the amplifier: a paid, industrial-scale CDN doing exactly what it was configured to do.

Who was tested, and were they vulnerable?

The researchers evaluated the attacks against Alibaba and Baidu, two of the largest CDN operators in China. Both handle a substantial share of Asian web traffic, so a workable attack against their translation logic is not academic.

The public disclosure does not read like a hypothetical. It reads like a measured result.

Detail Value
Attack name CDN Tsunami
Attacks disclosed 2
Peak amplification Up to 350x
CDNs tested Alibaba, Baidu
Protocol abused HTTP/3 to HTTP/1.1 translation

Should ordinary internet users worry?

Not directly. This is not a data breach and no personal information is at risk from the technique itself. The people who need to pay attention are the operators of websites that sit behind a CDN, especially anyone whose origin server is sized on the assumption that the CDN will smooth traffic rather than concentrate it.

If your favourite booking site or bank goes dark for an afternoon, this class of attack is one plausible reason. Nothing to do at your end beyond the usual: try again later, and be wary of any "the site is down, click here to log in" messages that arrive by email while an outage is in the news.

What should CDN customers do now?

Ask your provider whether their HTTP/3 front end and their HTTP/1.1 origin path have been reviewed for this specific amplification pattern. Rate limits at the origin help. So does capping the size and count of translated headers. Neither is exotic engineering. The fix here belongs to the CDN, not the customer, but a polite email focuses minds.

© 2026 Threat Vectr