{"id":163792,"date":"2026-03-10T23:11:57","date_gmt":"2026-03-10T21:11:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy"},"modified":"2026-03-10T23:11:57","modified_gmt":"2026-03-10T21:11:59","slug":"uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy","title":{"rendered":"Vulnerabilit\u00e0 nel progetto Pingora che consentono l'intercettazione di richieste esterne","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
L'azienda Cloudflare ha annunciato di aver risolto tre vulnerabilit\u00e0 nel framework Pingora, di cui due sono state classificate come critiche (9.3 su 10). Il framework Pingora \u00e8 scritto in Rust ed \u00e8 progettato per lo sviluppo di servizi di rete ad alte prestazioni e sicuri. Un proxy costruito con Pingora viene utilizzato nella rete di distribuzione dei contenuti di Cloudflare e gestisce oltre 40 milioni di richieste al secondo. Le vulnerabilit\u00e0 sono state risolte nella versione Pingora 0.8.0. <\/p>\n
Le due vulnerabilit\u00e0 pi\u00f9 pericolose consentono attacchi di tipo \u00abHTTP Request Smuggling\u00bb, permettendo di eludere i sistemi di controllo degli accessi e di infiltrarsi nel contenuto delle richieste di altri utenti, elaborate nella stessa sequenza tra frontend e backend (ad esempio, per iniettare codice JavaScript malevolo nella sessione di un altro utente sul sito). I problemi sono stati identificati da un partecipante al programma Bug Bounty, che prevede un compenso per la scoperta di vulnerabilit\u00e0. <\/p>\n
Nello schema che prevede l'accesso al backend tramite un proxy inverso, le richieste dei clienti vengono ricevute da un nodo aggiuntivo, che stabilisce una connessione TCP di lunga durata con il backend, il quale gestisce direttamente le richieste. Attraverso questa connessione comune vengono generalmente trasmesse le richieste di diversi utenti, che seguono una sequenza una dopo l'altra, separate dai mezzi del protocollo HTTP. Gli attacchi di tipo HTTP Request Smuggling si verificano a causa di diverse interpretazioni degli header HTTP e delle specifiche del protocollo HTTP tra frontend e backend, ad esempio, quando il frontend utilizza l'header HTTP \u00abContent-Length\u00bb per determinare la dimensione della richiesta, mentre il backend utilizza \u00abTransfer-Encoding: chunked\u00bb. <\/p>\n
La prima vulnerabilit\u00e0 CVE-2026-2835 \u00e8 presente nel codice di analisi delle richieste HTTP\/1.0 ed \u00e8 causata da una gestione errata dell'header \u00abTransfer-Encoding\u00bb con valori multipli, nonch\u00e9 dall'uso della chiusura della connessione come indicatore della fine del corpo della richiesta (close-delimited). Pingora controllava solo la versione \u00abTransfer-Encoding: chunked\u00bb e ignorava questo header se conteneva pi\u00f9 valori. In questa situazione, Pingora non considerava la dimensione nell'header \u00abContent-Length\u00bb, ma considerava come corpo della richiesta tutti i dati ricevuti fino alla chiusura della connessione. <\/p>\n
Attraverso l'indicazione di pi\u00f9 valori nell'header \u00abTransfer-Encoding\u00bb, l'attaccante poteva creare le condizioni in cui al backend veniva reindirizzata una richiesta il cui dimensione effettiva non corrispondeva a quella della catena chunked calcolata basata sull'header \u00abTransfer-Encoding\u00bb. Pingora reindirizzava tutti i dati ricevuti come un'unica richiesta, mentre il backend, ad esempio, Node.js, calcolava la richiesta in base a \u00abTransfer-Encoding: chunked\u00bb e trattava il restante tail come l'inizio di un'altra richiesta. GET \/ HTTP\/1.0 Host: example.com Connection: keep-alive Transfer-Encoding: identity, chunked Content-Length: 29 0 GET \/admin HTTP\/1.1 X:
<\/center> <\/p>\n
La seconda vulnerabilit\u00e0 CVE-2026-2833 \u00e8 causata da un'errata gestione dell'intestazione HTTP 'Upgrade' nelle richieste HTTP\/1.1. Quando l'intestazione 'Upgrade' \u00e8 presente nella richiesta, il proxy inoltra immediatamente al backend e i restanti dati della richiesta che seguono l'intestazione 'Upgrade' non aspettano la risposta del backend con codice 101 (Switching Protocols). Questo causa un'interruzione della sincronizzazione del flusso tra il proxy e il backend, e il backend percepisce i dati inviati dopo l'intestazione 'Upgrade' come una richiesta separata, inviando il risultato dell'elaborazione di questa richiesta in risposta alla seguente richiesta di un altro utente. GET \/ HTTP\/1.1 Host: example.com Upgrade: foo GET \/admin HTTP\/1.1 Host: example.com
<\/center>
<\/center> <\/p>\n
I problemi si manifestano quando si utilizza Pingora nella forma di un reverse proxy (ingress proxy), che trasmette le richieste degli utenti ai backend utilizzando i protocolli HTTP\/1.0 o HTTP\/1.1. La configurazione di Pingora nella rete di distribuzione dei contenuti Cloudflare non consentiva di sfruttare le vulnerabilit\u00e0, in quanto Pingora nel CDN non viene utilizzato come ingress proxy, inoltra richieste solo utilizzando il protocollo HTTP\/1.1, blocca le richieste con valori non corretti di Content-Length, inoltra solo un valore dell'intestazione 'Transfer-Encoding: chunked' e aggiunge, nelle richieste con intestazione 'Upgrade:', un'ulteriore intestazione 'Connection: close', che impedisce di inviare ulteriori richieste nella stessa connessione. <\/p>\n
La terza vulnerabilit\u00e0 CVE-2026-2836 (livello di pericolo 8.4 su 10) porta a un avvelenamento della cache (cache poisoning) a causa della generazione della chiave di archiviazione dei dati nella cache (CacheKey) basata solo sul percorso dell'URI, ignorando il contenuto dell'intestazione 'Host'. Questo difetto porta alla formazione di chiavi di caching identiche per percorsi HTTP identici a diversi host. La vulnerabilit\u00e0 pu\u00f2 essere utilizzata per sostituire il contenuto della cache quando si utilizza la modalit\u00e0 caching per pi\u00f9 host. In Pingora, la cache \u00e8 una funzione sperimentale, non raccomandata per implementazioni in produzione. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vulnerabilit\u00e0](\"\/wp-content\/uploads\/2026\/03\/6a4654a05c9ff8c64cc4cb4773bf4ec9.png\")
<\/center> <\/p>\n![\"Vulnerabilit\u00e0](\"\/wp-content\/uploads\/2026\/03\/f86f840431a9be00c4cfd74cc6b4c89b.png\")
<\/center> ![\"Vulnerabilit\u00e0](\"\/wp-content\/uploads\/2026\/03\/8b23d0642fc0b783c2027b91078607e4.png\")
<\/center> <\/p>\n