ssh-pur66/afterimagePatch-Diff-Analyse für veröffentlichte urllib3-Probleme: gepinnte Releases, originale Offline-Harnesses, Verhalten vor/nach der Änderung und harmlose Kontrollen.
Erstellt und gepflegt von Sergio Rodriguez (SSH-PuR66). Die Experiment-Harnesses und die Analyse stammen von mir; die veröffentlichten Schwachstellen, der urllib3-Code und die Upstream-Fixes behalten ihre ursprüngliche Zuordnung.
Forschungsmethode des Autors · Redirect-Harness · Chunk-Framing-Studie
Ein Redirect ändert das Ziel, während drei sensible Header angehängt bleiben. Ein Framing-Parser akzeptiert Eingaben, die die nächste Version ablehnt. Afterimage verwandelt veröffentlichte Protokoll-Fixes in kleine, nachvollziehbare Vorher/Nachher-Experimente.
Ich habe die Harnesses und Kontrollfälle rund um gepinnte, unveränderte urllib3-Releases gebaut. Jedes Ergebnis erfasst den Paket-Hash, das aufgezeichnete Verhalten, die Fixture-Grenze und die Upstream-Zuordnung.
| Studie | Verglichene Releases | Aufgezeichnetes Korpus | Prüfen |
|---|---|---|---|
| Redirect-Header-Grenze · CVE-2026-44431 | urllib3 2.6.3 / 2.7.0 | 12 Fälle, einschließlich betroffenem Verhalten und harmlosen Kontrollen | Ergebnisse · Harness |
| Chunk-Framing · CVE-2026-97689 | urllib3 2.7.0 / 2.8.0 | 32 begrenzte Offline-Fälle | Methode und Ergebnisse |
Forschungsart: unabhängige Reproduktion veröffentlichter Probleme. Gemessene Grenze: Argumentverarbeitung der Bibliothek und In-Memory-Framing-Verhalten. Anwendungs-Ausnutzbarkeit und Ressourcenerschöpfung bleiben außerhalb dieser Fixture-Ergebnisse.
Die veröffentlichte Studie öffnen
CVE-2026-44431 · urllib3 2.6.3 → 2.7.0 · reproduziert am 27. September 2026
Eine Anfrage trägt drei sensible Header an einen Origin. Ein Redirect ändert das Ziel. Trägt die nächste Anfrage sie noch?
Diese unabhängige Regression führt die echte Redirect-Implementierung aus zwei exakten urllib3-Releases aus. Version 2.6.3 behält alle drei Header über die betroffene Low-Level-API bei. Version 2.7.0 entfernt sie. Ein harmloser Header überlebt, und gewöhnliche Anfragen funktionieren weiterhin.
| Fixture | urllib3 2.6.3 | urllib3 2.7.0 |
|---|---|---|
| Low-Level Cross-Origin-Redirect | 3 sensible Header beibehalten | 0 beibehalten |
| Derselbe Fall mit kleingeschriebenen Namen | 3 beibehalten | 0 beibehalten |
| High-Level-API-Kontrolle | 0 beibehalten | 0 beibehalten |
| Direkte 200-Antwort | 3 wie beabsichtigt beibehalten | 3 wie beabsichtigt beibehalten |
| Redirect explizit deaktiviert | Ein Aufruf; 302 zurückgegeben | Ein Aufruf; 302 zurückgegeben |
| Benutzerdefiniertes Entfernungsset fügt harmlosen Marker hinzu | Alle 4 Header beibehalten | Alle 4 entfernt |
12/12 Szenario-Erwartungen erfüllt. Jedes Szenario prüft außerdem den Antwortstatus, die Anzahl der Transportaufrufe, den anfänglichen Header-Satz, das Ergebnis des harmlosen Headers und dass die Header des Aufrufers nicht verändert wurden. Das verwundbare Ergebnis ist ein erwartetes Baseline-Ergebnis, keine bestandene Sicherheitsprüfung.
Maschinenlesbare Ergebnisse enthalten die erfassten Argumente, exakte Wheel-Hashes, Laufzeit, Testquell-Hashes, Zuordnung und Reproduktionszeit.
Die Upstream-Advisory, veröffentlicht am 7. Mai 2026, identifiziert ein Informationsoffenlegungsproblem im proxied Low-Level-Redirect-Pfad von urllib3. Sie listet die Versionen >=1.23, <2.7.0 als betroffen auf. Der Aufruf von ProxyManager.connection_from_url(...).urlopen(..., assert_same_host=False) konnte konfigurierte sensible Header in eine umgeleitete Anfrage an einen anderen Origin übertragen. Die High-Level-Manager-API entfernte sie bereits.
Der Upstream-Fix wendet Retry.remove_headers_on_redirect vor der rekursiven Low-Level-Anfrage an. Unser Fall mit kleingeschriebenen Headern folgt der Aufmerksamkeit der Upstream-Regression für die Groß-/Kleinschreibung von Header-Namen. Der Fall mit benutzerdefinierter Entfernung prüft, dass die Regel das konfigurierte Set berücksichtigt, über die drei Standardnamen hinaus.
Die Advisory nennt christos-cantina-security als Reporter, illia-v als Koordinator und sethmlarson als Reviewer der Behebung. Sergio Rodriguez' Beitrag hier ist die unabhängige Offline-Testumgebung und die Vorher-/Nachher-Analyse. Dies ist eine Reproduktion ihrer veröffentlichten CVE.
Verwenden Sie Python 3.10 oder neuer. Eine pip-Installation oder virtuelle Umgebung ist nicht erforderlich: Jede Version wird direkt aus ihrem Pure-Python-Wheel in einem frischen isolierten Subprozess importiert.
Vom Stammverzeichnis des Portfolio-Repositories aus:
python -B ./labs/cve-replay/run_replay.py --fetch
python -B ./labs/cve-replay/run_replay.py
Der erste Befehl lädt die beiden exakten Wheels in das ignorierte Verzeichnis .cache/wheels/ des Labs herunter und prüft ihre SHA-256-Hashes gegen das Manifest. Der zweite Befehl verwendet diesen Cache, ohne etwas herunterzuladen. Für einen eigenständigen Source-Checkout führe python -B run_replay.py --fetch aus, dann denselben Befehl ohne --fetch. --cache akzeptiert ein anderes lokales Cache-Verzeichnis.
HTTPConnectionPool._make_request wird durch einen Transport mit zwei Antworten ersetzt: eine 302 mit fester Location, dann eine 200. Das Fixture erfasst die Argumente, die diese Grenze erreichen. Die Parsing-, Retry-Policy-, Header-Filter- und rekursive Redirect-Verarbeitung von urllib3 laufen unverändert aus dem ausgewählten Wheel.
Alle Ziele sind feste reservierte .invalid-Namen; alle Header-Werte beginnen mit DUMMY. Socket-Konstruktion und DNS-Funktionen werfen sofort eine Ausnahme. Die IPv6-Fähigkeitsprüfung der Bibliothek zur Importzeit wird verweigert und separat aufgezeichnet; die Replay-Szenarien versuchen keine Netzwerkoperationen. Es gibt keinen lauschenden Server und kein Live-Ziel.
Dies validiert die Behandlung von Redirect-Argumenten. Es misst keinen End-to-End-Proxy-Traffic. Version 2.7.0 ist der erste Fix für diese spezielle CVE; dieser historische Vergleich ist keine Empfehlung, sie neueren unterstützten Releases vorzuziehen.
Die Fixture-Skripte und die Analyse sind eigenständige Portfolio-Arbeit. urllib3 ist ein Upstream-Projekt, das unter seiner MIT-Lizenz vertrieben wird; sein Code und seine Release-Wheels werden im Portfolio-Quellarchiv nicht weiterverbreitet. Sie werden separat von PyPI heruntergeladen und für das Experiment unverändert importiert.