La vulnerabilità della password proxy tramite client HTTP: CVE in curl, libsoup e requests

La password per il proxy viene solitamente tenuta nascosta: non viene mostrata negli screenshot, non viene committata in git, viene mantenuta nelle variabili d'ambiente. Ma nel 2026 è emerso che a rivelarla può essere lo stesso client HTTP. Tra aprile e luglio sono emerse diverse vulnerabilità in curl, libcurl e libsoup, in cui l'intestazione Proxy-Authorization viene inviata non al proxy corretto, ma direttamente al sito target. Di seguito un'analisi delle condizioni in cui ciò avviene e una verifica passo passo del proprio stack.

Cosa è successo: quattro perdite in quattro mesi

Tutti questi bug sono strutturati allo stesso modo: il client memorizza il login e la password di un proxy e per errore li invia più avanti nella catena.

• CVE-2026-6253 (curl e libcurl 7.14.1–8.19.0). Se per http:// e https:// sono configurati proxy diversi, il primo richiede una password e il secondo no, allora durante il redirect con cambio di schema curl invierà le credenziali del primo proxy al secondo. I dati vengono inviati in base64, cioè praticamente in chiaro. Risolto in curl 8.20.0, rilasciato il 29 aprile 2026. Anche il curl da console è vulnerabile, non solo la libreria.
• CVE-2026-8927 (libcurl 7.12.0–8.20.0). L'applicazione riutilizza un handle per più richieste, i proxy vengono presi dalle variabili d'ambiente e l'autenticazione avviene tramite Digest. In questo caso, l'intestazione Proxy-Authorization per il proxy A viene inviata al proxy B, che può ripeterla per fingersi voi. Risolto in curl 8.21.0 del 24 giugno 2026. Il curl da console non è interessato. Un bug quasi identico è descritto in CVE-2026-7168, con la sola differenza nel modo in cui viene scelto il proxy.
• CVE-2026-12547 (libsoup, SoupAuthManager). libsoup memorizza le credenziali del proxy senza legarle all'indirizzo host:port. Quando le impostazioni del proxy cambiano (parametri di sistema, WPAD), la vecchia intestazione viene inviata al nuovo proxy. Pubblicato il 21 luglio 2026, valutazione bassa.
• CVE-2026-66339 (libsoup, tunnel CONNECT). Dopo l'installazione di un tunnel CONNECT tramite un proxy HTTP, libsoup allega Proxy-Authorization alle successive richieste HTTPS all'interno del tunnel. L'intestazione è già visibile al server target. CVSS 6.5, pubblicato il 24 luglio 2026.

La storia non è nuova. Nella libreria Python requests dalla versione 2.3.0 alla 2.31.0 (CVE-2023-32681) l'intestazione Proxy-Authorization durante il redirect su HTTPS veniva inviata al server target se login e password erano scritti direttamente nell'URL del proxy. In urllib3 fino alla 1.26.19 e 2.2.2 (CVE-2024-37891) l'intestazione impostata manualmente, e non tramite il supporto integrato per il proxy, non veniva rimossa durante il redirect su un dominio esterno.

Perché è importante per il lavoro con i proxy

Con un proxy a pagamento la password equivale a denaro. Chi la ottiene consuma il vostro traffico fino a quando non cambiate l'accesso. Quando si paga per gigabyte, questo è un costo diretto, e con l'accesso condiviso a tutta la squadra ci sono anche le azioni di altri con il vostro IP.

I scenari più vulnerabili si presentano così:

• Parser e monitoraggi, che seguono automaticamente i redirect. Il sito target o un redirect intermedio possono deviare la richiesta su un dominio che raccoglie intestazioni.
• Script con più proxy: proxy diversi per schemi diversi, cambio di proxy tra richieste su una stessa connessione, mescolanza di "proxy con password" e "proxy senza password".
• Processi a lungo termine su server Linux, dove libcurl e libsoup vengono forniti con pacchetti di sistema e aggiornati insieme alla distribuzione, e non con il vostro codice.
• Reti aziendali con WPAD e file PAC: il proxy cambia senza l'intervento dell'applicazione, e proprio questo caso è descritto in CVE-2026-12547.

Come controllare il proprio stack: passo dopo passo

