CVE-2026-66908

Zusammenfassung

Schwachstelle durch unzureichende Authentifizierung in der Apache Camel Platform HTTP Main-Komponente. Dieses Problem betrifft Apache Camel: von 4.8.0 bis vor 4.22.0. Der eingebettete HTTP-Server von camel-main kann seine Endpunkte mit JWT-Authentifizierung schützen, die über authenticationEnabled zusammen mit den JWT-Keystore-Eigenschaften konfiguriert wird. JWTAuthenticationConfigurer.buildJwtOptions gab null zurück, wenn weder jwtIssuer noch jwtAudience konfiguriert war, und der Aufrufer übersprang daraufhin den Aufruf von JWTAuthOptions.setJWTOptions vollständig, sodass die Vert.x-JWTAuth-Instanz allein aus dem Keystore erstellt wurde. Das Ergebnis war, dass eingehende Token nur auf Signatur und Ablauf geprüft wurden: Die Claims iss und aud wurden überhaupt nicht validiert. Nichts deutete darauf hin – der Server startete normal und meldete keine Warnung –, sodass eine auf die dokumentierte Weise konfigurierte Bereitstellung stillschweigend weniger durchsetzte, als der Betreiber glaubte, aktiviert zu haben, und die Komponentendokumentation selbst stellte die Prüfung von Signatur und Ablauf als Standard dar, mit Issuer und Audience als optionalem Zusatz. Sowohl der Anwendungsserver als auch der Verwaltungsserver waren betroffen, da die Auslassung in beiden configureAuthentication-Pfaden vorhanden war. Daher wurde jedes nicht abgelaufene Token akzeptiert, das von einem Schlüssel signiert wurde, dem der konfigurierte Keystore vertraut, unabhängig davon, welcher Issuer es ausgestellt hatte oder für welche Audience es bestimmt war. Wie weit das reicht, hängt von der Vertrauensmenge des Keystores ab: Gehört der Signaturschlüssel zu einem gemeinsamen oder mandantenfähigen Identitätsanbieter, wird ein Token akzeptiert, das legitimerweise für eine völlig andere Audience ausgestellt wurde, während ein Keystore, der einen dedizierten Signaturschlüssel enthält, dies auf die Wiederverwendung von Token einschränkt, die für andere Dienste innerhalb derselben Vertrauensdomäne ausgestellt wurden. Die Optionen jwtIssuer und jwtAudience existierten vor 4.21.0 nicht, daher gab es in früheren Versionen keine unterstützte Möglichkeit, diese Claims überhaupt durchzusetzen. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, die das Problem behebt. Ab 4.22.0 verweigert der Server den Start, wenn ein JWT-Keystore konfiguriert ist, aber weder jwtIssuer noch jwtAudience gesetzt ist, und nennt dabei die betroffenen Eigenschaften; eine Bereitstellung, die tatsächlich nur die Signatur- und Ablaufprüfung wünscht, muss dies explizit über die neue Option jwtAllowMissingIssuerAndAudience angeben, die standardmäßig false ist. Dieses Verhalten ist nur in 4.22.0 behoben. Die Versionen 4.14.9 und 4.18.4 ändern den Standard nicht: Sie fügen die Optionen jwtIssuer und jwtAudience hinzu, damit Betreiber in diesen Wartungslinien die Claims per Konfiguration durchsetzen können. Eine Installation, die auf 4.14.9 oder 4.18.4 aktualisiert, ohne mindestens eine dieser beiden Eigenschaften zu setzen, akzeptiert weiterhin jedes nicht abgelaufene Token, das von einem vertrauenswürdigen Schlüssel signiert wurde. Benutzer von 4.14.x oder 4.18.x sollten daher auf 4.14.9 oder 4.18.4 aktualisieren und anschließend jwtIssuer, jwtAudience oder beide setzen. Versionen von 4.8.0 bis einschließlich 4.21.x bieten keine Möglichkeit, diese Claims durchzusetzen, und sollten auf eine Version umgestellt werden, die dies unterstützt. Beschränken Sie den JWT-Keystore unabhängig von der Version auf die kleinstmögliche Vertrauensmenge – idealerweise einen für diesen Dienst dedizierten Signaturschlüssel anstelle eines gemeinsamen Schlüssels des Identitätsanbieters –, und stellen Sie dort, wo ein Gateway vor dem Server bereits Issuer und Audience validiert, sicher, dass es nicht umgangen werden kann. Hinweise: Das JIRA-Ticket: https://issues.apache.org/jira/browse/CAMEL-24281 verweist auf die verschiedenen Commits, die das Problem behoben haben, und enthält weitere Details. Der Fail-Closed-Mechanismus konnte nicht zurückportiert werden. Die Optionen jwtIssuer und jwtAudience wurden selbst erst in 4.21.0 durch CAMEL-23525 eingeführt. Daher gab es in camel-4.18.x und camel-4.14.x nichts, was ein Betreiber hätte setzen können, um die Anforderung zu erfüllen, und der Fail-Closed-Mechanismus hätte jede JWT-Bereitstellung in diesen Zweigen zerstört, ohne dass eine Abhilfe verfügbar gewesen wäre.