CVE-2026-24734, Umgehung des Apache Tomcat OCSP-Sperrvermerks

CVE-2026-24734 ist nicht die Art von Tomcat-Schwachstelle, die für dramatische Schlagzeilen sorgt. Sie verschafft einem nicht authentifizierten Angreifer keine Remotecodeausführung. Sie verwandelt eine fehlerhafte HTTP-Anfrage nicht in eine Speicherbeschädigung. Stattdessen wird eine ruhigere, grundlegendere Sicherheitsgarantie getroffen: ob ein Server, der sich auf Client-Zertifikate verlässt, seinen eigenen Widerrufsprüfungen noch vertrauen kann. Im Apache-Bericht heißt es, dass Tomcat Native und der OpenSSL FFM-Pfad von Tomcat bei der Verwendung eines OCSP-Responders keine Verifizierungs- oder Aktualitätsprüfungen für die OCSP-Antwort durchgeführt haben. Das Ergebnis ist simpel und in der richtigen Umgebung gefährlich: Zertifikatsperrungen können umgangen werden. Apache stufte das Problem als moderat ein, während NVD und die Advisory-Datenbank von GitHub einen hohen CVSS 3.x-Schweregrad zuweisen. (Google Gruppen)

Diese Unterscheidung ist wichtig, weil das tatsächliche Risiko leicht zu verkennen ist. Es handelt sich nicht um ein allgemeines "alle Tomcat-HTTPS sind kaputt"-Problem. Die Tomcat-eigene OCSP-Dokumentation bindet die OCSP-Prüfung an Client-Zertifikate und an eine Teilmenge von OpenSSL-gestützten Verbindungskonfigurationen. In dem dokumentierten Modell validiert Tomcat vom Client bereitgestellte Zertifikate mit einer OCSP-Responder-URI in der Authority Information Access-Erweiterung, und diese Funktion ist für den OpenSSL-JSSE-Pfad, den OpenSSL-FFM-Pfad und den APR/nativen Connector implementiert und nicht für die einfache JSSE-Implementierung, die an anderer Stelle in derselben Dokumentation beschrieben wird. In der Praxis sind die risikoreichsten Implementierungen diejenigen, die mTLS als Zugangskontrollgrenze für B2B-APIs, interne Verwaltungsebenen, Partnerintegrationen, Geräteidentitäten oder privilegierte Dienst-zu-Dienst-Authentifizierung verwenden. (Apache Tomcat)

Auch die von Apache selbst veröffentlichten Informationen sind bemerkenswert. Das Problem wurde dem Tomcat-Sicherheitsteam am 2. November 2025 gemeldet. Behobene Versionen wurden im Januar 2026 für Tomcat Native und Tomcat 9, 10.1 und 11.0 ausgeliefert, und der öffentliche Hinweis folgte am 17. Februar 2026. Dieses Timing ist normal für eine koordinierte Offenlegung. Der wichtigere technische Aspekt ist, dass sich die OCSP-Behandlung in diesem Codebereich auch nach der ersten Behebung weiterentwickelt hat. Im März 2026 veröffentlichte Apache CVE-2026-29145, ein weiteres OCSP-bezogenes Problem, bei dem die Authentifizierung von Client-Zertifikaten manchmal auch dann fehlschlug, wenn Soft Fail deaktiviert war. Die Lektion lautet nicht einfach: "Nimm die minimal gepatchte Version und mach weiter". Es geht darum, dass die Pfade zur Durchsetzung des Widerrufsrechts erneut getestet werden müssen und nicht einfach nur angekreuzt werden dürfen. (Apache Tomcat)

CVE-2026-24734 auf einen Blick

Apache und NVD bezeichnen die betroffenen Bereiche wie folgt. Für Tomcat Native sind die Versionen 1.3.0 bis 1.3.4 und 2.0.0 bis 2.0.11 betroffen, mit Korrekturen in 1.3.5 und 2.0.12. Bei Apache Tomcat sind die Züge 11.0.0-M1 bis 11.0.17, 10.1.0-M7 bis 10.1.51 und 9.0.83 bis 9.0.114 betroffen, mit Korrekturen in 11.0.18, 10.1.52 und 9.0.115. NVD weist auch darauf hin, dass ältere Tomcat Native-Versionen, insbesondere 1.1.23 bis 1.1.34 und 1.2.0 bis 1.2.39, ebenfalls betroffen sind. Die Advisory-Datenbank von GitHub ordnet das Problem zusätzlich in eingebettete Java-Paketbereiche ein, darunter org.apache.tomcat.embed:tomcat-embed-core und org.apache.tomcat:tomcat-coyoteDies ist eine nützliche Erinnerung daran, dass nicht jeder anfällige Einsatz wie ein eigenständiger Tomcat-Server auf einer VM aussieht. (nvd.nist.gov)

Komponente	Betroffene Versionen	Festgelegte Versionen	Operativer Hinweis
Tomcat Nativ 1.3.x	1.3.0 bis 1.3.4	1.3.5 oder höher	OCSP-Pfad im APR/nativen Anschluss
Tomcat Nativ 2.0.x	2.0.0 bis 2.0.11	2.0.12 oder höher	OpenSSL-unterstützter nativer Pfad
Tomcat 11	11.0.0-M1 bis 11.0.17	11.0.18 oder höher	FFM OpenSSL-Pfad betroffen
Tomcat 10.1	10.1.0-M7 bis 10.1.51	10.1.52 oder höher	FFM OpenSSL-Pfad betroffen
Tomcat 9	9.0.83 bis 9.0.114	9.0.115 oder höher	FFM OpenSSL-Pfad betroffen
EOL Native Linien	1.1.23 bis 1.1.34, 1.2.0 bis 1.2.39	Keine unterstützte in-place Zukunft	Migration ist sicherer als sich an tote Äste zu klammern

Die Geschichte mit dem Schweregrad ist auf eine lehrreiche Art und Weise etwas unübersichtlich. Der Apache-Bericht bezeichnet das Problem als moderat. NVD listet einen 7.5 High-Vektor von NVD Enrichment und einen separaten 7.4 High-Vektor von CISA-ADP. Snyk stuft eng verwandte Paketdatensätze im Stil von CWE-863 ein und beschreibt die Auswirkung als falsche Autorisierung, während Apache und NVD die Schwachstelle mit unvollständiger Validierung und OCSP-Antwortbehandlung umschreiben. Diese Unterschiede sind weniger ein Widerspruch als ein Perspektivenwechsel. Auf der Code-Ebene betrifft der Fehler die unvollständige Validierung von Antworten. Auf der Systemebene besteht die Auswirkung darin, dass ein widerrufener Berechtigungsnachweis immer noch akzeptiert werden kann und daher immer noch den Zugriff erlaubt. (Google Gruppen)

Apache Tomcat OCSP-Widerrufsumgehung erklärt

Um zu verstehen, warum CVE-2026-24734 von Bedeutung ist, ist es hilfreich, genau zu wissen, was Tomcat tut, wenn OCSP aktiviert ist. In der SSL/TLS-Dokumentation von Tomcat heißt es, dass die OCSP-Unterstützung dazu dient, den Status der vom Client bereitgestellten Zertifikate zu überprüfen. Sie listet die unterstützten Connector-Familien für diese Funktion auf: NIO oder NIO2 mit org.apache.tomcat.util.net.openssl.OpenSSLImplementierung, NIO oder NIO2 mit org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementierungund der APR/native HTTP-Konnektor mit einem OCSP-fähigen Tomcat Native Build. In derselben Dokumentation heißt es, dass OCSP nicht unterstützt wird, wenn die einfache JSSE-Implementierung oder der JSSE-Konfigurationsstil verwendet wird. Diese Bereichsdefinition ist kritisch. Sie bedeutet, dass die Schwachstelle in einem bestimmten Vertrauenspfad liegt: Server-seitige Validierung von Client-Zertifikaten in OpenSSL-gestützten Tomcat-Konfigurationen. (Apache Tomcat)

