{"id":"2e7f3691-0283-481a-b4b2-e0ec7b001394","arxiv_id":"2607.26589","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"New HBA and HCA attacks exploit HTTP/3-to-HTTP/1.1 conversion at CDNs, with up to 350x bandwidth amplification and 42,330 potentially vulnerable subdomains.","lead":"This paper shows that CDNs that use HTTP/3 with users but HTTP/1.1 with websites can be tricked into turning tiny requests into heavy traffic or long-held connections, knocking websites offline. The authors tested six CDN providers, report all six vulnerable to a bandwidth amplification attack and five to a connection-exhaustion attack, and identify 42,330 potentially exposed subdomains.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Central claim depends on HTTP/3-to-HTTP/1.1 conversion behaviors observed only in a single testbed per vendor; Cloudflare and Fastly already deviate from the claimed behavior, and no evidence shows the other four generalize across edge nodes, account tiers, or time, so the 42,330-domain impact estim","rationale":"The paper's central claim is an empirical generalization from a small, unrepeated observational study. The load-bearing premise is the stability and universality of CDN conversion behavior. The paper itself undercuts the universality by showing Cloudflare and Fastly behave differently, and the measurement methodology lacks error characterization. The 42,330 figure is explicitly 'potentially vulnerable' based on prerequisites rather than attack validation, so it is an upper bound. The proposed test—repeating measurements across accounts, locations, and dates—would either confirm the behaviors are stable (supporting the claim) or reveal variation (requiring a reclassification and downward revision of the estimated impact). This does not change the reader's verdict: the paper is a valuable first study but should be CONDITIONAL on artifact release and additional validation.","tokens_in":16955,"tokens_out":11561,"duration_ms":112069,"concrete_test":"Re-run the HBA and HCA measurements for each of the six CDNs using three fresh accounts per vendor, three geographically distinct client locations, and a fixed nginx (default config, 8k header limit) origin, repeating the connection-timing and amplification experiments on three separate dates. Record whether (a) a backend TCP connection is established on every HEADERS frame (before complete request), (b) a 3,072-byte dynamic-table entry is honored, and (c) origin bandwidth/connection saturation thresholds are reached. If any vendor fails these checks in any repetition, recompute the 42,330 count after excluding that vendor and/or the affected time window. This directly tests whether the observed behaviors are stable enough to support the central claim.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's headline results (all six CDNs vulnerable to HBA, five to HCA; 42,330 potentially vulnerable subdomains) rest on the assumption that the conversion behaviors measured in the authors' testbed — immediate CDN-origin connection on HEADERS, QPACK dynamic-table entries up to 3,072 bytes accepted, no decompressed-request size cap, and POST-based cache bypass — are stable properties of each vendor's entire edge surface. The manuscript itself shows this is not a protocol invariant: Table IV reports Cloudflare buffers the complete request before connecting (kept-open 7.57s vs. ~300s for others), and Fastly limits backend fan-out to the first 10 streams per connection. Thus the 'each stream establishes a separate connection' claim already has two exceptions. The measurements in Figures 6-8 and Tables V-VI have no error bars, repeat counts, or per-edge-node breakdowns, and the large-scale count is inferred from CNAME suffixes plus an HTTP/3 probe, not from testing the conversion behavior on those 42,330 domains. Finally, the paper discloses that Baidu and Tencent deployed mitigations, so the current exposure is time-dependent. If any of the six vendors' behavior varies by PoP or account tier, or has changed since disclosure, the 'five/six vulnerable' and 42,330 figures overstate the attack surface.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper studies DoS attacks that exploit the heterogeneous deployment of HTTP/3 on the client–CDN segment and HTTP/1.1 on the CDN–origin segment. It introduces two attacks: HBA (HTTP/3 Bandwidth Amplification), which abuses QPACK header compression so that compact indexed headers are expanded into large raw HTTP/1.1 headers at the origin; and HCA (HTTP/3 Connection Amplification), which uses slow DATA frames to keep backend connections open and exhaust the origin's connection resources. The authors evaluate both attacks against six CDN vendors, reporting that all six are vulnerable to HBA and five to HCA, with amplification factors up to 66x (static QPACK table) and 350x (dynamic table). They further measure the Tranco Top 1M list and report 151,685 subdomains hosted by vulnerable CDNs, of which 42,330 are 'potentially vulnerable.' The paper also proposes mitigations and describes responsible disclosure, with Baidu and Tencent deploying fixes.","tokens_in":17265,"tokens_out":5503,"duration_ms":54192,"significance":"If the reported results hold, this is a timely and useful contribution: it is the first systematic study of HTTP/3-to-HTTP/1.1 conversion as a DoS amplifier at the CDN layer, building on the earlier HTTP/2-based CDN Judo attack and showing that HTTP/3's QPACK and multiplexing features increase the amplification surface. The attack requires minimal attacker resources (a single connection with small bandwidth) and no special victim-side configuration, which makes the threat model realistic. The paper's strengths include direct measurements against production CDNs, concrete responsible-disclosure outcomes, and practical mitigation principles. However, the paper does not release code or data, and the empirical evidence is thin in terms of repeatability and generality. The impact measurement is an upper-bound estimate based on CNAME suffixes and an HTTP/3 probe, not on validation of the actual conversion behavior on the measured domains. These limitations do not invalidate the core attack idea, but they do prevent the paper's current quantitative claims from being taken at face value.","major_comments":[{"comment":"The vendor-vulnerability claims are based on a single testbed configuration: one attacker VPS in Singapore, one Apache origin in Hong Kong, and one time window. The paper reports no per-PoP variation, account-tier variation, or repeated runs with error statistics for Figures 6 and 7. The manuscript itself shows that behavior is not uniform across vendors: Table IV reports that Cloudflare buffers the complete request before opening the backend connection (kept-open 7.57s vs. ~300s for others), and Fastly limits fan-out to the first 10 streams per connection. Without evidence that the measured behaviors are stable across the vendors' edge surfaces and over time, the headline claims that 'all six' are vulnerable to HBA and 'five' to HCA are not established beyond the tested configuration.","section":"§IV-A, Tables IV–VI, Figures 6–7"},{"comment":"The 42,330 'potentially vulnerable' domains are identified by (i) matching CNAME suffixes from prior work [27] and (ii) an HTTP/3 connection probe. The actual conversion behavior exploited by HBA/HCA — immediate backend connection on HEADERS, QPACK dynamic-table size, absence of a decompressed-request size cap — is not tested on those 42,330 domains. The paper correctly uses the word 'potentially,' but the abstract and RQ2 answer present the number as an identified impact figure. This estimate should be explicitly framed as an upper bound that assumes all edge nodes of the six vendors behave like the single tested node, and the manuscript should discuss how sensitive the estimate is to that assumption.","section":"§III-B, Figure 5"},{"comment":"The amplification-factor analysis lacks statistical support. No error bars, confidence intervals, or per-run values are reported for Figure 8 or Table V, and the only repeated experiment mentioned is RQ3 (10 repetitions), without reporting variance. For central quantitative claims — especially the 350x dynamic-table peak and the claim that the factor is 'independent of the number of streams' for the static table — the paper must provide repeat counts and dispersion measures, or clearly state that these are single-run observations.","section":"§IV-D, Figure 8, Table V"},{"comment":"The paper discloses that Baidu and Tencent have acknowledged the vulnerabilities and deployed mitigations. Nevertheless, the abstract and RQ1 answers report 'all six are vulnerable' / 'five are vulnerable' without caveating that this reflects the state before those mitigations and may no longer describe the current exposure of those two vendors. The claims should be dated and qualified (e.g., 'as of the measurement period') so that readers do not assume the current attack surface is unchanged. This is a load-bearing point because the impact numbers in the paper are intended to quantify real-world risk.","section":"§V-B, §V-D"}],"minor_comments":[{"comment":"Typo: 'thefirststudy' appears as one word in both the abstract and the introduction; it should read 'the first study.'","section":"Abstract and §I"},{"comment":"The y-axis labels and legends are readable, but the figures would benefit from marking the attack start/end times and the victim's capacity limits more explicitly, and from including error bars or shaded confidence regions.","section":"Figures 6–8"},{"comment":"References should include access dates for online resources, especially the Tranco list and vendor documentation, and the paper would benefit from a link to a released artifact (code/data) for reproducibility.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The core attack idea is plausible and timely, and the vendor responses (two bug bounties) lend credibility. My main concern is that the paper's empirical base is too narrow to support the broad 'all six / five' and 42,330-domain claims without additional evidence and more careful caveating. A major revision that adds repeatability data, explicitly bounds the impact estimate, and dates the vulnerability status after disclosure would make the paper suitable for publication."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this paper documents a real and plausibly serious DoS vector — a small HTTP/3 request to a CDN that expands into a large HTTP/1.1 request to the origin — and backs it with a six-vendor evaluation. The broad conclusion holds, but the headline numbers should be read with caution: the measurements are single-testbed and the 42,330 figure is a proxy, not a confirmed vulnerable count.\n\nWhat's new: the QPACK-specific bandwidth amplification (HBA) and the connection-exhaustion variant (HCA) are a natural extension of CDN Judo's HTTP/2-to-HTTP/1.1 attack, but the paper adds the HTTP/3 layer, works through static vs. dynamic table behavior, and measures real CDN limits (stream counts, dynamic table sizes). The six-vendor evaluation is genuinely useful, and the fact that Baidu and Tencent shipped mitigations after disclosure is external evidence the attack is not purely theoretical. The paper is honest about the two exceptions: Cloudflare buffers complete requests and Fastly caps backend fan-out at 10 streams.\n\nSoft spots in proportion. First, there is no released code, data, or repeat counts. Figures 6–8 show single traces with no error bars, and the numbers in Tables IV–VI are averages over 10 repeats — better than nothing, but we don't see variance or per-PoP behavior. Second, the entire evaluation runs from one VPS in Singapore to one Apache server in Hong Kong. That's enough to show the mechanism exists, but not enough to claim 'all six CDNs are vulnerable' as a stable property of each vendor's edge. Third, the 42,330 subdomains are 'potentially vulnerable' in the sense that they sit behind a vulnerable CDN and speak HTTP/3; the paper never tests whether the actual conversion behavior holds for those domains. That's a reasonable measurement boundary, but the abstract's phrasing overshoots. Fourth, two vendors have already patched, so the exposure is time-dependent.\n\nNone of this is fatal. The core insight — CDNs that terminate HTTP/3 and re-origin over HTTP/1.1 are amplifying by default — is sound and worth taking seriously. The paper deserves a serious referee, not a desk reject. The review should ask for artifacts, multi-node repeat measurements, and a clearer separation between confirmed and potential impact.\n\nFor you: if you work on CDN or DoS security, this is worth a read and probably a cite. I'd bring it to a reading group to discuss what counts as 'vulnerable' in a protocol-conversion study.","headline":"A plausible and well-scoped new attack surface — HTTP/3-to-HTTP/1.1 conversion at CDNs — with a real six-vendor evaluation, but the headline numbers are softer than they look because the measurements are single-testbed and the impact estimate is a proxy.","tokens_in":17807,"tokens_out":2949,"would_cite":true,"duration_ms":28687,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Small HTTP/3 requests can be amplified into large HTTP/1.1 floods against CDN-hosted sites, with bandwidth amplification up to 350x.","keywords":["HTTP/3","QUIC","CDN security","denial of service","bandwidth amplification","connection amplification","QPACK","protocol conversion"],"falsifier":"Connect a fresh origin server to any CDN that claims to enforce the paper's mitigations (e.g., a 512-byte dynamic-table entry cap and a 64KB decompressed-request limit), send QPACK-indexed headers with large dynamic entries, and measure the origin bandwidth. If the amplification factor stays near 350x, the root-cause claim is wrong. Separately, for the HCA attack, connect to a CDN that buffers the complete HTTP/3 request before establishing a backend connection; if the origin sees no sustained connection pool exhaustion, the connection-amplification claim is falsified.","tokens_in":16842,"feed_emoji":"🌊","tokens_out":3034,"duration_ms":30817,"temperature":0.7,"pith_summary":"This paper tries to prove that the gap between the protocols a CDN speaks to clients and to websites creates a new denial-of-service weapon. Because CDNs typically accept HTTP/3 from users but forward requests to origin servers over HTTP/1.1, the CDN must decompress QPACK-compressed headers and multiplex many streams into separate backend connections. The authors design two attacks that exploit this conversion: one inflates bandwidth by expanding tiny header indexes into full HTTP/1.1 headers, and the other inflates the number of connections by slowly feeding data through HTTP/3 streams. They report that all six major CDNs they tested are vulnerable to the bandwidth attack, five to the connection attack, and that a scan of the Tranco Top 1M domains identifies 42,330 subdomains as potentially vulnerable. If correct, the work shows that heterogeneous protocol deployment at CDNs is itself an attack surface that requires guardrails during protocol conversion.","feed_headline":"HTTP/3-to-HTTP/1.1 conversion turns small requests into 350x DoS floods","feed_subtitle":"All six tested CDNs amplify bandwidth; five let attackers hold backend connections open. Two vendors already patched.","key_machinery":"The central mechanism is the HTTP/3-to-HTTP/1.1 protocol conversion at the CDN edge, specifically two HTTP/3 features that get lost in translation. QPACK header compression lets clients replace full headers with small dynamic-table indexes; the CDN must expand those indexes into full HTTP/1.1 headers, creating bandwidth amplification. HTTP/3 multiplexing over QUIC lets an attacker open many concurrent streams over one connection, each of which can trigger a separate backend HTTP/1.1 connection if the CDN is eager to establish backend connections, creating connection amplification.","core_discovery":"The paper's central claim is that a CDN's HTTP/3-to-HTTP/1.1 conversion step can be weaponized for amplification. The HTTP/3 Bandwidth Amplification (HBA) attack exploits QPACK header compression: an attacker sends small index references that the CDN must expand into full raw HTTP/1.1 headers, achieving measured amplification factors up to 66x with the static table and 350x with the dynamic table. The HTTP/3 Connection Amplification (HCA) attack exploits the fact that most CDNs open a backend TCP connection immediately upon receiving an HTTP/3 HEADERS frame; by slowly sending DATA frames, the attacker holds many backend connections open, exhausting the origin's connection pool. The paper rep","pith_inferences":["Beyond the paper's claims: the same conversion flaws likely extend beyond CDNs to any HTTP/3-terminating proxy or load balancer that forwards to HTTP/1.1 origins, so the attack surface could be wider than the six vendors tested.","A reader might infer that the 42,330 subdomain figure is a lower bound, since subdomain enumeration is incomplete and HTTP/3 default-on deployments expose victims even when the website owner has taken no action.","An editor's extension: the paper's root-cause analysis suggests a concrete way to assess the HBA mitigation in the wild—measure the amplification factor before and after deploying a 512-byte dynamic-table entry cap; the paper's own numbers suggest this would sharply reduce amplification.","A further inference is that attack detection is hard because the malicious requests are indistinguishable from normal CDN-to-origin traffic; this points to the need for protocol-conversion-level rate limiting rather than traditional volumetric DDoS filters."],"forward_implications":["If the amplification factors hold, an attacker using less than 500 Kbps can saturate a 100 Mbps origin via HBA with dynamic tables.","The attacks require no special victim configuration beyond being hosted behind a CDN with HTTP/3 enabled, which is a default for several major providers.","The connection attack can exhaust an origin's connection pool within seconds using just a few HTTP/3 client connections, amplifying a single attacker into hundreds of backend connections.","The proposed mitigations—capping dynamic-table entry sizes, limiting header-index references, enforcing decompressed-request size limits, and buffering complete requests—directly target the conversion behaviors that enable the attacks.","Two CDN vendors have already acknowledged and patched the vulnerabilities, suggesting the attack is practical enough for vendors to respond."],"fun_headline_variants":["CDN HTTP/3 handoff enables 350x request amplification","HTTP/3-to-1.1 gap yields DoS amplification up to 350x","CDN conversion abuse: small HTTP/3 requests become huge floods","New DoS trick: HTTP/3 headers magnify into 350x traffic","HTTP/3 connection trap: slow data pins CDN backend links"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The central result rests on the assumption that the conversion behaviors observed in the testbed—immediate backend connection on HEADERS, permissive dynamic-table entry sizes up to 3,072 bytes, no decompressed-request size cap, and POST-based cache bypass—are stable across edge nodes and generalizable beyond the six CDN vendors tested.","fun_headline_variants_meta":{"raw":{"variants":["CDN HTTP/3 handoff enables 350x request amplification","HTTP/3-to-1.1 gap yields DoS amplification up to 350x","CDN conversion abuse: small HTTP/3 requests become huge floods","New DoS trick: HTTP/3 headers magnify into 350x traffic","HTTP/3 connection trap: slow data pins CDN backend links"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000625,"raw_usage":{"total_tokens":2790,"prompt_tokens":864,"completion_tokens":1926,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":608,"completion_tokens_details":{"reasoning_tokens":1841}},"tokens_in":608,"tokens_out":1926,"duration_ms":13420,"temperature":1.0,"reasoning_tokens":1841,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T12:43:40.759282+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Connect a fresh origin server to any CDN that claims to enforce the paper's mitigations (e.g., a 512-byte dynamic-table entry cap and a 64KB decompressed-request limit), send QPACK-indexed headers with large dynamic entries, and measure the origin bandwidth. If the amplification factor stays near 350x, the root-cause claim is wrong. Separately, for the HCA attack, connect to a CDN that buffers the complete HTTP/3 request before establishing a backend connection; if the origin sees no sustained connection pool exhaustion, the connection-amplification claim is falsified.","supporting_citations":[],"review_version":1}