async-http-client-check

Offline-Prüfwerkzeug für die 26 sicherheitsrelevanten Advisories auf Repository-Ebene von org.asynchttpclient:async-http-client (AsyncHttpClient, „AHC"). Es zeigt dir, welchen davon dein Jar tatsächlich ausgesetzt ist, markiert diejenigen, die Dependabot und OSV nicht sehen können, und liefert eine Antwort pro Zeile:

• 3.x → 3.0.14
• 2.x → es gibt keine saubere 2.x-Version. Die 2.x-Linie ist End of Life; ihre letzte Veröffentlichung 2.16.1 ist weiterhin von 5 Advisories betroffen, die nicht behoben werden. Die einzige Lösung ist der Wechsel zu 3.0.14.

Ein einziges Jar, keine Laufzeitabhängigkeiten, vollständig offline, Java 17+.

Korrektur (2026-10-12, v0.2.0). v0.1.0 dieses Werkzeugs und der README besagten: „die globale Datenbank listet nur 4 der 17", „Dependabot rät dir, 3.0.12 zu installieren", „die richtige Antwort ist 3.0.13 / 2.16.1". Alle drei Aussagen waren am 2026-09-19 zutreffend und keine davon stimmt mehr: upstream hat am 2026-09-24 fünf weitere Advisories veröffentlicht (behoben in 3.0.14, nicht behoben auf 2.x), und am 2026-10-08 hat die globale GitHub-Datenbank 9 weitere Einträge aufgenommen. v0.1.0 meldet 3.0.13 und 2.16.1 als sauber — das sind sie nicht. Verwende v0.2.0.

---

Warum es dieses Werkzeug gibt

1. Die 2.x-Linie ist End of Life, und ihre letzte Veröffentlichung ist weiterhin betroffen

Am 2026-09-24 haben die Maintainer fünf Advisories veröffentlicht. Jedes davon endet seinen Abschnitt Patches mit demselben Satz:

Die 2.x-Linie ist End of Life und erhält keinen Fix. Aktualisiere auf 3.0.14.

Alle fünf listen einen 2.x-Bereich, der bei 2.16.1 endet — der neuesten 2.x-Veröffentlichung auf Maven Central — mit einer leeren Fixed-Version:

Advisory	Schweregrad	2.x-Bereich	Was	Voraussetzung
CVE-2026-107230	hoch	>= 2.0.0, <= 2.16.1	Gepoolte Verbindungen werden weiterhin über NTLM- / Negotiate- / Proxy-Logins hinweg geteilt (unvollständiger Fix von GHSA-vvp4-63h8-v5pm)	NTLM, Kerberos oder SPNEGO zu einem Origin oder Proxy, oder ein beliebiger Login über einen SOCKS- / CONNECT-Proxy, und Anfragen unter verschiedenen Identitäten über einen Client. Basic und Digest zu einem Origin sind nicht betroffen
CVE-2026-107227	hoch	>= 2.2.0, <= 2.16.1	WebSocket-permessage-deflate-Nachrichten werden ohne Größenlimit entpackt	setEnablewebSocketCompression(true) — standardmäßig aus — und ein nicht vertrauenswürdiger oder unverschlüsselter WebSocket-Server
CVE-2026-107228	mittel	>= 2.1.0, <= 2.16.1	Ein per setHeader / addHeader gesetzter Cookie-Header wird durch die Cookies des Cookie-Stores ersetzt (Umgehung des Fixes von CVE-2024-53990)	Der Cookie-Store, standardmäßig an, der einen beliebigen Cookie für diesen Origin enthält
CVE-2026-107226	mittel	>= 2.1.0, <= 2.16.1	Ein über unverschlüsseltes HTTP empfangener Cookie kann einen über HTTPS gesetzten Secure-Cookie einpflanzen, überschreiben oder löschen	Ein Cookie-Store, der zwischen unverschlüsselten und HTTPS-Origins derselben Site geteilt wird
CVE-2026-107229	mittel	>= 2.16.0, <= 2.16.1	Unvollständige Origin-Prüfungen im Standard-Cookie-Store (privater Abschnitt der Public Suffix List, IP-Hosts, …)	Ein Client, der mehrere Origins erreicht, von denen einer angreiferbeeinflusst ist

Sei präzise bei den beiden hohen: Keines von beiden betrifft einen Client, der einfache Anfragen mit Standardeinstellungen ausführt. CVE-2026-107227 erfordert aktivierte WebSocket-Kompression; CVE-2026-107230 erfordert NTLM / Kerberos / SPNEGO oder einen authentifizierenden Proxy. Die drei mittleren sind diejenigen, die den Standard-Cookie-Store betreffen. Dieses Werkzeug weiß nicht, wie du den Client verwendest; es meldet, was der Versionsbereich aussagt, und überlässt dir die Entscheidung.

Was sich jedoch ändert: „Aktualisiere auf 2.16.1" ist keine Antwort mehr. Eine ältere 2.x-Version wie 2.12.3 kann auf 2.16.1 angehoben werden, um die Advisories zu beseitigen, die einen 2.x-Fix haben — und danach liegt sie weiterhin innerhalb der fünf oben genannten Bereiche (ein Upgrade von unterhalb 2.16.0 fügt sogar CVE-2026-107229 hinzu, dessen Bereich bei 2.16.0 beginnt). Das Werkzeug gibt genau das aus und beendet sich mit 1 für 2.16.1.

2. In der globalen Datenbank fehlen weiterhin 9 der 26

Dependabot und OSV lesen nicht die eigene Seite Security → Advisories des Projekts. Sie lesen die globale Advisory-Datenbank von GitHub. Stand 2026-10-12 liefert GET /advisories/<GHSA> 404 für 9 der 26 Repository-Advisories:

• 8 der 17 am 2026-08-09 veröffentlichten (CVE-2026-107281, CVE-2026-107279, CVE-2026-107232, CVE-2026-107284, CVE-2026-102740, CVE-2026-102737, CVE-2026-85718, CVE-2026-85719) — zwei davon von den Maintainern als hoch eingestuft (CVE-2026-107232, CVE-2026-85719), beide zu Proxy-Anmeldedaten;
• 1 der 5 am 2026-09-24 veröffentlichten (CVE-2026-107229).

Die Datenbank hat aufgeholt — 4 aus dem August-Batch kamen am 2026-09-17 hinzu, 5 weitere am 2026-10-08 — daher wird sich diese Zahl weiter verändern. Jeder Treffer wird mit Dependabot/全局库:已收录 / 未收录 („in / nicht in der globalen Datenbank") ausgegeben, und das Tool gibt das Datum aus, an dem seine Tabelle erzeugt wurde. tools/recheck_before_publish.py sagt Ihnen, ob die Lücke heute noch besteht.

Für 3.x ist die praktische Konsequenz inzwischen gering: Allein aus der globalen Datenbank berechnet, ist das Ziel ebenfalls 3.0.14. Für Versionen <= 3.0.11 werden Ihnen die beiden fehlenden High-Advisories einfach nicht angezeigt.

Ein weiterer Unterschied, den man kennen sollte: CVE-2026-107282 wird von den Maintainern als hoch und in der globalen Datenbank als kritisch eingestuft. Die Regeltabelle behält die Einstufung der Maintainer bei.

3. Die Dekompressionsbombe erfordert keine Konfiguration

CVE-2026-85721 (hoch) ist derjenige, der für Standardeinstellungen gilt: Die automatische Dekomprimierung von Antworten ist standardmäßig aktiviert, und der HTTP/1.1-Pfad entpackt den Body ohne Begrenzung der Gesamtgröße. Ein bösartiger oder kompromittierter Server — oder jeder, der die Antwort auf dem Transportweg verändern kann — kann einen kleinen gzip/deflate-Body senden, der den Heap erschöpft. Betroffen: <= 3.0.11 und <= 2.16.0. Dieser ist in der globalen Datenbank enthalten, sodass Dependabot davor warnt.

Grenzen sind nicht einheitlich geschrieben

Die Bereiche mischen >=, <=, <, ein explizites = 3.0.12 und ein bloßes 3.0.0. Dasselbe 3.0.11 ist sicher für CVE-2026-55688 (< 3.0.11) und betroffen für CVE-2026-107232 (<= 3.0.11). Die Regeltabelle behält jeden Operator exakt wie geschrieben bei; eine Assertion in tools/gen_rules.py und ein Unit-Test schlagen fehl, wenn die Grenze sich nicht mehr so verhält. Jedes Bereichs- Fragment, das der Parser nicht erkennt, ist ein Fehler — niemals „nicht betroffen". Eine leere feste Version wird nur akzeptiert, wenn der Advisory-Text selbst sagt, dass die Linie das Ende ihres Lebenszyklus erreicht hat; sie wird als „kein Fix auf dieser Linie" gespeichert, niemals als „nicht betroffen".

Wenn sowohl das Repository als auch die globale Datenbank ein Advisory enthalten, aber beim Bereich nicht übereinstimmen, nimmt die Regeltabelle die Vereinigung. Aktuell: CVE-2024-53990 (das Repository listet nur die 3.x-Version 3.0.0, die globale Datenbank listet auch 2.x >= 2.1.0, < 2.12.4) und CVE-2026-107230 (gleicher Bereich, auf einer Seite als <= 3.0.13 und auf der anderen als < 3.0.14 geschrieben).

Und es durchsucht pom.xml nicht — absichtlich