Bei einem typischen mTLS-Einsatz legt der Client während des TLS-Handshakes ein Zertifikat vor. Der Server muss nicht nur wissen, ob das Zertifikat auf einen vertrauenswürdigen Aussteller ausgestellt ist. Er muss auch wissen, ob das Zertifikat seit seiner Ausstellung widerrufen wurde. OCSP ist eine der Standardmethoden, um diese Frage nahezu in Echtzeit zu beantworten. Wenn ein Gerätezertifikat widerrufen wird, weil das Gerät außer Betrieb genommen wurde, wenn ein Partnerzertifikat widerrufen wird, weil eine Beziehung beendet wurde, oder wenn der Verdacht besteht, dass ein privater Client-Schlüssel kompromittiert wurde, sollte der vertrauende Dienst dieses Client-Zertifikat zurückweisen. Wenn die Widerrufsprüfung umgangen werden kann, wird das auf diesem Zertifikat aufbauende Zugangskontrollmodell unglaubwürdig. (Apache Tomcat)

Aus diesem Grund sind die Auswirkungen in bestimmten Umgebungen stärker als in anderen. Eine öffentliche Website, die Tomcat für gewöhnliches TLS verwendet, aber keine Client-Zertifikate benötigt, ist nicht das klassische Opfer. Eine Partner-API, die nur Inhaber genehmigter Client-Zertifikate zulässt, schon. Das Gleiche gilt für eine interne Betriebsebene, bei der Maschinenidentitäten über mTLS durchgesetzt werden, ein industrielles System, das Geräte über Zertifikate einbindet, oder ein Gateway, bei dem der Besitz von Zertifikaten als primärer Nachweis der Organisationszugehörigkeit gilt. In all diesen Entwürfen ist der Widerruf keine kosmetische Funktion. Es ist der Kill Switch für Identitäten, denen nicht mehr vertraut werden sollte. Sobald dieser Schalter umgangen werden kann, verschlechtern sich die Eindämmung von Vorfällen, das Offboarding und die Reaktion auf Schlüsselkompromittierungen. (Apache Tomcat)

Es gibt auch einen einfachen konzeptionellen Fehler, der zu vermeiden ist. Das Wort "Zertifikat" lässt viele Leser an Browser denken, die Serverzertifikate validieren. Das ist hier aber nicht der Schwerpunkt. Die OCSP-Funktionsdokumentation von Tomcat weist ausdrücklich darauf hin, dass der Mechanismus die vom Client bereitgestellten Zertifikate validiert. Das bedeutet, dass es bei der Schwachstelle darum geht, wer eindringen kann, und nicht darum, welches Serverzertifikat ein Browser akzeptiert. Anders ausgedrückt: CVE-2026-24734 ist ein Fehler in der Authentifizierungs- und Autorisierungsgrenze in mTLS-aktivierten Serverimplementierungen, nicht ein allgemeiner Bruch der HTTPS-Vertraulichkeit für beliebige Besucher. (Apache Tomcat)

Warum die OCSP-Validierung leicht falsch sein kann

OCSP sieht einfach aus, wenn man es auf eine Statuskennzeichnung reduziert. Fragen Sie, ob ein Zertifikat gut, widerrufen oder unbekannt ist. Lesen Sie die Antwort. Fahren Sie fort. Dieses mentale Modell ist unvollständig genug, um gefährlich zu sein. RFC 6960 definiert OCSP als ein Protokoll zur Bestimmung des aktuellen Status eines digitalen Zertifikats, ohne dass vollständige CRLs erforderlich sind. Der gleiche RFC beschreibt die Semantik von thisUpdate, nextUpdate, produziertAufund revocationTime. Es wird auch darauf hingewiesen, dass die Nonce-Erweiterung eine Anfrage und eine Antwort kryptografisch verbindet, um Wiederholungsangriffe zu verhindern. Diese Details sind keine optionale Beigabe. Sie sind Teil dessen, was eine OCSP-Antwort vertrauenswürdig und nicht nur wohlgeformt macht. (datatracker.ietf.org)

RFC 6960 sagt thisUpdate ist der letzte Zeitpunkt, zu dem der Responder weiß, dass der angegebene Status korrekt war, und nextUpdate ist der Zeitpunkt, zu dem oder vor dem neuere Informationen verfügbar sein werden. Sie fügt eine subtile, aber wichtige Regel hinzu: Antworten, deren nextUpdate vor der Ortszeit liegt, sollte als unzuverlässig angesehen werden, und Antworten, deren thisUpdate später als die Ortszeit ist, sollte ebenfalls als unzuverlässig angesehen werden. Der RFC stellt außerdem fest, dass, wenn nextUpdate nicht gesetzt ist, sagt der Antwortende damit, dass jederzeit neuere Widerrufsinformationen verfügbar sein können. Das bedeutet, dass eine Implementierung die OCSP-Behandlung nicht sicher auf "das Statusfeld sagt gut, also bin ich fertig" reduzieren kann. Die Zeitsemantik ist Teil der Vertrauensentscheidung. (datatracker.ietf.org)

OpenSSL's eigene Dokumentation macht den gleichen Punkt in Begriffen der Bibliothek und nicht in Begriffen des Protokolls. Die OCSP_check_validity() Laut Dokumentation prüft die Funktion thisupd und nextupdermöglicht einen konfigurierbaren Spielraum für Taktverzögerungen und kann das maximale Alter einer Antwort begrenzen. Die OpenSSL-Manpage erklärt auch, dass Anwendungen typischerweise den Zertifikatsstatus abrufen und dann dessen Gültigkeit überprüfen, und warnt ausdrücklich, dass, wenn nextUpdate nicht vorhanden ist, könnte eine uralte Antwort andernfalls als gültig erscheinen, es sei denn, es werden maximale Altersgrenzen durchgesetzt. OpenSSL dokumentiert auch OCSP_basic_verify() als der Mechanismus, der prüft, ob die Basisantwort korrekt signiert ist und ob das Zertifikat des Unterzeichners validiert werden kann. Auch hier ist das Muster klar: eine vertrauenswürdige OCSP-Antwort erfordert mindestens die Statusabfrage, die Signaturprüfung, die Validierung des Unterzeichners und die Aktualitätslogik. (docs.openssl.org)

Nonce ist aus einem anderen Grund wichtig. RFC 6960 besagt, dass die Nonce Anfrage und Antwort verbindet, um Wiederholungen zu verhindern. Ohne diese Bindung kann eine Antwort, die technisch analysierbar ist, dennoch die falsche Antwort für die aktuelle Transaktion sein. In Umgebungen, in denen sich der Sperrstatus schnell ändert oder in denen Angreifer zuvor beobachtetes Material erneut abspielen können, ist dies kein theoretisches Problem. Freshness ohne Request-Response-Bindung ist schwächer als viele Teams annehmen. Die Überprüfung von Signaturen ohne Freshness ist ebenfalls schwächer, als die Teams annehmen. Alle drei Eigenschaften müssen übereinstimmen. (datatracker.ietf.org)

Diese breitere Sichtweise erklärt, warum CVE-2026-24734 nicht "nur ein OCSP-Edge-Fall" ist. Es ist ein konkretes Beispiel für eine wiederkehrende Implementierungsfalle in Identitätssystemen. Ingenieure achten oft auf die Kettenvalidierung und das grundlegende Parsen von Zertifikaten und behandeln dann den Widerruf als zusätzlichen Schritt. In Wirklichkeit ist der Widerruf ein Teil der Identitätsentscheidung selbst. Ein Zertifikat, das korrekt verkettet, aber widerrufen wird, ist kein geringerer Erfolg. Es ist ein Fehlschlag. Jede Implementierungslücke, die ein solches Zertifikat akzeptiert, untergräbt die Bedeutung der gesamten mTLS-Richtlinie, die es umgibt. (Apache Tomcat)