1. Scoprite la reale versione di libcurl, non solo del curl da console. Il comando curl -V mostra entrambe, ma l'applicazione potrebbe essere stata costruita con la propria copia della libreria. Per Python con pycurl eseguite python -c "import pycurl; print(pycurl.version)", per PHP chiamate curl_version(). Limite di sicurezza: 8.21.0 e versioni successive o rami corretti 8.20.1+, 8.16.1+ e 8.14.2+.
2. Controllate le dipendenze di Python. Eseguite pip show requests urllib3. Sono necessarie requests non inferiori a 2.31.0 e urllib3 non inferiori a 1.26.19 (ramo 1.x) o 2.2.2 (ramo 2.x). Se la dipendenza arriva in modo transitivo, controllate pip list all'interno dello stesso ambiente in cui opera il parser.
3. Controllate libsoup su Linux. Questo riguarda le applicazioni GNOME, WebKitGTK e tutto ciò che è costruito su questo stack. Aggiornate il pacchetto tramite il gestore della distribuzione e confrontatevi con il bollettino di sicurezza della vostra distribuzione: nelle schede di queste CVE per Red Hat sono indicati come colpiti RHEL 6–10.
4. Trovate nel codice l'impostazione manuale dell'intestazione. Cercate Proxy-Authorization in tutto il repository. Se l'intestazione è impostata manualmente e non tramite il meccanismo standard del client proxy (proxies= in requests, ProxyManager in urllib3, CURLOPT_PROXYUSERPWD in libcurl), è un candidato per la perdita durante il redirect.
5. Trovate il riutilizzo delle connessioni durante il cambio di proxy. Un handle libcurl, una sessione requests o un agente HTTP, attraverso i quali passano a turno richieste con proxy diversi. La soluzione più semplice: una sessione separata per ogni proxy.
6. Disattivate i redirect automatici dove non sono necessari. In requests è allow_redirects=False, in urllib3 redirect=False, in curl non impostate -L e CURLOPT_FOLLOWLOCATION. In questo modo i 3xx vengono gestiti manualmente e decidete voi dove andare dopo. Questo percorso alternativo è fornito dagli autori di requests e urllib3.
7. Eseguite un test dal vivo per la trappola. Avviate un semplice server HTTP che stampa tutte le intestazioni ricevute e fate un redirect su un secondo server simile. Eseguite il vostro parser con proxy in uno scenario reale, incluso il cambio di schema da http a https. Se uno dei server ha visto Proxy-Authorization, la perdita è confermata nel vostro codice, e non in teoria.

Insidie

• Le immagini Docker vivono una vita propria. Avete aggiornato curl sull'host, ma il parser funziona in un contenitore con una vecchia immagine di base. È necessario controllare all'interno del contenitore: docker exec <contenitore> curl -V.
• Il curl da console e libcurl si aggiornano in modo diverso. CVE-2026-8927 non colpisce il curl da console, mentre CVE-2026-6253 lo colpisce. Un curl -V fresco nel terminale non dice nulla sulla libreria con cui è stato costruito il vostro PHP o Python.
• Digest non salva. Sì, con Digest la password non viene inviata in chiaro. Ma in CVE-2026-8927 l'attaccante non ha bisogno della password: l'intestazione intercettata viene ripetuta finché il nonce è valido.
• La password nell'URL è comoda, ma pericolosa. La perdita in requests si manifestava proprio quando le credenziali erano scritte nell'indirizzo del proxy del tipo user:pass@host:port. Questo non è un motivo per rinunciare al formato, ma un motivo per mantenere le librerie aggiornate.
• Il redirect può arrivare non dalla meta. Le pagine captcha, i banner di consenso, i riduttori di link e i CDN rispondono anch'essi con 3xx. Più "seguimenti di link" ci sono nel crawler, più ampia è la superficie di attacco.

Come limitare i danni se la password dovesse andare persa

Escludere completamente la perdita non è possibile: domani uscirà la prossima CVE. Pertanto, è importante sapere quanto costa una perdita.

• Un progetto, un accesso. Non mantenete un login comune per tutti i parser. In ProxyCove ogni proxy acquistato riceve una coppia di login e password separata, quindi l'accesso perso di uno script non apre il traffico degli altri.
• Non mantenete su un unico accesso più traffico di quanto necessario. Rifornite poco a poco per il compito, e non per sei mesi in anticipo.
• Monitorate il consumo. Un improvviso aumento del traffico senza un aumento del numero di attività è il primo segnale che qualcuno sta usando il vostro accesso.
• Cambiate la password immediatamente in caso di sospetto e secondo un programma. Come organizzare questo senza interruzioni è spiegato nella guida sulla rotazione delle password del proxy.

Quale tipo di proxy scegliere e cosa c'entra

La perdita non dipende dal tipo di proxy: il bug vive nel client. Ma il costo della perdita dipende. I proxy dei data center sono più economici per gigabyte, e per il parsing di siti semplici con frequenti redirect è ragionevole tenerli separati dal traffico costoso. I proxy residenziali dovrebbero essere assegnati a compiti dove sono realmente necessari, e per loro dovrebbero essere creati accessi separati con i redirect automatici disattivati. I proxy mobili, i più costosi per gigabyte, è opportuno mantenerli nel codice con il minimo di dipendenze esterne e con un controllo delle versioni delle librerie ad ogni build.

Conclusione

La password per il proxy può andare persa senza hacking, senza virus e senza errore umano: basta un libcurl obsoleto, un redirect su un dominio esterno e una connessione riutilizzata. La checklist è breve: curl e libcurl dalla 8.21.0, requests dalla 2.31.0, urllib3 dalla 1.26.19 o 2.2.2, libsoup aggiornato, sessione separata per ogni proxy, redirect sotto controllo e un test dal vivo per la trappola. Inoltre, accesso separato per ogni progetto, affinché una perdita costi solo uno script e non tutto il bilancio.