CVE-2026-66908

Beschreibung

Unsachgemäße Authentifizierungslücke in der HTTP-Hauptkomponente der Apache Camel Plattform. Dieses Problem betrifft Apache Camel: von 4.8.0 vor 4.22.0. Der eingebettete HTTP-Server für Kamel-Main kann seine Endpunkte mit JWT-Authentifizierung schützen, konfiguriert durch AuthentifizierungEnabled zusammen mit den JWT-Keystore-Eigenschaften. JWTAuthenticationConfigurer.buildJwtOptions gab null zurück, als weder jwtIssuer noch jwtAudience konfiguriert wurden und der Aufrufer dann die JWTAuthOptions übersprang. setJWTOptions wird vollständig aufgerufen, so dass die Vert.x JWTAuth-Instanz allein aus dem Keystore erstellt wurde. Das Ergebnis war, dass eingehende Token nur auf Signatur und Ablauf überprüft wurden: Die iss- und aud-Ansprüche wurden überhaupt nicht validiert. Nichts signalisierte dies - der Server startete normal und meldete keine Warnung - so konfigurierte eine Bereitstellung die dokumentierte Art und Weise stillschweigend, die weniger durchgesetzt wurde, als der Betreiber glaubte, und die Komponentendokumentation selbst präsentierte Signatur und Ablaufprüfung als Standard mit dem Emittenten und dem Publikum als optionales Extra. Sowohl der Anwendungsserver als auch der Verwaltungsserver waren betroffen, da die Auslassung in jedem der beiden configurationAuthentication-Pfade lag. Jedes nicht abgelaufene Token, das von einem beliebigen Schlüssel signiert wurde, dem der konfigurierte Keystore vertraut, wurde daher akzeptiert, unabhängig davon, für welchen Emittenten es geprägt wurde oder für welches Publikum es bestimmt war. Wie weit das reicht, hängt vom Vertrauenssatz des Keystores ab: Wenn der Signaturschlüssel zu einem Shared- oder Multi-Tenant-Identity-Provider gehört, wird ein Token akzeptiert, der rechtmäßig für eine völlig andere Zielgruppe ausgegeben wurde, während ein Keystore mit einem dedizierten Unterzeichner ihn auf die Wiederverwendung von Token einschränkt, die für andere Dienste innerhalb derselben Trust-Domain geprägt wurden. Die jwtIssuer- und jwtAudience-Optionen existierten nicht vor 4.21.0, daher gab es bei früheren Veröffentlichungen keine unterstützte Möglichkeit, diese Ansprüche durchzusetzen. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, wodurch das Problem behoben wird. Ab 4.22.0 weigert sich der Server zu starten, wenn ein JWT-Keystore konfiguriert ist, aber weder jwtIssuer noch jwtAudience sind gesetzt, wobei die beteiligten Eigenschaften benannt werden, und eine Bereitstellung, die wirklich Signatur und Ablaufvalidierung wünscht, muss dies nur explizit mit der neuen Option jwtAllowMissingIssuerAndAudience sagen, die standardmäßig auf false lautet. Dieses Verhalten ist nur auf 4.22.0 festgelegt. Die Versionen 4.14.9 und 4.18.4 ändern nichts an der Standardeinstellung: Sie fügen die Optionen jwtIssuer und jwtAudience hinzu, so dass Betreiber auf diesen Wartungslinien die Ansprüche durch Konfiguration durchsetzen können, und eine Installation, die auf 4.14.9 oder 4.18.4 aktualisiert, ohne auch mindestens eine dieser beiden Eigenschaften festzulegen, akzeptiert immer noch jedes nicht abgelaufene Token, das von einem vertrauenswürdigen Schlüssel signiert wurde. Benutzer auf 4.14.x oder 4.18.x sollten daher auf 4.14.9 oder 4.18.4 upgraden und dann jwtIssuer, jwtAudience oder beides festlegen. Releases von 4.8.0 bis einschließlich 4.21.x bieten keine Möglichkeit, diese Ansprüche durchzusetzen und sollten auf eine Version verschoben werden, die dies tut. Beschränken Sie den JWT-Keystore unabhängig von der Version auf das kleinstmögliche Trust-Set - idealerweise ein ..

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Apache Software Foundation camel.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.