Was Apache mit dem Patch geändert hat

Der schnellste Weg, CVE-2026-24734 zu verstehen, ist ein Blick auf den Fix. Apache's Tomcat Commit e76e9ea trägt den Titel "OCSP-Prüfungen für OpenSSL erweitern, um mit JSSE übereinzustimmen". Dieser Commit ist aufschlussreicher als der kurze Advisory-Text, da er genau zeigt, welche Checks im OpenSSL FFM-Pfad fehlten und welche hinzugefügt wurden. Die Änderungen sind nicht kosmetisch. Sie fügen Anfrage-Antwort-Nonce-Validierung, Antwort-Signatur und Signierer-Verifizierung, explizite Gültigkeitsüberprüfungen über thisUpdate und nextUpdate, konfigurierbare OCSP-Timeout-Behandlung und konfigurierbare OpenSSL-Verifizierungsflags. (GitHub)

Eine der wichtigsten Ergänzungen ist OCSP_check_nonce(ocspRequest, basicResponse). Der Patch behandelt eine Nonce-Fehlanpassung als ungültige OCSP-Antwort und gibt einen unbekannten Status mit einem im Verifizierungskontext gesetzten Fehler zurück. Das ist wichtig, weil RFC 6960 nonce als Anti-Replay-Bindung zwischen Anfrage und Antwort definiert. Wenn die Implementierung zuvor bereit war, eine Antwort zu akzeptieren, ohne diese Bindung zu überprüfen, dann hat sie nicht vollständig sichergestellt, dass die Antwort tatsächlich zu der laufenden Anfrage gehört. (GitHub)

Der Patch fügt außerdem Folgendes hinzu OCSP_basic_verify(basicResponse, certStack, X509_STORE_CTX_get0_store(x509ctx), state.ocspVerifyFlags). OpenSSL-Dokumente OCSP_basic_verify() wie die Überprüfung, dass die Antwort korrekt signiert ist und dass das Zertifikat des Unterzeichners unter Verwendung des vertrauenswürdigen Speichers und aller bereitgestellten Zwischenprodukte validiert werden kann. Das ist eine erhebliche Verbesserung der Sicherheit im Vergleich zur einfachen Extraktion eines Statusfeldes. A gut Status von einem nicht vertrauenswürdigen oder nicht korrekt validierten Responder ist keine akzeptable Grundlage, um ein widerrufenes Client-Zertifikat durch den TLS-Handshake zu lassen. Die Fehlerbehandlung des Patches spiegelt diese Logik wider, indem eine fehlgeschlagene Basisverifizierung auf X509_V_ERR_OCSP_SIGNATURE_FAILURE. (GitHub)

Genauso wichtig sind die Aktualitätsprüfungen. Der alte Codepfad, wie er sich im Diff widerspiegelt, holte zuvor die einzelne Antwort ein und gab dann den Status zurück, ohne den umfassenderen Zeitvalidierungsfluss, der jetzt im Patch sichtbar ist. Der korrigierte Code extrahiert thisUpdate und nextUpdateund ruft dann OCSP_check_validity() zweimal: einmal, um noch nicht gültige Antworten zu erkennen, und einmal, um abgelaufene Antworten zu erkennen, mit ausdrücklicher Zuordnung zu X509_V_ERR_OCSP_NOT_YET_VALID und X509_V_ERR_OCSP_HAS_EXPIRED. In der Dokumentation von OpenSSL heißt es OCSP_check_validity() ist die Funktion, die für die Auswertung dieser Zeitstempel und für die Begrenzung des Antwortalters verantwortlich ist. Das bedeutet, dass der Patch nicht nur die Hygiene verbessert. Er repariert die Vertrauenssemantik, die darüber entscheidet, ob man sich auf eine OCSP-Antwort überhaupt noch verlassen kann. (GitHub)

Auch die Ergänzungen auf der Konfigurationsseite sind sinnvoll. Der Commit führt die Unterstützung für OCSP_TIMEOUT und OCSP_VERIFY_FLAGS im OpenSSL FFM-Codepfad, und die Konfigurationsreferenz von Tomcat dokumentiert nun ocspVerify als das Attribut, das die Überprüfungskennzeichen an OCSP_basic_verify für OpenSSL-basierte TLS-Implementierungen. Sie dokumentiert außerdem ocspSoftFailmit einem Standardwert von falschDas bedeutet, dass bei einer fehlgeschlagenen OCSP-Prüfung der TLS-Handshake fehlschlagen sollte, es sei denn, Soft Fail ist ausdrücklich aktiviert. Diese Knöpfe existieren nicht in einem Vakuum. Sie zeigen, dass Apache die Korrektur nicht als eine einzeilige Fehlerbehebung behandelte, sondern als Teil einer breiteren Anstrengung, die OCSP-Behandlung explizit, konfigurierbar und besser auf das beabsichtigte Sicherheitsmodell abgestimmt zu machen. (GitHub)

Die Tomcat Native Seite erzählt eine parallele Geschichte. Native 2.0.12 und 1.3.5 wurden im Januar 2026 veröffentlicht. In den Versionshinweisen heißt es, dass die Überprüfung von OCSP-Antworten erweitert und Optionen zur Konfiguration des OCSP-Verhaltens hinzugefügt wurden. Im Februar und März 2026 wurde dann die Härtung von Native fortgesetzt, einschließlich einer Änderung zur Beseitigung eines zusätzlichen Fehlers in der OCSP-Verarbeitung, so dass sich Soft Fail korrekt mit dem APR/Native Connector verhielt. Diese spätere Arbeit wurde zu CVE-2026-29145. Diese Abfolge ist von Bedeutung, da sie zeigt, dass der Codebereich nicht nur einmal gepatcht wurde, sondern dass er aktiv in Richtung eines strengeren und kohärenteren OCSP-Modells korrigiert wurde. (Apache Tomcat)

Wenn CVE-2026-24734 ein echter Angriffspfad wird

Die sauberste Art, über eine Ausnutzung nachzudenken, ist nicht: "Kann ich einen Exploit-String auf Tomcat abfeuern?", sondern: "Kann ich eine Client-Identität vorlegen, die eigentlich nicht mehr gültig sein sollte und trotzdem akzeptiert wird?" In den Umgebungen, in denen dieses CVE von Bedeutung ist, ist der Vermögenswert des Angreifers oft ein Client-Zertifikat und der dazugehörige private Schlüssel, der einmal gültig war, dem aber nicht mehr vertraut werden sollte. Dies kann der Fall sein, wenn ein Mitarbeiter das Unternehmen verlässt, ein Auftragnehmer den Zugang verliert, ein Gerät ausgemustert wird, eine Partnerbeziehung endet oder ein Schlüssel bei einem anderen Vorfall offengelegt wird. In einem gesunden System wird diese Tür durch den Widerruf geschlossen. In einem anfälligen System ist der Server möglicherweise immer noch bereit, sie zu öffnen. (Google Gruppen)

Ein realistisches Beispiel ist eine Partner-API, die durch gegenseitiges TLS geschützt ist. Das Zertifikat des Partners wird nach einer Kompromittierung oder Vertragskündigung widerrufen. Der Partner oder jeder, der jetzt im Besitz des alten privaten Schlüssels ist, sollte sofort den Zugang verlieren. Wenn der Tomcat-Rand, der diese Identitätsentscheidung erzwingt, im betroffenen Bereich liegt und sich auf den anfälligen OCSP-Pfad stützt, kann die Entscheidung über den Widerruf des Zertifikats fehlschlagen. Der Zugriff wird nicht mehr durch den aktuellen Vertrauensstatus der Zertifizierungsstelle kontrolliert, sondern durch die unvollständige Interpretation der OCSP-Antworten durch den Server. Aus diesem Grund beschreiben einige Ökosysteme das Problem mit Begriffen der Autorisierung und nicht nur mit Begriffen der Eingabevalidierung. Der Fehler befindet sich in der Validierungslogik, aber das operative Ergebnis ist eine Vertrauensentscheidung, die fehlschlagen sollte, es aber nicht tut. (nvd.nist.gov)

