CVE-2026-95663

Zusammenfassung

Schwachstelle durch unzureichenden Sitzungsablauf in der Apache-Camel-Keycloak-Komponente. Dieses Problem betrifft Apache Camel: von 4.16.0 vor 4.18.5, von 4.19.0 vor 4.22.2. Wenn die Token-Introspektion in der KeycloakSecurityPolicy von camel-keycloak aktiviert ist (useTokenIntrospection=true), validiert der Sicherheitsprozessor das Zugriffstoken einer Anfrage, indem er es an den OAuth-2.0-Token-Introspektionsendpunkt von Keycloak sendet, und akzeptiert das Token, solange die Antwort es als aktiv meldet. Der Introspektionsendpunkt meldet ein Token als inaktiv, sobald seine exp-Zeit (Ablaufzeit) verstrichen ist, sodass auf diesem Pfad das active-Flag die Durchsetzung des Token-Ablaufs übernimmt. Introspektionsergebnisse werden standardmäßig zwischengespeichert (introspectionCacheEnabled=true, introspectionCacheTtl=60 Sekunden), und beide mit der Komponente ausgelieferten Cache-Implementierungen, ConcurrentMapTokenCache und CaffeineTokenCache, ließen einen Eintrag nach einer festen Zeit ab seiner Einfügung ablaufen, ohne diese Lebensdauer durch den exp-Claim zu begrenzen, den die zwischengespeicherte Antwort bereits enthielt. Der KeycloakSecurityProcessor wiederum prüfte auf jedem Pfad, der die Introspektion nutzt, nur das active-Flag des Ergebnisses und verglich exp nie mit der aktuellen Zeit. Eine Antwort, die kurz vor dem Ablauf des Tokens zwischengespeichert wurde, wurde daher späteren Anfragen mit demselben Token bis zu der konfigurierten Time-to-Live nach dem Ablauf des Tokens ausgeliefert, und diese Anfragen wurden mit den Rollen und Berechtigungen zugelassen, die das abgelaufene Token getragen hatte, obwohl RFC 7662, der die Token-Introspektion definiert, festlegt, dass eine Antwort, die exp enthält, nicht über diesen Zeitpunkt hinaus zwischengespeichert werden darf. Das Zugriffstoken wird vom Aufrufer mit jeder Anfrage übermittelt, typischerweise als Bearer-Token im Authorization-Header, sodass ein Aufrufer, der ein noch vor wenigen Augenblicken gültiges Token besitzt, es nach seinem Ablauf weiterverwenden konnte, solange der zwischengespeicherte Eintrag lebte. Das Zeitfenster ist durch introspectionCacheTtl begrenzt, das standardmäßig 60 Sekunden und 300 bis 600 Sekunden beträgt, wo der Empfehlung der Dokumentation für interne Dienste gefolgt wurde, und es öffnet sich nur für ein Token, das derselbe Camel-Prozess introspektiert und zwischengespeichert hat, während das Token noch aktiv war. Das Problem gewährt nichts über das hinaus, was das Token bereits trug: Es ermöglicht weder Token-Fälschung noch Rechteausweitung, und die Token-Introspektion ist standardmäßig nicht aktiviert, weshalb die Schwere als mittel eingestuft wird. Der lokale JWT-Verifikationspfad, der verwendet wird, wenn die Introspektion deaktiviert ist, ist von diesem Problem nicht betroffen. Benutzern wird empfohlen, auf Version 4.23.0 zu aktualisieren, die das Problem behebt. Wenn Benutzer den Release-Zweig 4.22.x verwenden, wird ihnen empfohlen, auf 4.22.2 zu aktualisieren. Wenn Benutzer den Release-Zweig 4.18.x verwenden, wird ihnen empfohlen, auf 4.18.5 zu aktualisieren. Die Release-Linien 4.16.x, 4.17.x und 4.19.x bis 4.21.x haben ihr Lebensende erreicht, bevor dieses Problem behoben wurde, und erhalten keinen Fix, sodass Bereitstellungen auf ihnen auf eine unterstützte Version wechseln müssen. Für Bereitstellungen, die nicht sofort aktualisieren können, setzen Sie introspectionCacheEnabled=false in der KeycloakSecurityPolicy, sodass jede Anfrage gegen den Introspektionsendpunkt geprüft wird, der ein abgelaufenes Token als inaktiv meldet, zum Preis eines Introspektionsaufrufs pro Anfrage. Das Verringern von introspectionCacheTtl verkleinert das Zeitfenster nur und schließt es nicht.