ssh-pur66/afterimageRegressioni indipendenti offline ai confini del protocollo per le correzioni pubblicate di urllib3, con release bloccate e attribuzione upstream.
Precedentemente pubblicato come CVE Replay. Il nome del repository e la presentazione sono cambiati; le release bloccate, l'attribuzione del reporter originale, i percorsi dei fixture e i risultati registrati mantengono la loro identità originale.
Studi offline indipendenti confrontano le correzioni pubblicate utilizzando release esatte e fixture delimitate. Ogni studio mantiene espliciti il comportamento misurato, il confine di trasporto e l'attribuzione.
CVE-2026-44431 · urllib3 2.6.3 → 2.7.0 · riprodotto il 27 settembre 2026
Una richiesta trasporta tre header sensibili verso una singola origine. Un redirect cambia la destinazione. La richiesta successiva li trasporta ancora?
Questa regressione indipendente esegue l'implementazione reale del redirect da due release esatte di urllib3. La versione 2.6.3 mantiene tutti e tre gli header attraverso l'API di basso livello interessata. La versione 2.7.0 li rimuove. Un header benigno sopravvive, e le richieste ordinarie continuano a funzionare.
| Fixture | urllib3 2.6.3 | urllib3 2.7.0 |
|---|---|---|
| Redirect cross-origin di basso livello | 3 header sensibili mantenuti | 0 mantenuti |
| Stesso caso con nomi in minuscolo | 3 mantenuti | 0 mantenuti |
| Controllo API di alto livello | 0 mantenuti | 0 mantenuti |
| Risposta 200 diretta | 3 mantenuti come previsto | 3 mantenuti come previsto |
| Redirect esplicitamente disabilitato | Una chiamata; 302 restituito | Una chiamata; 302 restituito |
| Set di rimozione personalizzato aggiunge marcatore benigno | Tutti e 4 gli header mantenuti | Tutti e 4 rimossi |
12/12 aspettative di scenario superate. Ogni scenario verifica anche lo stato della risposta, il numero di chiamate di trasporto, il set di header iniziale, il risultato dell'header benigno e che gli header del chiamante non siano stati mutati. L'esito vulnerabile è un risultato di base atteso, non un controllo di sicurezza superato.
I risultati leggibili da macchina includono gli argomenti catturati, gli hash esatti dei wheel, il runtime, gli hash del codice sorgente dei test, l'attribuzione e il momento della riproduzione.
L'advisory upstream, pubblicato il 7 maggio 2026, identifica un problema di esposizione di informazioni nel percorso di redirect di basso livello con proxy di urllib3. Elenca le versioni >=1.23, <2.7.0 come interessate. La chiamata a ProxyManager.connection_from_url(...).urlopen(..., assert_same_host=False) poteva trasportare header sensibili configurati in una richiesta reindirizzata verso un'altra origine. L'API del manager di alto livello li rimuoveva già.
La correzione upstream applica Retry.remove_headers_on_redirect prima della richiesta ricorsiva di basso livello. Il nostro caso con header in minuscolo segue l'attenzione della regressione upstream al casing dei nomi degli header. Il caso di rimozione personalizzata verifica che la regola rispetti il set configurato, oltre ai soli tre nomi predefiniti.
L'advisory accredita christos-cantina-security come reporter, illia-v come coordinatore e sethmlarson come revisore della remediation. Il contributo di Sergio Rodriguez qui è l'harness offline indipendente e l'analisi before/after. Questa è una riproduzione della loro CVE pubblicata.
Usa Python 3.10 o successivo. Non è necessario pip install o un ambiente virtuale: ogni versione viene importata direttamente dal suo wheel pure-Python in un sottoprocesso isolato nuovo.
Dalla radice del repository del portfolio:
python -B ./labs/cve-replay/run_replay.py --fetch
python -B ./labs/cve-replay/run_replay.py
Il primo comando scarica i due wheel esatti nella directory .cache/wheels/ ignorata dal lab e verifica i loro hash SHA-256 rispetto al manifest. Il secondo comando usa quella cache senza scaricare. Per un checkout del sorgente autonomo, esegui python -B run_replay.py --fetch, poi lo stesso comando senza --fetch. --cache accetta una directory di cache locale diversa.
HTTPConnectionPool._make_request viene sostituito con un trasporto a due risposte: un 302 con una location fissa, poi un 200. Il fixture cattura gli argomenti che raggiungono quel confine. Il parsing di urllib3, la policy di retry, il filtraggio degli header e la gestione ricorsiva dei redirect vengono eseguiti invariati dal wheel selezionato.
Tutte le destinazioni sono nomi .invalid riservati e fissi; tutti i valori degli header iniziano con DUMMY. La costruzione dei socket e le funzioni DNS sollevano immediatamente un'eccezione. La sonda di capacità IPv6 all'import della libreria viene negata e registrata separatamente; gli scenari di replay non tentano alcuna operazione di rete. Non c'è alcun server in ascolto o target live.
Questo valida la gestione degli argomenti del redirect. Non misura il traffico proxy end-to-end. La versione 2.7.0 è la prima correzione per questa particolare CVE; questo confronto storico non è una raccomandazione a sceglierla rispetto a release più recenti supportate.
Gli script dei fixture e l'analisi sono lavoro originale del portfolio. urllib3 è un progetto upstream distribuito sotto la sua licenza MIT; il suo codice e i wheel delle release non sono ridistribuiti nell'archivio sorgente del portfolio. Vengono scaricati separatamente da PyPI e importati invariati per l'esperimento.