Apache CXF: Fehlende TLS-Hostnamenprüfung im Netty-HTTP-Client-Transport
Zusammenfassung
Der Netty-basierte HTTP-Client-Transport (cxf-rt-transports-http-netty-client) in Apache CXF prüft nicht, ob der Hostname im TLS-Zertifikat des Servers mit dem aufgerufenen Host übereinstimmt. Dies betrifft sowohl HTTP/1.1 als auch HTTP/2. Auch wenn disableCNCheck auf dem Standardwert false belassen wird, wird die Zertifikatskette zwar gegen den konfigurierten Truststore geprüft, die Identität des Servers jedoch nicht. Ein Angreifer im Netzwerkpfad, der den Datenverkehr abfangen kann, kann ein beliebiges vom Client vertrauenswürdiges Zertifikat vorlegen, etwa ein öffentlich ausgestelltes Zertifikat für eine von ihm kontrollierte Domain, den Zieldienst imitieren und die ausgetauschten Nachrichten, einschliesslich Zugangsdaten, lesen oder verändern.
Betroffen
- Apache CXF 4.2.0 vor 4.2.4
- Apache CXF 4.0.0 vor 4.1.9
- Apache CXF vor 3.6.13
- Nur Anwendungen, die den Netty-basierten HTTP-Client-Transport verwenden, sind betroffen.
Behoben in
- Apache CXF 4.2.4
- Apache CXF 4.1.9
- Apache CXF 3.6.13
- Ältere Zweige (3.5.x und früher) werden von der Community nicht unterstützt, und für sie ist keine verifizierte korrigierte Version bekannt.
Umgehung
- Unbekannt. Es ist kein vom Hersteller dokumentierter Workaround vorhanden.
- Das Setzen von disableCNCheck schützt nicht vor dieser Schwachstelle.
- Bis zur Korrektur sollten betroffene Java-Anwendungen nicht über unsichere Netzwerke betrieben werden.
Ausnutzung
- Eine Ausnutzung in freier Wildbahn ist nicht bekannt.
- Ein öffentlicher Proof of Concept ist nicht bekannt.
- CISA-SSVC-Bewertung: Exploitation none, Automatable yes, Technical Impact total.
- Der CISA-KEV-Katalog sollte erneut geprüft werden, da er nicht direkt abgefragt werden konnte.
Unsere Empfehlung
- Alle Anwendungen ermitteln, die CXF im Classpath enthalten, zum Beispiel mit mvn dependency:tree oder einer SBOM.
- Auf 4.2.4, 4.1.9 oder 3.6.13 je nach Zweig aktualisieren.
- Die Anwendungen neu erstellen und neu ausrollen, da ein reines Aktualisieren des Hosts die verwundbare Kopie unter Umständen bestehen lässt.
- Die laufende Version überprüfen.
- Betroffene Anwendungen bis zur Verteilung des Updates nicht über unsichere Netzwerke betreiben.
Öffentliche Exploits
In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.
Quellen der Recherche
- Apache CXF security advisory thread (Pony Mail) lists.apache.org
- oss-security post CVE-2026-107938 www.openwall.com
- Apache CXF security advisories cxf.apache.org
- Apache CXF advisory text (mail archive) www.mail-archive.com
- Apache CXF commit: Netty client TLS hostname verification mail-archive.com
- Apache CXF Security Advisories (wiki) cwiki.apache.org
- HeroDevs vulnerability directory: CVE-2026-107938 www.herodevs.com
Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 31.10.2026 07:07.
Quellen
Der Tracker verbindet offizielle, frei nutzbare Datenquellen – laufend aktualisiert:
- NVD (NIST) – CVE, Bewertung (CVSS), betroffene Produkte
- CISA KEV – von der CISA bestätigt aktiv ausgenutzte Lücken
- CISA Vulnrichment – Einschätzung der CISA (SSVC) im offiziellen CVE-Eintrag
- FIRST EPSS – Wahrscheinlichkeit einer Ausnutzung
- Microsoft MSRC – Patch Tuesday: Lücken, Schweregrad, Updates
- PoC-in-GitHub – öffentliche Proof-of-Concept-Repositories
- Metasploit (Rapid7) – Module des Metasploit Framework
- Exploit-DB (OffSec) – Archiv öffentlicher Exploits (nur Verweise)
- Patch-Tage: offizielle Seiten der Hersteller (je Hersteller verlinkt) (Patch-Tage der Hersteller)
Dieses Angebot nutzt Daten der NVD-API, ist aber von der NVD weder unterstützt noch zertifiziert. EPSS-Daten © FIRST.org.
Betroffen? Wir helfen.
Wir prüfen, ob Ihre Systeme betroffen sind, spielen Updates ein und schliessen die Lücke – auf Wunsch auch laufend mit dem System Health Checker.