When Cache Identity and Backend Identity Split

H3Act's cache-poisoning and request-smuggling findings expose a different translation failure from upstream amplification. The focus here is whether the CDN's cache, router, translator, and origin agree on the identity and boundaries of one HTTP/3 request. Readers will be able to separate a measured field conflict from a cache consequence, then connect strict HTTP/3 validation to preventing a downstream HTTP/1.1 parser from seeing a different message.

The central risk is not that a request contains an unusual value. Modern intermediaries have to normalize, route, cache, and serialize values constantly. The risk appears when two components use different values—or different interpretations of the same value—to make decisions that should agree. A cache may name one origin while a router sends the request to another. An edge may regard a field as data while an HTTP/1.1 parser regards it as a delimiter. In each case, the request's meaning splits at a boundary.

Two authorities in one request

A cache stores a response under a key. A router selects a backend. Those operations are separate, but they should be driven by the same effective request identity. For ordinary HTTP(S) traffic, the authority identifies the target origin. In HTTP/3, that authority is carried by :authority; when an intermediary converts the request to HTTP/1.1, it must create a corresponding Host field when needed. If the cache and router do not agree about that value, the edge can fetch one representation and label it as another.

H3Act reports a concrete form of this problem involving an absolute URI in :path. In the tested behavior, the absolute URI conflicted with the value in :authority. The translated HTTP/1.1 request used the host information from the path, while the cache key could be derived from the authority. That creates two identities for one request: one influences where the origin request goes, and another influences where the response is stored. If the response comes from an attacker-controlled origin and is stored under a victim-domain key, later clients can receive the wrong representation.

The causal chain has several necessary links. First, the edge must accept or interpret the conflicting request rather than reject it. Second, translation must give the path or another value influence over the forwarded host. Third, cache-key generation must use a different identity from routing or origin selection. Finally, the cache must serve the stored response to later requests under the affected key. A conflict in two fields is therefore a warning sign, not by itself proof of poisoning. The impact depends on the exact cache and routing arrangement.

Duplicate host information creates a similar split without an absolute URI. The paper reports that Tencent CDN and Tencent EdgeOne accepted multiple Host fields, multiple :authority values, or combinations of both in the tested HTTP/3 path. Their routing behavior followed a “last one wins” pattern. If cache-key generation uses the first value while routing uses the last, the cache and backend are no longer answering the same question. One component is deciding which name labels the response; another is deciding which origin creates it.

The phrase “last one wins” describes an implementation behavior, not a safe protocol rule.