Das gleiche Muster gilt für interne Dienstnetze und Maschine-zu-Maschine-Plattformen, die mTLS weniger als Transportfunktion und mehr als Mitgliedschaftstest verwenden. Viele Teams gehen davon aus, dass die Bedrohung geringer ist, weil es sich bei den Zertifikaten um private PKI-Artefakte handelt und die Endpunkte intern sind. Das Gegenteil kann der Fall sein. Internes mTLS schließt oft Verwaltungsfunktionen, Orchestrierungssysteme, sensible Datenpfade oder Engpässe für seitliche Bewegungen ein. Wenn ein widerrufener Client-Berechtigungsnachweis immer noch authentifiziert, ist das genau die Art von Lücke, die ein Angreifer mit teilweisem Fußabdruck, veraltetem Gerätematerial oder durchgesickerten Schlüsseln finden möchte. Die Tatsache, dass der Netzwerkstandort "intern" ist, schützt ein System nicht vor einer schlechten Vertrauenssemantik. (Apache Tomcat)

Was dieses CVE natürlich nicht beschreibt, ist die anonyme Fernkompromittierung gewöhnlicher öffentlicher Tomcat-Sites, die keine OCSP-Prüfungen für Client-Zertifikate verwenden. Deshalb sind pauschale Schlagzeilen wie "Tomcat-Server über das Netzwerk verwundbar" hier nicht hilfreich. Der Netzwerk-Angriffsvektor in CVSS spiegelt wider, dass die Schwachstelle über Netzwerk-Authentifizierungspfade ohne vorherige Privilegien ausgeübt werden kann, und nicht, dass jeder einfache, dem Internet zugewandte Tomcat-Einsatz gleichermaßen gefährdet ist. Der Unterschied ist wichtig, wenn es darum geht, die Dringlichkeit von Patches für verschiedene Flotten zu bewerten. Die Teams sollten den Systemen Priorität einräumen, bei denen der Zertifikatsentzug als Live-Zugangskontrollgrenze fungieren soll. (nvd.nist.gov)

Wer wahrscheinlich betroffen ist und wer wahrscheinlich nicht

Der schnellste Weg, auf CVE-2026-24734 zu reagieren, ist, jede Tomcat-Instanz als gleichermaßen verwundbar zu behandeln. Der schnellste Weg, zu wenig zu reagieren, ist die Annahme, dass Sie sicher sind, weil Sie "Tomcat Native" nie explizit als separates Produkt installiert haben. Beide Abkürzungen scheitern, da die tatsächliche Gefährdung von der Kombination aus Version, Connector-Implementierung, Zertifikat-Authentifizierungsmodell und OCSP-Verwendung abhängt. (nvd.nist.gov)

Ein Einsatz ist mit dem höchsten Risiko behaftet, wenn vier Bedingungen zusammentreffen. Erstens: Es wird eine anfällige Tomcat- oder Tomcat Native-Version verwendet. Zweitens wird ein OpenSSL-gestützter Verbindungspfad verwendet, der die OCSP-Funktionen von Tomcat unterstützt, z. B. APR/native, OpenSSL JSSE oder die OpenSSL Panama FFM-Implementierung. Drittens wird die Validierung von Client-Zertifikaten tatsächlich auf eine Weise durchgeführt, die von OCSP abhängt. Viertens tragen diese Client-Zertifikate eine OCSP-Responder-URI, denn laut Tomcat-Dokumentation werden Client-Zertifikate anhand der in die Authority Information Access-Erweiterung eingebetteten Responder-URI validiert. Wenn eines dieser Elemente fehlt, sinkt das praktische Risiko drastisch. (Apache Tomcat)

Ein einfacher JSSE-Einsatz ohne diese OpenSSL-gestützten OCSP-Prüfungen scheint nicht dem verwundbaren Pfad zu entsprechen, den Apache für dieses CVE beschrieben hat. Diese Schlussfolgerung basiert auf Tomcats eigenem Feature Scoping: Die OCSP-Unterstützungsdokumentation listet die Konnektortypen auf und sagt explizit, dass OCSP nicht unterstützt wird mit org.apache.tomcat.util.net.jsse.JSSEImplementierung oder JSSE-Konfigurationsstil. Das ist nicht dasselbe wie zu sagen, dass jeder JSSE-Einsatz für immer gegen jeden Fehler bei der Zertifikatsvalidierung immun ist. Es handelt sich lediglich um die sorgfältigste Auslegung des für CVE-2026-24734 beschriebenen verwundbaren Pfades. (Apache Tomcat)

Eine eingebettete Java-Anwendung verdient besondere Aufmerksamkeit. Viele Teams denken in Server-Paketen, während ihre Produktionsrealität eine Spring Boot-Anwendung mit eingebettetem Tomcat ist. Die Advisory-Datenbank von GitHub verfolgt die verwundbaren Bereiche in tomcat-embed-core und Kater und Kojote Pakete, was bedeutet, dass die Analyse der Softwarezusammensetzung, Build-Manifeste und Abhängigkeitsbäume in den Exposure Review gehören. Ein Team kann keine /opt/tomcat Installation überhaupt und dennoch den verwundbaren Codepfad in einem Anwendungsartefakt tragen. (GitHub)

Die schnellste praktische Triage-Frage lautet daher nicht "Führen wir Tomcat aus?", sondern "Wo beenden wir mTLS-Client-Authentifizierung auf Tomcat mit OCSP-gestütztem Zertifikatswiderruf über einen OpenSSL-gestützten Konnektor in einer der betroffenen Versionsreihen?" Diese Frage ist enger gefasst, besser umsetzbar und näher am tatsächlichen Explosionsradius. (Apache Tomcat)

Wie Sie die Exposition in Ihrer Umgebung bestimmen

Beginnen Sie mit der Versionsinventur. Überprüfen Sie bei einer eigenständigen Tomcat-Installation zunächst den Runtime Train und den Patch-Level. Überprüfen Sie bei eingebetteten Anwendungen die Abhängigkeitsmanifeste und Lockfiles. Bei containerisierten Workloads überprüfen Sie den Inhalt des Images und die gebündelten Bibliotheken der Anwendung. Es geht nicht nur darum, "Tomcat irgendwo" zu finden. Es geht darum, jede Arbeitslast den Versionsbereichen von Apache und NVD zuzuordnen, die tatsächlich betroffen sind. (nvd.nist.gov)

Ein einfacher erster Durchgang bei einer herkömmlichen Installation sieht wie folgt aus:

# Eigenständiger Tomcat Version
$CATALINA_HOME/bin/catalina.sh Version

# Suche nach dem Vorhandensein nativer Bibliotheken
find "$CATALINA_HOME" "$CATALINA_BASE" -iname '*tcnative*' -o -iname 'libtcnative*' 2>/dev/null

# Container-Image oder Paketinventar
rpm -qa | grep -Ei 'tomcat|tcnative'
dpkg -l | grep -Ei 'tomcat|tcnative'

Für eingebettete Java-Anwendungen ist die Überprüfung von Abhängigkeiten ebenso wichtig, da Advisory-Datenbanken die CVE in Paketkoordinaten sowie Serverversionen abbilden. (GitHub)

