CVE Watch20 de out. de 2026

CVE-2026-105298

Summary Before version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filt

CVSS

—

Sem CVSS

EPSS

0.6%

p47

KEV

—

Exploit Today

0-100

Publicado: 20 de out. de 2026 · Última mod.: 20 de out. de 2026 · CWE-444

EPSS · 30d

0.4%EPSS · 30 dias0.6%

2026-10-202026-11-07

Descrição técnica

Summary Before version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs that read the request URI (session.req_header().uri) saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (for example, user@example.com). This violates RFC 9113 Section 8.3.1, which requires an intermediary to use the :authority value for Host and replace any existing Host field. Root cause * HTTP/2 to HTTP/1.1: Host was generated from :authority only when the request had no Host header, so a conflicting client Host was forwarded unchanged. * HTTP/2 to HTTP/2: the client Host header was removed and used to overwrite the upstream :authority, after request filters had already run against the original :authority. * The HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority. Impact A remote, unauthenticated attacker can send a single HTTP/2 request that the application sees as one host and the upstream receives as another. Where request filters, access controls, or cache keys use the URI authority and the upstream routes by Host, this can lead to: * Cache poisoning: a response from another virtual host is stored under the victim host's cache key and served to other users (this also requires the upstream to serve different content per Host). * Host-based access control bypass: a request approved for one host is served by a different virtual host on the upstream. Deployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected. Note that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients. Mitigation: * Upgrade to pingora 0.9.0 or later. Pingora now returns 400 Bad Request for HTTP/2 requests whose Host differs from :authority, that contain more than one Host, or whose authority contains userinfo, and keeps the upstream Host or :authority consistent with the request authority. Fix commits: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76 * If you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains '@'.

Referências oficiais

github.comhttps://github.com/cloudflare/pingora

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-1233184.8 MÉD

3.8%

——1In JetBrains Ktor before 3.6.1 hTTP request smuggling was possible in the CIO engine2d CVE-2026-55458—

43.0%

——13Caddy is an extensible server platform that uses TLS by default. Prior to 2.11.5, the reverse proxy's finalizeResponse method in modules/caddyhttp/reverseproxy/reverseproxy.go handles an upstream 101 Switching Protocols response before running removeConnectionHeaders and the hopHeaders deletion loop used for ordinary responses. The early return invokes handleUpgradeResponse, which copies the upstream headers to the client and normalizes only WebSocket-specific header names. An attacker who controls or compromises a proxied WebSocket upstream can therefore cause hop-by-hop headers such as Alt-Svc, Keep-Alive, and Proxy-Authenticate, as well as headers named by Connection, to cross the proxy boundary. For HTTP/2 or HTTP/3 extended CONNECT, the upstream 101 response may be represented to the client as an ordinary successful response, increasing the chance that leaked headers are processed. This issue is fixed in version 2.11.5.3d CVE-2026-103866—

11.6%

——3Inconsistent interpretation of HTTP requests ('HTTP Request/Response smuggling') vulnerability in Apache Sling Engine. The engine's query/form parser accepts non-standard percent-escapes, wrong charsets, and continues request processing on such errors. This issue affects Apache Sling Engine: before 3.0.4. Users are recommended to upgrade to version 3.0.4, which fixes the issue.2d CVE-2026-1214413.7 BAI

13.1%

——4Wasmtime before 36.0.19, 37.0.0 before 48.0.7, and 49.0.0 before 49.0.4 contains a request smuggling vulnerability in wasi-http that allows guests to set multiple conflicting content-length headers. Malicious guests can make the host send HTTP requests with conflicting content-length values to smuggle requests through servers or intermediaries that do not reject them.5d CVE-2026-1214395.3 MÉD

9.0%

——3Wasmtime 46.0.0 before 48.0.7 and 49.0.0 before 49.0.4 contains a response splitting vulnerability in wasi-http p3 that allows guests to set unvalidated content-length headers. Malicious wasip3 guests can splice an existing body into a new response with an incorrect content-length to perform response splitting or injection attacks.5d CVE-2026-55614—

34.0%

——10uhttpd is a small HTTP server. In unpatched repository snapshots, `client_parse_header()` in `client.c` lowercases header names but compares the `Transfer-Encoding` value to `chunked` using case-sensitive `strcmp`. A mixed-case transfer-coding token is accepted without enabling `r->transfer_chunked`, despite transfer-coding tokens being case-insensitive. On a keep-alive connection, the `chunked` POST body is left unread and request-shaped body bytes are parsed as another HTTP request, permitting HTTP request smuggling and boundary desynchronization. Commits ae015e099986ceace44975cb69629841a2d58d37 and 6641b050e5f7c7fd9ae92e8e119d6d6dfc6e9837 patch the issue.2d