Security researchers have disclosed a pair of denial-of-service techniques — collectively named CDN Tsunami — that turn the protocol translation layer of major content delivery networks into a force multiplier for attackers. The core issue: when a CDN accepts lightweight client-facing HTTP/3 (QUIC) requests and translates them into HTTP/1.1 requests toward the origin server it fronts, the conversion process amplifies a low-bandwidth attacker stream by as much as 350x at the origin.
The techniques were evaluated against major CDN providers including Alibaba and Baidu, demonstrating that this is not a theoretical edge case — it is a structural weakness in how a significant portion of the internet's front-door infrastructure handles protocol downgrade. No CVE identifiers have been assigned at the time of disclosure; this is an architectural/design-class weakness rather than a single patchable code flaw, which makes your defensive posture — not a patch cycle — the primary control.
If you operate a web property behind a CDN, you are in scope. If your origin accepts traffic from anything other than authenticated CDN edge nodes, you are especially in scope. This post breaks down how the amplification works, how to detect it in your telemetry, and how to harden your origin before someone else benchmarks the technique against your infrastructure.
Technical Analysis
What Is Actually Being Abused
HTTP/3 runs over QUIC (UDP/443) and was designed to be efficient: compact headers via QPACK compression, multiplexed streams, and minimal connection setup overhead. HTTP/1.1, which most origin servers still speak, is comparatively verbose — plain-text headers, no compression of header fields, and heavy per-request overhead.
The amplification lives in the translation gap between the two:
- An attacker sends compact HTTP/3 requests to the CDN edge. QPACK-compressed headers and QUIC stream multiplexing mean the attacker can push a high request rate with very little bandwidth.
- The CDN edge converts each request to HTTP/1.1 toward the origin. Headers decompress into plain text, CDN-injected headers (
X-Forwarded-For,Via,True-Client-IP, vendor-specific telemetry headers) are appended, and each request may ride on separate or pipelined TCP connections. - The origin receives a traffic volume — in bytes and/or request rate — that is a multiple of what the attacker actually sent. In the researchers' measurements, up to 350x amplification depending on the CDN's translation behavior and the request profile.
The two disclosed techniques differ in where the amplification lands: one primarily amplifies bandwidth toward the origin (header decompression plus injected headers), while the other amplifies request/connection processing load (one QUIC stream fanning out into expensive HTTP/1.1 connection handling at the origin). Both exhaust origin-side resources while the attacker — and the CDN edge — remain comfortably within normal operating thresholds.
Why This Is Hard for CDN Providers to Simply "Fix"
This is important for your defensive planning: the CDN edge may not see this as an attack at all. Each individual HTTP/3 request is legitimate-looking. Edge-side rate limiting thresholds calibrated for L7 DDoS may never trip, because the edge isn't the victim — your origin is. The amplification factor means an attacker can rent a trivial amount of bandwidth and still saturate a mid-size origin's ingress or exhaust its worker pools.
Exploitation Status
- CVE assignment: None at time of writing. This is a protocol-translation design weakness spanning multiple CDN implementations, not a discrete vendor bug.
- CISA KEV: Not listed.
- Public research/PoC: The techniques were demonstrated by researchers against production CDN infrastructure (Alibaba, Baidu) under controlled evaluation, meaning the attack path is proven reproducible at scale. Historically, DoS amplification research of this class (compare: the HTTP/2 Rapid Reset wave of 2023, later assigned CVE-2023-44487, which is referenced here strictly as precedent for how quickly amplification research converts to in-the-wild abuse) moves from disclosure to weaponization within weeks.
- Active exploitation: Not publicly confirmed as of disclosure, but defenders should assume the technique is now in every DDoS-for-hire operator's evaluation pipeline.
Who Is Affected
- Any organization fronting an HTTP/1.1-only origin behind a CDN that terminates HTTP/3 at the edge.
- Origins that are directly reachable from the internet (no CDN-IP allowlisting, no authenticated origin pull) — these can be attacked directly or via the CDN, whichever is cheaper for the attacker.
- Applications with expensive per-request processing (search, API endpoints, dynamic rendering) — request-rate amplification hits these hardest.
Detection & Response
The most reliable detection surface for CDN Tsunami is the origin itself: request rate and byte volume from CDN egress IPs diverging from baseline, QUIC traffic arriving at hosts that should never speak QUIC, and direct-to-origin connection attempts. The detections below are built around those three observables.
Sigma Rules
---
title: QUIC HTTP/3 Traffic Reaching Origin Web Server Directly
id: 3f8a2c14-7b5e-4d91-a6c2-9e1f4b8d7032
status: experimental
description: Detects inbound UDP/443 (QUIC/HTTP-3) connections to origin web server processes. Origins fronted by a CDN that terminates HTTP/3 at the edge should only ever receive TCP-based HTTP/1.1 from CDN egress IPs. QUIC arriving at the origin indicates direct-to-origin probing or an attempt to exploit HTTP/3 translation amplification (CDN Tsunami).
references:
- https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html
author: Security Arsenal
date: 2026/08/20
tags:
- attack.impact
- attack.t1498
logsource:
category: network_connection
product: windows
detection:
selection:
DestinationPort: 443
Protocol: udp
Initiated: 'false'
Image|endswith:
- '\w3wp.exe'
- '\httpd.exe'
- '\nginx.exe'
- '\Microsoft.Web.Host.exe'
falsepositives:
- Origins legitimately serving HTTP/3 directly to clients (no CDN in path). Confirm your architecture before deploying.
level: high
---
title: Web Request With IP-Literal Host Header - Possible Direct-to-Origin Access
id: 91d4e7b2-3c6f-4a08-b5d1-2e7c9f4a6105
status: experimental
description: Detects HTTP requests where the Host header is a raw IPv4 address rather than a hostname. Requests arriving via a CDN carry the public hostname; IP-literal Host headers are characteristic of direct-to-origin scanning and attack traffic that bypasses CDN protections, a common companion to CDN Tsunami amplification campaigns.
references:
- https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html
author: Security Arsenal
date: 2026/08/20
tags:
- attack.impact
- attack.t1498
- attack.reconnaissance
- attack.t1595
logsource:
category: webserver
detection:
selection:
cs-host|re: '^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}(:\d+)?$'
falsepositives:
- Internal health checks and load balancer probes using IP-literal hosts. Allowlist known monitoring infrastructure.
- Legacy API clients hardcoded to IP addresses.
level: medium
Why these two rules: The first catches the reconnaissance and direct-attack path — QUIC should never terminate on an origin behind an HTTP/3-terminating CDN, so any UDP/443 inbound to a web worker process is anomalous by architecture, not by heuristic. The second catches the bypass attempt that almost always accompanies these campaigns: attackers who have resolved your origin's real IP hammering it directly with IP-literal Host headers. Both are low-noise in a correctly architected environment.
KQL (Microsoft Sentinel / Defender)
This hunt assumes your origin web logs reach Sentinel via IIS/Apache log ingestion (W3CIISLog) or as CEF/syslog from your reverse proxy (CommonSecurityLog), and that firewall/NSG flow data is available for the QUIC check. It surfaces the two primary CDN Tsunami observables: request-rate divergence from a single egress source and UDP/443 flows toward origin subnets.
// CDN Tsunami Hunt 1: Request-rate spike per source IP at the origin
// A single CDN egress IP (or direct attacker IP) generating an anomalous
// request rate is the signature of translation amplification.
// Tune the threshold (500 req / 5 min) to your origin's baseline.
let threshold = 500;
W3CIISLog
| where TimeGenerated > ago(24h)
| summarize RequestCount = count(),
DistinctUris = dcount(csUriStem),
BytesSent = sum(scBytes),
BytesReceived = sum(csBytes)
by cIP, bin(TimeGenerated, 5m)
| where RequestCount > threshold
| project TimeGenerated, cIP, RequestCount, DistinctUris, BytesSent, BytesReceived
| order by RequestCount desc;
// CDN Tsunami Hunt 2: QUIC (UDP/443) flows inbound to origin web tier
// Origin behind an HTTP/3-terminating CDN should see ZERO inbound UDP/443.
// Any hits here = direct-to-origin probing or attack staging.
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationPort == 443
| where Protocol =~ "UDP"
| where DeviceAction !in ("Deny", "Drop")
| summarize FlowCount = count(),
TotalBytesIn = sum(tolong(ReceivedBytes)),
Sources = make_set(SourceIP, 50)
by DestinationIP, bin(TimeGenerated, 10m)
| order by FlowCount desc;
// CDN Tsunami Hunt 3 (Syslog-ingested origins, e.g., Linux/nginx via CEF):
// Hour-over-hour request volume comparison to catch slow-ramp amplification.
Syslog
| where TimeGenerated > ago(2h)
| where SyslogMessage has_any ("GET ", "POST ", "HEAD ")
| summarize CurrentHour = countif(TimeGenerated > ago(1h)),
PriorHour = countif(TimeGenerated between (ago(2h) .. ago(1h)))
by Computer
| where PriorHour > 0 and CurrentHour > (PriorHour * 3)
| project Computer, PriorHour, CurrentHour,
GrowthMultiple = round(todouble(CurrentHour) / PriorHour, 2)
| order by GrowthMultiple desc;
Hunt 3 is the one I'd actually run first in production. Amplification attacks frequently ramp gradually to stay under fixed thresholds — a 3x hour-over-hour growth on any single origin host with no corresponding deployment or marketing event is worth a page. Calibrate the multiplier against your traffic seasonality before alerting on it.
Velociraptor VQL
For live origin triage during a suspected event, this artifact enumerates established TCP connections to the web tier and aggregates by remote address — instantly surfacing whether load is concentrated in a handful of CDN egress IPs (expected) versus a diffuse or unexpected source set (bypass or abuse). The QUIC check runs alongside it.
-- CDN Tsunami origin triage: aggregate established connections to web ports
-- by remote address. Investigate remotes that are NOT in your CDN's
-- published egress ranges, and any remote with an outsized connection count.
LET web_ports = (80, 443, 8080, 8443)
SELECT RemoteIP,
count() AS ConnectionCount,
group_by=RemoteIP,
array_agg(Path) AS ListeningProcesses,
array_agg(LocalPort) AS LocalPorts
FROM (
SELECT split(string=RemoteAddress, sep=':')[0] AS RemoteIP,
int(string=split(string=LocalAddress, sep=':')[-1]) AS LocalPort,
Path, Status
FROM netstat()
WHERE Status =~ 'ESTAB'
AND int(string=split(string=LocalAddress, sep=':')[-1]) IN web_ports
)
GROUP BY RemoteIP
ORDER BY ConnectionCount DESC
LIMIT 100
Pair this with your CDN provider's published egress IP list (Cloudflare, Akamai, Alibaba Cloud CDN, and Baidu Cloud all publish theirs as JSON endpoints — automate a nightly pull and diff). Any high-count remote not in that list during an event is your incident.
Remediation / Verification Script
This Bash script hardens a Linux/nginx origin in the three ways that matter for CDN Tsunami: restricting ingress to CDN egress IPs, applying request and connection rate limits, and verifying the origin is not advertising HTTP/3 to the public internet. Review before running; it is written for nftables-based hosts with nginx.
#!/usr/bin/env bash
# CDN Tsunami origin hardening - verify + enforce
# Test in staging. Assumes nftables and nginx.
set -euo pipefail
CDN_ALLOWLIST="/etc/nginx/cdn_egress_allowlist.conf"
RATELIMIT_CONF="/etc/nginx/conf.d/tsunami_ratelimit.conf"
echo "=== [1/5] Checking whether origin is advertising HTTP/3 (Alt-Svc) ==="
ORIGIN_IP="$(curl -4 -s ifconfig.me)"
if curl -sI "https://${ORIGIN_IP}" -k | grep -i 'alt-svc.*h3'; then
echo "[!] WARNING: Origin advertises HTTP/3 directly. Disable QUIC on the origin;"
echo " HTTP/3 termination belongs at the CDN edge only."
else
echo "[+] OK: No Alt-Svc h3 advertisement on origin."
fi
echo "=== [2/5] Checking for listeners on UDP/443 (QUIC on origin) ==="
if ss -lunp | grep -q ':443'; then
echo "[!] WARNING: UDP/443 listener found on origin:"; ss -lunp | grep ':443'
else
echo "[+] OK: No UDP/443 listener on origin."
fi
echo "=== [3/5] Installing CDN egress allowlist for nginx ==="
# Replace with YOUR CDN's published egress ranges. Pull them fresh from the
# provider's API - these example ranges are placeholders.
cat > "${CDN_ALLOWLIST}" <<'EOF'
# CDN egress allowlist - regenerate nightly from provider API
# Example (Cloudflare format shown; substitute your provider):
# allow 173.245.48.0/20;
# allow 103.21.244.0/22;
# allow 103.22.200.0/22;
deny all;
EOF
echo "[+] Wrote ${CDN_ALLOWLIST} - POPULATE WITH REAL CDN RANGES BEFORE USE"
echo "=== [4/5] Installing nginx rate/connection limits ==="
cat > "${RATELIMIT_CONF}" <<'EOF'
# CDN Tsunami mitigation: cap request rate and concurrent connections
# per client IP (here, per CDN egress node). Tune to your baseline.
limit_req_zone \$binary_remote_addr zone=tsunami_req:10m rate=50r/s;
limit_conn_zone \$binary_remote_addr zone=tsunami_conn:10m;
server {
# Apply inside your real server block / location as appropriate
limit_req zone=tsunami_req burst=100 nodelay;
limit_conn tsunami_conn 200;
# Return 444 (connection closed, no response) instead of burning
# CPU rendering a 503 page during floods.
error_page 429 = @flood;
location @flood { return 444; }
}
EOF
nginx -t && echo "[+] nginx config valid - reload with: systemctl reload nginx"
echo "=== [5/5] nftables: drop non-CDN traffic to web ports at the host ==="
echo "Add your CDN egress set to an nft set, then:"
cat <<'EOF'
nft add set inet filter cdn_egress '{ type ipv4_addr; flags interval; }'
# nft add element inet filter cdn_egress { <CDN-CIDR-1>, <CDN-CIDR-2>, ... }
nft add rule inet filter input ip saddr @cdn_egress tcp dport {80,443} accept
nft add rule inet filter input tcp dport {80,443} drop
nft add rule inet filter input udp dport 443 drop # QUIC has no business here
EOF
echo "=== Done. Monitor request amplification ratio (origin bytes vs edge bytes) daily. ==="
Remediation
Because CDN Tsunami has no single patch, remediation is layered. Work through these in order of impact:
- Lock down origin ingress to CDN egress IPs only. This is the single highest-value control. If the origin answers arbitrary internet traffic, attackers bypass the CDN entirely — or worse, compare direct and translated paths to pick the cheapest one. Enforce at the network layer (security groups, nftables, cloud firewall), not just the application layer. Every major CDN publishes machine-readable egress ranges; automate the sync.
- Authenticate origin pulls. Configure your CDN to present a secret header or, better, mutual TLS on origin connections, and reject anything without it. IP allowlists leak; mTLS does not. Alibaba Cloud CDN, Baidu Cloud CDN, Cloudflare (Authenticated Origin Pulls), and Akamai all support this.
- Enable end-to-end HTTP/2 or HTTP/3 to the origin where your CDN supports it. The amplification lives in the HTTP/3→HTTP/1.1 translation. If the edge can speak a modern protocol upstream, the decompression/injection asymmetry shrinks dramatically. Check your provider's current documentation — support expanded significantly after the 2023 Rapid Reset disclosures.
- Apply origin-side rate and connection limits keyed on CDN egress IPs (see script above). A 350x amplification means even a modestly sized origin limit will force the attacker's cost up by the same factor.
- Remove HTTP/3 from the origin entirely. If your origin advertises
Alt-Svc: h3or listens on UDP/443, you've handed attackers a direct QUIC path around the edge. The verification steps in the script check both. - Instrument the amplification ratio. Log bytes-in at the CDN edge versus bytes-in at the origin per time window (your CDN analytics versus your origin logs). A sustained divergence well above your normal header-injection overhead is your earliest reliable indicator — build the dashboard now, not during the incident.
- Engage your CDN provider. Ask specifically: what request-rate and bandwidth limits apply per-egress-node toward origins, whether translation-layer amplification mitigations have been deployed in response to this research, and whether per-request fan-out controls are available. Providers named in the research (Alibaba, Baidu) are on notice; hold yours to account through your TAM.
- Load-test your own translation path. Work with your provider or a red team to measure your actual amplification factor against non-production infrastructure. You cannot tune thresholds you have never measured.
Deadlines: There is no CISA mandate here — this is not a KEV-listed CVE. That does not lower the urgency. Amplification techniques with published research and a memorable name have a historically short fuse before they appear in booter/stresser service catalogs. Treat origin allowlisting (item 1) as a this-week action.
The Bottom Line
CDN Tsunami is a reminder that "we're behind a CDN" is a statement about your attacker's cost model, not your security posture — and this research just made the CDN itself part of the attack surface. The good news: unlike a zero-day in your application stack, the defenses here are architectural, well-understood, and fully within your control. Origin lockdown, authenticated pulls, rate limits, and amplification-ratio monitoring will blunt this technique and a large family of CDN-bypass attacks that haven't been named yet. Do the unglamorous work now.
Related Resources
Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.