# Maven
mvn -q dependency:tree | grep -E 'org\.apache\.tomcat|tomcat-embed-core|tomcat-coyote'

# Gradle
./gradlew abhängigkeiten | grep -E 'org\.apache\.tomcat|tomcat-embed-core|tomcat-coyote'

Stellen Sie als nächstes fest, ob die Anwendung überhaupt die von Tomcat dokumentierten Connector-Familien für OCSP verwendet. Der SSL/TLS-Leitfaden von Tomcat zeigt die relevanten Konnektortypen und den Konfigurationsstil. Sie suchen nach Anzeichen für APR/native, OpenSSLImplementierungoder die OpenSSL-Implementierung von Panama sowie die Einstellungen für die Zertifikatsüberprüfung und die OCSP-bezogene Konfiguration. Ein schneller Konfigurationsdurchlauf beantwortet diese Fragen oft in wenigen Minuten (Apache Tomcat)

grep -RInE 'Http11AprProtocol|OpenSSLImplementation|openssl\.panama|ocspEnabled|ocspSoftFail|ocspVerify|certificateVerification|sslImplementationName' \
  "$CATALINA_BASE/conf" "$CATALINA_HOME/conf" 2>/dev/null

Das Tomcat-eigene OCSP-Connector-Beispiel ist ein guter Anhaltspunkt dafür, wie eine entsprechende Konfiguration aussieht. Die Dokumentation zeigt einen APR/nativen Konnektor mit certificateVerification="require" und ein Zertifikat, das unter SSLHostConfigdann wird ein OCSP-Responder-Prozess mit dem OpenSSL ocsp Werkzeug. Wenn Ihr Server nichts hat, was diesem Modell ähnelt, ist die Wahrscheinlichkeit, dass CVE-2026-24734 Ihr dringendes Problem ist, geringer. Wenn doch, sollten Sie weiter suchen. (Apache Tomcat)

Ein reduziertes Beispiel, das dem dokumentierten Muster sehr nahe kommt, sieht wie folgt aus:

Prüfen Sie nach der Konfiguration, ob die verwendeten Client-Zertifikate tatsächlich eine OCSP-Responder-URI in der Erweiterung Authority Information Access enthalten. Der OCSP-Leitfaden von Tomcat besagt, dass das Zertifikat den Ort des Responders kodiert enthalten muss. Ohne diese Angabe ist der vorgesehene OCSP-Validierungspfad möglicherweise gar nicht aktiv. (Apache Tomcat)

openssl x509 -in client.crt -noout -text | sed -n '/Zugangsberechtigung/,+5p'

Prüfen Sie schließlich, ob die Anwendung wirklich von der Client-Zertifikat-Authentifizierung als Sicherheitsgrenze abhängig ist. In vielen Flotten ist TLS überall aktiviert, aber mTLS ist nur auf einer kleinen Teilmenge von Verbindungen, Pfaden oder Diensten aktiviert. Die geschäftlichen Auswirkungen von CVE-2026-24734 sind dort zu spüren, wo die Annahme eines Zertifikats mit der Berechtigung gleichzusetzen ist, etwas Sinnvolles zu tun. Erstellen Sie eine Bestandsaufnahme der Verwaltungsebenen, Partnerendpunkte, Geräteeinführungsdienste, internen APIs und Maschinenidentitäten, auf die diese Aussage zutrifft. Diese Bestandsaufnahme ist in der Regel wichtiger als die reine Anzahl der Hosts. (Apache Tomcat)

Sichere Laborvalidierung für CVE-2026-24734

Der richtige Weg, dieses Problem zu validieren, ist nicht, gegen die Produktion zu improvisieren. Sie müssen die Vertrauensentscheidung in einem Labor reproduzieren, das Sie kontrollieren, und dann das Verhalten vor und nach dem Patching vergleichen. Die Tomcat-Dokumentation liefert bereits die meisten Bausteine: wie man OCSP-fähige Zertifikate erstellt, wie man einen OCSP-fähigen Connector konfiguriert und wie man einen einfachen OCSP-Responder mit OpenSSL startet. Die Aufgabe besteht nun darin, diese Bausteine in einen kontrollierten Widerrufstest zu verwandeln. (Apache Tomcat)

Die Seite der Zertifikatserstellung beginnt mit einer OpenSSL-CA-Konfiguration, die eine OCSP-Responder-URI über die Erweiterung Authority Information Access in das ausgestellte Zertifikat einbettet. Die Tomcat-Dokumentation zeigt die entsprechende Zeile als authorityInfoAccess = OCSP;URI:http://127.0.0.1:8088. Das ist keine dekorative Erweiterung. So weiß Tomcat, wo er nach dem Status des Client-Zertifikats fragen muss. Danach erzeugt der dokumentierte Ablauf einen privaten Schlüssel, erstellt eine CSR, signiert sie und verifiziert dann das resultierende Zertifikat. (Apache Tomcat)

# Erstellen eines privaten Schlüssels
openssl genrsa -aes256 -out ocsp-cert.key 4096

# Erstellen einer CSR
openssl req -config openssl.cnf -new -sha256 \
  -key ocsp-cert.key -out ocsp-cert.csr

# Signieren Sie die CSR
openssl ca -config openssl.cnf -extensions ocsp -days 375 -notext \
  -md sha256 -in ocsp-cert.csr -out ocsp-cert.crt

# Überprüfen Sie das Zertifikat für AIA / OCSP
openssl x509 -noout -text -in ocsp-cert.crt

Auf der Serverseite verwenden Sie einen Tomcat-Connector, der mit den dokumentierten OCSP-fähigen Pfaden übereinstimmt. Wenn Sie das APR/native Beispiel aus den offiziellen Dokumenten nachbilden wollen, verwenden Sie das APR-Protokoll. Wenn Sie speziell den FFM-Pfad testen wollen, verwenden Sie die dokumentierte OpenSSL-Panama-Implementierung auf einer Java-Version, die diese Funktion unterstützt. Der wichtigste Punkt ist, dass Ihre Testumgebung einer der Connector-Familien ähneln sollte, die laut Tomcat OCSP unterstützt. Andernfalls validieren Sie nicht den Codepfad, den dieses CVE tatsächlich abdeckt. (Apache Tomcat)

Die Tomcat-Dokumentation enthält auch einen grundlegenden OpenSSL-Responder-Befehl:

openssl ocsp -port 127.0.0.1:8088 \
  -text -sha256 -index index.txt \
  -CA ca-chain.cert.pem -rkey ocsp-cert.key \
  -rsigner ocsp-cert.crt

Mit dieser Voraussetzung ist eine nützliche Übungssequenz einfach. Stellen Sie zunächst ein Client-Zertifikat von Ihrer Test-CA aus und bestätigen Sie, dass ein Client mit diesem Zertifikat den mTLS-Handshake abschließen und den geschützten Endpunkt erreichen kann. Zweitens widerrufen Sie dieses Client-Zertifikat in Ihrem CA-Index und aktualisieren den OCSP-Responder-Status entsprechend. Drittens: Wiederholen Sie den gleichen Verbindungsversuch mit einem verwundbaren und einem reparierten Build. Die Frage ist nicht, ob Tomcat etwas Interessantes protokolliert. Die Frage ist, ob ein jetzt widerrufenes Client-Zertifikat noch akzeptiert wird. Das ist die Vertrauensentscheidung, um die es in CVE-2026-24734 geht. (Apache Tomcat)

Ein defensiver Test-Client kann so einfach sein wie openssl s_client mit dem Client-Zertifikat und dem Schlüssel:

openssl s_client \
  -connect tomcat-lab.example:8443 \
  -cert revoked-client.crt \
  -key revoked-client.key \
  -CAfile ca-chain.cert.pem \
  -state -tlsextdebug

