CVE-2026-105298 in Pingora
Riassunto
di VulDB • 20/10/2026
Prima della versione 0.9.0, Pingora accettava richieste HTTP/2 il cui intestazione `Host` differiva dal pseudo-header `:authority`. I filtri delle richieste, le chiavi di cache e i log che leggevano l'URI della richiesta (`session.req_header().uri`) vedevano il valore di `:authority`, mentre l'upstream riceveva il valore `Host` fornito dal client. Pingora accettava inoltre valori di `:authority` contenenti userinfo (ad esempio, [email protected]). Ciò viola la Sezione 8.3.1 della RFC 9113, che richiede a un intermediario di utilizzare il valore `:authority` per l'intestazione Host e di sostituire qualsiasi campo Host esistente.
Causa radice * HTTP/2 verso HTTP/1.1: l'header `Host` veniva generato da `:authority` solo quando la richiesta non disponeva di un header `Host`, quindi un `Host` client conflittuale veniva inoltrato invariato. * HTTP/2 verso HTTP/2: l'intestazione `Host` del client è stata rimossa e utilizzata per sovrascrivere il valore upstream di `:authority`, dopo che i filtri delle richieste erano già stati eseguiti sul valore originale di `:authority`. * Il server HTTP/2 non confrontava `Host` con `:authority` e non rifiutava la presenza di userinfo nell'autorità.
Impatto
Un attaccante remoto, senza necessità di autenticazione, può inviare una singola richiesta HTTP/2 che l'applicazione vede come proveniente da un determinato host, mentre l'upstream la riceve come proveniente da un altro. Dove i filtri delle richieste, i controlli di accesso o le chiavi di cache utilizzano l'autorità dell'URI e l'upstream instrada in base a `Host`, ciò può portare a:
* Avvelenamento della cache (Cache poisoning): una risposta proveniente da un altro host virtuale viene memorizzata con la chiave di cache dell'host vittima e servita ad altri utenti (questo richiede inoltre che l'upstream fornisca contenuti diversi in base all'intestazione `Host`). * Elusione dei controlli di accesso basati sull'host: una richiesta approvata per un determinato host viene servita da un diverso host virtuale presente nell'infrastruttura upstream.
Le distribuzioni che non accettano connessioni HTTP/2 dai client o che non utilizzano l'autorità della richiesta per decisioni relative alla sicurezza o all'inoltro delle richieste (caching) non sono interessate.
Si noti che i clienti del Cloudflare CDN non erano interessati, poiché i servizi Pingora interni a Cloudflare non dispongono di client HTTP/2.
Mitigazione: * Aggiornare a pingora versione 0.9.0 o successiva. Pingora restituisce ora un errore 400 Bad Request per le richieste HTTP/2 il cui `Host` differisce da `:authority`, che contengono più di una intestazione `Host` o la cui autorità contiene userinfo, e mantiene coerente l'host upstream (`Host`) o `:authority` con l'autorità della richiesta. Commit di correzione: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76 * Se non è possibile effettuare l'aggiornamento: nel `request_filter`, rifiutare le richieste HTTP/2 che trasportano un'intestazione `Host` diversa dall'autorità dell'URI o la cui autorità contiene il carattere '@'.
If you want to get best quality of vulnerability data, you may have to visit VulDB.