CVE-2026-53913
Apache Camel Keycloak: KeycloakSecurityPolicy überprüft das Bearer-Zugriffstoken nur innerhalb seiner Rollen- und Berechtigungsprüfungen, sodass das Token in der Standardkonfiguration nie verifiziert wird und jeder Nicht-Null-Bearer-Wert akzeptiert wird.
- Veröffentlicht
- 06.07.2026
- Aktualisiert
- 07.07.2026
- CNA zuweisen
- apache
- Beweise beobachtet
- 07.08.2026
Primäres CVSS
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HNiedrig · nächste 30 Tage
- Perzentil
- 63,3 %
- Modelldatum
- 21.09.2026
EPSS ist eine statistische Schätzung, keine Gewissheit oder ein Maß für die Auswirkung. Kombinieren Sie es mit CVSS, KEV-Status, Belichtung und Ihrer Umgebung.
Zusammenfassung
# Unsachgemäße Authentifizierung, fehlende Authentifizierung für kritische Funktionen, nicht sicheres Fehlschlagen („Failing Open“) – Schwachstelle in der Apache Camel Keycloak-Komponente Die KeycloakSecurityPolicy von camel-keycloak schützt eine Route, indem sie KeycloakSecurityProcessor.beforeProcess() ausführt, das drei Prüfungen in Folge durchführt: Es lehnt eine Anfrage ohne Zugriffstoken ab, validiert dann – nur wenn requiredRoles nicht leer ist – die Rollen und validiert – nur wenn requiredPermissions nicht leer ist – die Berechtigungen. Die eigentliche kryptografische Verifizierung des Bearer-Zugriffstokens (Signatur, Aussteller und Ablauf für ein lokales JWT oder Aktiv-Status und Aussteller für die Token-Introspection) wird ausschließlich innerhalb dieser Rollen- und Berechtigungsprüfungen durchgeführt. KeycloakSecurityPolicy setzt requiredRoles und requiredPermissions standardmäßig auf leer – was dem dokumentierten „Basic Setup“ entspricht –, sodass bei einer so konfigurierten Route die Rollen- und Berechtigungsprüfungen übersprungen werden und das Zugriffstoken daher nie verifiziert wird. Die Token-Präsenzprüfung lehnt ein fehlendes Token weiterhin ab, aber ein ungültiges Token wird akzeptiert: Jeder Nicht-Null-Wert im Authorization: Bearer-Header – einschließlich einer beliebigen Zeichenkette oder eines gefälschten, unsignierten JWT – besteht die Richtlinie und die Anfrage erreicht die geschützte Route, ohne Signatur-, Aussteller- oder Ablaufprüfung und ohne Anfrage an Keycloak. Das Token wird aus dem eingehenden Anfrage-Header gelesen, da allowTokenFromHeader standardmäßig auf true gesetzt ist. Da der normale Grund, eine Route hinter diese Richtlinie zu legen, darin besteht, dass die Route serverseitige Arbeit ausführt, führt die Umgehung zu nicht authentifiziertem Zugriff auf diese Arbeit; wo die geschützte Route an einen codeausführungsfähigen Producer weiterleitet, kann dies zu nicht authentifizierter Remote-Codeausführung führen. Dieser Fehler ist unabhängig von CVE-2026-23552: Dieses Problem betraf den Aussteller-Anspruch und wurde durch Hinzufügen einer Prüfung innerhalb der Verifizierungsroutine behoben, aber hier wird die Verifizierungsroutine in der Standardkonfiguration überhaupt nicht erreicht, sodass der Fehler bestehen bleibt. Dieses Problem betrifft Apache Camel: von 4.15.0 vor 4.18.3, von 4.19.0 vor 4.21.0. Benutzern wird empfohlen, auf Version 4.21.0 zu aktualisieren, die das Problem behebt. Wenn Benutzer auf dem 4.18.x-Release-Stream sind, wird empfohlen, auf 4.18.3 zu aktualisieren. Für Bereitstellungen, die nicht sofort aktualisieren können, konfigurieren Sie ein nicht leeres requiredRoles oder requiredPermissions auf jeder KeycloakSecurityPolicy, damit der Token-Verifizierungspfad ausgeführt wird, setzen Sie allowTokenFromHeader auf false, wo das Token nicht aus dem Anfrage-Header erwartet wird, oder führen Sie die Token-Verifizierung auf der Framework-Ebene vor der Richtlinie durch.
Verantwortungsvoller Umgang
Verwenden Sie Schwachstelleninformationen nur auf Systemen, die Sie besitzen oder zu deren Testen Sie berechtigt sind. Kitploit verlinkt auf öffentliche Forschungsmetadaten und speichert keinen Exploit-Code oder bösartige Payloads.