Behandeln Sie das Ergebnis mit Vorsicht. Ein fehlgeschlagener Handshake nach einer Sperrung ist das erwartete gesunde Ergebnis. Ein erfolgreicher Handshake mit dem widerrufenen Zertifikat ist die Fehlerbedingung. Wenn Sie eine bessere Beobachtbarkeit während des Testens wünschen, empfiehlt der SSL/TLS-Leitfaden von Tomcat die Aktivierung des speziellen TLS-Handshake-Debug-Loggers in logging.propertiesmit Loggernamen wie org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE oder org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE abhängig von dem jeweiligen Anschluss. Diese Protokollierung wird Ihnen nicht auf magische Weise sagen: "CVE-2026-24734 ist passiert", aber sie kann Ihnen helfen, eine gewöhnliche TLS-Fehlkonfiguration von dem spezifischen Vertrauensergebnis zu unterscheiden, das Sie zu validieren versuchen. (Apache Tomcat)

org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE
org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE

Hier ist eine praktische Vorsicht geboten. In der Tomcat-Dokumentation wird darauf hingewiesen, dass bei Verwendung von OCSP der im Zertifikat kodierte Responder aktiv sein muss. Das klingt selbstverständlich, hat aber Auswirkungen auf die Interpretation der Tests. Wenn der Responder nicht verfügbar ist, werden Soft-Fail-Verhalten und Timeout-Verhalten Teil des Ergebnisses. Und das ist genau der Grund, warum die späteren OCSP-Härtungsarbeiten, einschließlich ocspSoftFail, ocspVerify, die Behandlung von Zeitüberschreitungen und die Korrekturen von CVE-2026-29145 vom März 2026 sollten bei der Validierung im Auge behalten werden. Ein System kann von einem defekten Vertrauenspfad zu einem anderen wechseln, wenn Teams nur den Sunny-Day-Fall validieren. (Apache Tomcat)

Was Verteidiger erkennen können und was sie normalerweise nicht erkennen können

CVE-2026-24734 ist keine IOC-reiche Sicherheitslücke. Es gibt keine kanonische Exploit-URI, die in den Zugriffsprotokollen zu finden wäre. Es gibt keine offensichtliche Anwendungsausnahme, die schreit "widerrufenes Zertifikat wurde akzeptiert". In vielen Umgebungen ist das gefährliche Signal das Gegenteil eines Fehlersignals: Eine Verbindung ist erfolgreich, obwohl das Unternehmen glaubt, dass sie hätte fehlschlagen müssen. Damit verlagert sich die Erkennung weg von der allgemeinen Protokollanalyse hin zur Kontrollüberprüfung und zum systemübergreifenden Nachweis. (Google Gruppen)

Die beste unmittelbare Abwehrtechnik ist die aktive Überprüfung. Erstellen Sie einen kleinen Satz von Test-Client-Zertifikaten, deren Lebenszyklus Sie kontrollieren. Widerrufen Sie eines. Versuchen Sie den Handshake. Bestätigen Sie die Ablehnung. Wiederholen Sie den Vorgang nach Upgrades, Änderungen am Zertifikatsspeicher, Änderungen am Connector, Java-Upgrades und Änderungen am OCSP-Responder. Diese Art von Test ist hier wertvoller als darauf zu warten, dass SIEM aus der allgemeinen Telemetrie auf ein subtiles Vertrauensversagen schließt. RFC 6960 und das Gültigkeitsmodell von OpenSSL machen beide deutlich, dass die Aktualität und die Anfrage-Antwort-Bindung Teil der Vertrauensentscheidung sind. Die einzige verlässliche Methode, um zu wissen, dass Ihr Stack diese Semantik nach einer Änderung immer noch erzwingt, ist, sie erneut zu überprüfen. (datatracker.ietf.org)

Passive Telemetrie spielt zwar immer noch eine Rolle, aber sie ist indirekt. Wenn Ihre PKI- oder IAM-Wahrheitsquelle besagt, dass ein Client-Zertifikat widerrufen wurde, während anwendungsseitige Zugriffsprotokolle, Gateway-Protokolle oder nachgelagerte Audit-Aufzeichnungen weiterhin erfolgreiche authentifizierte Sitzungen zeigen, die mit dieser Zertifikatsidentität verbunden sind, ist diese Diskrepanz von Bedeutung. In ausgereiften Unternehmen sollten Zertifikatsinventar, Widerrufsprotokolle und Anwendungszugriffsprotokolle vergleichbar genug sein, um diese Art von Abweichung zu erkennen. Es geht nicht darum, dass Tomcat eine perfekte "Sperrungsumgehungsmeldung" ausgibt. Es geht darum, dass Ihre Kontrollinstanz es schwierig machen sollte, dass tote Anmeldedaten immer wieder in erfolgreichen Anmeldepfaden auftauchen, ohne dass es jemand bemerkt. (datatracker.ietf.org)

Die Debug-Protokollierung des Handshake von Tomcat ist bei der Triage nützlich, weil sie zeigt, wo der Handshake fehlschlägt oder verläuft, und weil Probleme bei der Zertifikatsvalidierung sonst oft in allgemeinem TLS-Rauschen untergehen. Es handelt sich nicht um eine vollständige Erkennungsstrategie, und sie sollte nicht immer und überall eingeschaltet bleiben. Aber während Verifizierungsfenstern, bei der Überprüfung von Vorfällen oder bei kontrollierten Wiederholungstests gibt sie Verteidigern einen besseren Einblick in OCSP-bezogenes Verhalten als normale Anfrageprotokolle. (Apache Tomcat)

Abhilfemaßnahmen und Härtung für Apache Tomcat OCSP-Pfade

Die minimale Abhilfemaßnahme ist klar: Wechseln Sie zu einer fixen Version oder höher. Das bedeutet Tomcat Native 1.3.5 oder 2.0.12 und Apache Tomcat 9.0.115, 10.1.52 oder 11.0.18, je nach Zug, als absolutes Minimum. Aber "oder später" bedeutet, dass hier wichtige Arbeit geleistet wird. Apache hat auch nach der ursprünglichen Veröffentlichung OCSP-bezogene Korrekturen veröffentlicht. Für Teams, die Client-Zertifikate als sinnvolle Zugangskontrolle betrachten, ist es klüger, auf eine aktuelle Wartungsversion umzusteigen, als ewig auf dem ersten gepatchten Build sitzen zu bleiben. (nvd.nist.gov)

Wenn Sie mit den alten Native-Zweigen arbeiten, deren Lebensdauer abgelaufen ist und die NVD immer noch als betroffen auflistet, ist dies nicht der richtige Ort für heldenhafte Patches. Die Durchsetzung von Sperrungen ist eine zentrale Identitätslogik. Der Betrieb von toten Zweigen, von denen bereits bekannt ist, dass sie in der Vergangenheit OCSP-Probleme aufwiesen, und die auch nicht von späteren Härtungsmaßnahmen profitieren, ist die Art von technischer Schuld, die bei der Reaktion auf einen Vorfall am meisten scheitert. Eine Migration ist in der Regel die sicherere und letztlich kostengünstigere Lösung. (nvd.nist.gov)

Testen Sie nach dem Upgrade erneut mit widerrufenen Zertifikaten. Das hört sich banal an, ist aber der wichtigste Schritt, den Teams übergehen. Ein Versionssprung kann Ihnen sagen, dass der Hersteller eine Korrektur geliefert hat. Sie sagt Ihnen jedoch nicht, ob Ihre Umgebung den festen Pfad so ausführt, wie Sie es erwarten, ob Ihr OCSP-Responder die erwartete Semantik zurückgibt oder ob Ihre Anschlussauswahl und -konfiguration auch nach anderen Änderungen noch stimmt. Die Akzeptanz von Patches ohne erneute Prüfung des widerrufenen Zertifikats ist eine Vertrauensannahme, kein Beweis. (GitHub)

