Cloudflare Pingora EUVD-2026-104695

Three concrete conditions must hold simultaneously: (1) the Pingora instance (before 0.9.0) accepts HTTP/2 connections directly from clients; (2) the application makes security or caching decisions from the request URI authority - i.e., request_filter logic, host-based access controls, or cache keys read session.req_header().uri / :authority; and (3) the upstream routes by the Host header and serves different content per Host (explicitly required for the cache-poisoning outcome). The attack needs no authentication (PR:N) and no user interaction (UI:N) and succeeds with a single request. Limiting factors: deployments that do not accept client HTTP/2, or that do not use the request authority for security or caching decisions, are not affected; Cloudflare's internal Pingora services (no HTTP/2 clients) were unaffected.

This is a conditional, moderate-risk request-routing discrepancy rather than a drop-everything priority. The provided CVSS 4.0 vector (6.3, Medium) reports NO impact to the vulnerable Pingora system itself (VC:N/VI:N/VA:N) and only Low confidentiality/integrity impact to subsequent systems (SC:L/SI:L), which correctly models the real harm: other users and other virtual hosts, not the proxy. Crucially the vector sets AT:P (attack requirements present), signaling that successful exploitation depends on specific environmental conditions, not merely sending a packet - consistent with the description's caveat that cache poisoning 'also requires the upstream to serve different content per Host' and that only deployments using the request authority for security/caching are affected. Attack is network-reachable and unauthenticated (AV:N/PR:N/UI:N), which raises exposure, but the preconditions cap real-world likelihood. No EPSS score was provided, so statistical exploitation probability cannot be assessed - this is a gap. There is no CISA KEV listing and no public exploit was identified, so despite a plausible high-impact outcome (cache poisoning affecting many users), there is currently no evidence of weaponization. Net: a legitimate issue to patch for affected architectures, but not a universal emergency; the vendor explicitly notes Cloudflare's own CDN customers were unaffected because internal Pingora services have no HTTP/2 clients.

A remote, unauthenticated attacker sends a single crafted HTTP/2 request in which the :authority pseudo-header names the victim host but the client-supplied Host header names a different virtual host. Pingora's request filters, access controls, and cache key read the :authority while the upstream routes on the forwarded Host, so a response from the attacker-chosen virtual host is cached under the victim's key and later served to other users, or a host-based access control check passes for one host while a different host actually serves the request. No public exploit code was identified at time of analysis.