Legen Sie die OCSP-Richtlinie eindeutig fest. Referenzdokumente zur Konfiguration von Tomcat ocspSoftFail und ocspVerifyund die Patch-Arbeit fügte Unterstützung für Timeout- und Verifizierungsflags im FFM-Pfad hinzu. Das bedeutet, dass sicherheitskritisches Verhalten nicht vollständig durch "OCSP ist eingeschaltet" erfasst wird. Die Teams sollten dokumentieren, ob Soft Fail erlaubt ist, welches Timeout-Verhalten akzeptabel ist, ob der Trust Store und die Verifizierungsflags absichtlich gesetzt werden und wie sich das System verhalten soll, wenn der Responder nicht verfügbar ist oder sich verspätet. Unklarheiten in Bezug auf diese Entscheidungen können versehentlich zu Sicherheitsrichtlinien für die Produktion werden. (Apache Tomcat)

Kompensierende Kontrollen können die Gefährdung während der Einführung von Upgrades verringern, sind aber kein Ersatz für die Durchsetzung von Sperrungen. Kombinieren Sie mTLS an den hochwertigsten Schnittstellen mit einer geringeren Netzwerkexposition, einer expliziten Autorisierung auf der Anwendungsebene, kurzlebigen Client-Zertifikaten und schnellen Zertifikatsaustausch-Workflows. Diese Kontrollen sind wichtig, da sie den Wert eines abgelaufenen oder kompromittierten Zertifikats verringern, selbst wenn die Widerrufsbehandlung vorübergehend unvollkommen ist. Sie können die fehlende Garantie, dass ein widerrufenes Zertifikat wirklich tot ist, nicht wiederherstellen. Das kann nur ein fester und verifizierter Vertrauenspfad leisten. (datatracker.ietf.org)

Es gibt hier einen Arbeitsablauf, der oft übersehen wird. Die Schwierigkeit besteht nicht darin, einen Shell-Befehl zum Testen eines Connectors zu finden. Vielmehr geht es darum, Asset Scoping, Versionsinventarisierung, Connector Fingerprinting, Zertifikatsprüfung, erneutes Testen und Beweissammlung jedes Mal miteinander zu verknüpfen, wenn ein Release, eine Zertifikatsrotation oder eine PKI-Änderung ansteht. In den öffentlichen Unterlagen von Penligent werden agentenbasierte Workflows unter menschlicher Kontrolle, der Zugriff auf eine große Kali-Tool-Oberfläche per Mausklick sowie die Verifizierung und Berichterstattung als zusammenhängende Schleife hervorgehoben. In der Praxis ist das die Form der Arbeit, die Verteidiger nach einem Fehler wie diesem benötigen: nicht nur Patches, sondern wiederholbare Beweise, dass der verwundbare Vertrauenspfad auf den Systemen, die wirklich wichtig sind, verschwunden ist. (penligent.ai)

Verwandte CVEs, die CVE-2026-24734 nicht weniger, sondern wichtiger machen

Ein Grund, CVE-2026-24734 ernst zu nehmen, ist die Tatsache, dass es sich nicht um ein isoliertes Problem handelt. Die Sicherheitshistorie von Tomcat Native enthält frühere OCSP-bezogene Probleme, die die Durchsetzung von Sperrungen betrafen, was dies weniger zu einem zufälligen Einzelfall als vielmehr zu einer Erinnerung daran macht, dass die Handhabung des Zertifikatsstatus leicht zu einem subtilen Fehler führen kann. Die Sicherheitsseite von Apache Native ist hier besonders nützlich, da sie die Historie an einer Stelle auflistet. (Apache Tomcat)

CVE-2017-15698 war eine OCSP-Prüfungsauslassung in Tomcat Native. Laut Apache hat der Konnektor beim Parsen der AIA-Erweiterung eines Client-Zertifikats Felder, die länger als 127 Byte sind, nicht korrekt verarbeitet, was dazu führte, dass die OCSP-Prüfung übersprungen wurde. Die Auswirkung war direkt: Client-Zertifikate, die abgelehnt werden sollten, wenn die OCSP-Prüfung gelaufen wäre, konnten stattdessen akzeptiert werden. Dies ist ein anderer Implementierungsfehler als CVE-2026-24734, aber das Thema ist identisch. Die Sperrlogik ist sicherheitskritisch, und scheinbar sekundäre Parsing- oder Validierungsfehler können sie aushebeln. (Apache Tomcat)

CVE-2018-8019 und CVE-2018-8020 gingen in die gleiche Richtung. In einem Fall wurden ungültige OCSP-Antworten falsch behandelt, wodurch widerrufene Client-Zertifikate falsch identifiziert werden konnten. Im anderen Fall überprüfte Tomcat Native vorproduzierte OCSP-Antworten, die Listen von Zertifikatsstatus enthielten, nicht ordnungsgemäß, was wiederum dazu führte, dass widerrufene Client-Zertifikate bei Verbindungen, die gegenseitiges TLS erfordern, durchschlüpfen konnten. Diese älteren Probleme sind wertvoll, weil sie den richtigen Instinkt schulen: Wenn es um OCSP-Behandlung geht, sollten Sie nicht bei der Syntax oder den Statusfeldern stehen bleiben. Vergewissern Sie sich, dass die Berechtigung zur Beantwortung, die Struktur der Antwort, die Aktualität der Antwort und die genaue Zertifikatsidentität, die ausgewertet wird, korrekt gehandhabt werden. (Apache Tomcat)

Dann kommt CVE-2026-24734, das unvollständige Verifizierungs- und Freshness-Checks in den Native- und FFM-Pfaden behebt. Und kurz darauf erscheint CVE-2026-29145, wobei Apache angibt, dass CLIENT_CERT Die Authentifizierung schlug OCSP-Prüfungen in einigen Szenarien nicht wie erwartet fehl, selbst wenn Soft Fail deaktiviert war. Dieses Folgeproblem ist kein Beweis dafür, dass die ursprüngliche Korrektur falsch war. Es ist ein Beweis dafür, dass das OCSP-Verhalten unter betrieblichen Randbedingungen nach wie vor kompliziert genug ist, so dass Verteidigungsteams den gesamten Vertrauenspfad validieren sollten und nicht einfach davon ausgehen, dass "einmal gepatcht" gleich "für immer gelöst" ist. (Apache Tomcat)

Für Teams, die in großem Umfang Client-Zertifikate verwenden, ist eine weitere naheliegende Lektion die Umgehung der Zertifikatsüberprüfung durch Tomcat außerhalb der OCSP-Familie. Apache hat CVE-2025-66614 als Umgehung der Verifizierung von Client-Zertifikaten im Zusammenhang mit der Zuordnung virtueller Hosts veröffentlicht und später CVE-2026-32990 als unvollständige Korrektur in diesem Bereich bekannt gegeben. Die direkten Mechanismen unterscheiden sich von CVE-2026-24734, aber die operative Botschaft ist dieselbe: Zertifikatsbasierte Vertrauensgrenzen in Tomcat verdienen eine weitere Überprüfung, da das Verhalten von Konnektoren, die Zuordnung von Hosts und die Widerrufslogik alle zu Autorisierungsfehlern führen können, wenn sie falsch implementiert oder konfiguriert sind. (Apache Tomcat)

CVE	Bereich	Warum das hier wichtig ist	Praktischer Unterricht
CVE-2017-15698	OCSP-Prüfung ausgelassen	AIA-Parsing-Fehler kann OCSP komplett überspringen	Gehen Sie niemals davon aus, dass "OCSP aktiviert" "OCSP erzwungen" bedeutet.
CVE-2018-8019	Ungültige OCSP-Antwortbehandlung	Widerrufene Client-Zertifikate könnten falsch identifiziert werden	Die Behandlung des Antwortformats ist Teil der Korrektheit der Authentifizierung
CVE-2018-8020	Vorgefertigte OCSP-Antwortbehandlung	Widerrufene Client-Zertifikate können immer noch authentifiziert werden	Zwischengespeicherte oder gebündelte Antwortlogik erfordert strenge Validierung
CVE-2026-24734	Unvollständige Überprüfung und Frischekontrollen	Der Widerruf kann umgangen werden	Signatur, Nonce und Aktualität sind wichtig
CVE-2026-29145	Soft-Fail-Verhalten in Grenzfällen	CLIENT_CERT Autorisierung kann immer noch scheitern	Flicken, dann erneut die Randbedingungen testen, nicht nur die glücklichen Pfade

Nachweise, Berichterstattung und erneute Tests nach dem Patch

Nach der Korrektur ist die Arbeit erst dann abgeschlossen, wenn die Beweise so gut sind, dass ein anderer Techniker, ein Prüfer oder Ihr zukünftiges Ich drei Fragen beantworten kann, ohne zu raten: Welches System war betroffen, was hat sich geändert, und welcher genaue Test hat bewiesen, dass der Pfad mit dem widerrufenen Zertifikat nun fehlschlägt. Das bedeutet, dass die betreffende Anschlusskonfiguration, die beim Testen verwendete Zertifikatsidentität, das Widerrufsereignis, das Vorher-Nachher-Handshake-Verhalten und der genaue Versionsstand von Tomcat oder Tomcat Native bei jedem Durchlauf aufbewahrt werden müssen. Gute Beweise für Abhilfemaßnahmen sind konkret oder sie sind nicht nützlich. (Apache Tomcat)

Das ist auch der Punkt, an dem KI-Hilfe entweder hilft oder schadet. Eine vage KI-generierte Notiz, die besagt, dass "erfolgreich aktualisiert und erneut getestet" wurde, ist kein Beweis. Die Berichtsanleitung von Penligent trifft den richtigen Teil dieses Problems: Ein aussagekräftiger Pentest- oder Validierungsbericht benötigt eine klare Position, eine konkrete Aussage zu den Auswirkungen, Reproduktionsschritte und unterstützende Artefakte anstelle von generischer Modellprosa. Diese Denkweise ist genau das, was die Post-Patch-Validierung für CVE-2026-24734 braucht. Eine gute Aufzeichnung sollte es einem anderen Ingenieur ermöglichen, die Vertrauensentscheidung zu wiederholen und nicht einfach darauf zu vertrauen, dass Sie es bereits getan haben. (penligent.ai)

Die wahre Lektion von CVE-2026-24734

CVE-2026-24734 ist eine nützliche Schwachstelle, weil sie eine weit verbreitete Sicherheitsangewohnheit aufdeckt: Viele Systeme behandeln das Vertrauen in ein Zertifikat als statische Eigenschaft, obwohl es in Wirklichkeit eine lebendige Entscheidung ist. Ein Zertifikat kann wohlgeformt und vom richtigen Aussteller signiert sein, aber dennoch nicht vertrauenswürdig sein, weil der Aussteller es widerrufen hat. OCSP soll diese aktuelle Entscheidung in den TLS-Handshake einbringen. Wenn die Implementierung den Responder nicht korrekt verifiziert, Anfrage und Antwort nicht korrekt verknüpft oder die Aktualität nicht korrekt durchsetzt, trifft das System keine Live-Vertrauensentscheidung mehr. Es trifft eine veraltete Entscheidung. (datatracker.ietf.org)

Aus diesem Grund verdient dieses CVE mehr Aufmerksamkeit, als seine Überschrift vermuten lässt. Für Teams, die Tomcat verwenden, um gewöhnliches HTTPS ohne Client-Zertifikate zu beenden, ist der Fehler vielleicht ein wenig dramatisches Patch-Element. Für Teams, die mTLS als echte Grenze verwenden, ist es ein direkter Test, ob widerrufene Identitäten wirklich sterben, wenn die Organisation sagt, dass sie es sollten. Apache hat das Problem behoben. Die verbleibende Arbeit liegt bei den Verteidigern: herausfinden, wo der verwundbare Vertrauenspfad existierte, auf aktuelle unterstützte Versionen umsteigen, mit widerrufenen Zertifikaten validieren und dies immer wieder tun, wenn sich die PKI, der Connector-Stack oder die Identitätsgrenze ändert. (Google Gruppen)

Weiterführende Literatur und Referenzen

• NVD-Eintrag für CVE-2026-24734, betroffene Versionen, CVSS und Referenzsatz. (nvd.nist.gov)
• Apache-Hinweistext mit Schweregrad, betroffenen Versionen, Abhilfemaßnahmen und Dank an Joshua Rogers. (Google Gruppen)
• Eintrag auf der Sicherheitsseite von Apache Tomcat 9 für CVE-2026-24734 und den späteren OCSP-bezogenen Nachfolger CVE-2026-29145. (Apache Tomcat)
• Eintrag auf der Sicherheitsseite von Apache Tomcat 10.1 für CVE-2026-24734 und spätere OCSP-bezogene Nachfolge CVE-2026-29145. (Apache Tomcat)
• Eintrag auf der Sicherheitsseite von Apache Tomcat 11 für CVE-2026-24734 und den späteren OCSP-bezogenen Nachfolger CVE-2026-29145. (Apache Tomcat)
• Apache Tomcat Native Sicherheitsseite für CVE-2026-24734, sowie frühere OCSP-Linien einschließlich CVE-2017-15698, CVE-2018-8019 und CVE-2018-8020. (Apache Tomcat)
• Apache Tomcat Versionshinweise, die die im Januar 2026 gefixten Versionen und die weitere OCSP-bezogene Entwicklung in späteren Versionen zeigen. (Apache Tomcat)
• Tomcat SSL/TLS OCSP-Dokumentation, die die unterstützten Konnektor-Familien, den Fokus auf Client-Zertifikate, die AIA-Anforderungen, ein Konnektor-Beispiel, den Start des Responders und die Protokollierung des Handshakes behandelt. (Apache Tomcat)
• Tomcat-Konnektor-Konfigurationsreferenz für ocspEnabled, ocspSoftFailund ocspVerify. (Apache Tomcat)
• OpenSSL-Dokumentation für OCSP_basic_verify, OCSP_Prüfung_der_Gültigkeit, Status-Extraktion und Behandlung des Antwortalters. (docs.openssl.org)
• RFC 6960 für OCSP-Semantiken, einschließlich thisUpdate, nextUpdate, produziertAufund nonce. (datatracker.ietf.org)
• Apache-Tomcat-Fehlerbehebung e76e9eadie die hinzugefügten Nonce-, Signatur- und Freshness-Prüfungen im OpenSSL FFM-Pfad zeigt. (GitHub)
• Tomcat Native Folge-Commit 69a977dDies erklärt, warum die OCSP-Härtung auch nach der ursprünglichen Offenlegung fortgesetzt wurde. (GitHub)
• Penligent-Homepage für öffentliche Produktinformationen rund um agenturische Workflows, Tool-Zugang und Verifizierung sowie Berichterstattung. (penligent.ai)
• Project Glasswing Shows Why AI Defense Needs Continuous Penetration Testing (Projekt Glasswing zeigt, warum die KI-Abwehr kontinuierliche Penetrationstests benötigt), für die breitere Argumentation, dass Sicherheitskontrollen eine wiederkehrende Überprüfung durch Gegner benötigen, anstatt einmalige Annahmen. (penligent.ai)
• How to Get an AI Pentest Report (Wie man einen AI-Pentest-Bericht erhält), für praktische Hinweise zur Qualität der Nachweise, Reproduktionsdetails und unterstützende Artefakte in der Sicherheitsberichterstattung. (penligent.ai)