CVE-2026-66908
Apache Camel: Camel-platform-http-main: when JWT authentication was configured with a keystore but no issuer or audience, the iss and aud claims were never validated, so any unexpired token signed by a trusted key was accepted
Description
Improper Authentication vulnerability in Apache Camel Platform HTTP Main component. This issue affects Apache Camel: from 4.8.0 before 4.22.0. The camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legitimately issued for an entirely different audience is accepted, while a keystore holding a dedicated signer narrows it to reuse of tokens minted for other services within the same trust domain. The jwtIssuer and jwtAudience options did not exist before 4.21.0, so on earlier releases there was no supported way to have these claims enforced at all. Users are recommended to upgrade to version 4.22.0, which fixes the issue. From 4.22.0 the server refuses to start when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set, naming the properties involved, and a deployment that genuinely wants signature and expiry validation only must say so explicitly with the new jwtAllowMissingIssuerAndAudience option, which defaults to false. This behaviour is fixed only on 4.22.0. The 4.14.9 and 4.18.4 releases do not change the default: they add the jwtIssuer and jwtAudience options so that operators on those maintenance lines can enforce the claims by configuration, and an installation that upgrades to 4.14.9 or 4.18.4 without also setting at least one of those two properties is still accepting any unexpired token signed by a trusted key. Users on 4.14.x or 4.18.x should therefore upgrade to 4.14.9 or 4.18.4 and then set jwtIssuer, jwtAudience, or both. Releases from 4.8.0 up to and including 4.21.x offer no way to enforce these claims and should be moved to a version that does. Independently of version, restrict the JWT keystore to the smallest possible trust set - ideally a signer dedicated to this service rather than a shared identity-provider key - and where a gateway already validates issuer and audience in front of the server, ensure it cannot be bypassed. Notes: The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24281 refers to the various commits that resolved the issue, and has more details. The fail-closed guard could not be backported. The jwtIssuer and jwtAudience options were themselves only introduced in 4.21.0 by CAMEL-23525, so on camel-4.18.x and camel-4.14.x there was nothing an operator could set to satisfy the requirement and the guard would have broken every JWT deployment on those branches with no remedy available.
INFO
Published Date :
Aug. 24, 2026, 5:18 p.m.
Last Modified :
Oct. 24, 2026, 4:10 p.m.
Remotely Exploit :
Yes !
Source :
[email protected]
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS | 134c704f-9b21-4f2e-91b3-4a467353bcc0 | |||||
| CVSS 3.1 | HIGH | 134c704f-9b21-4f2e-91b3-4a467353bcc0 |
Solution
- Upgrade to Apache Camel version 4.22.0 or later.
- On older versions, configure jwtIssuer and jwtAudience.
- Restrict JWT keystore trust set.
- Ensure front-end gateway validation is not bypassed.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-66908.
| URL | Resource |
|---|---|
| https://camel.apache.org/security/CVE-2026-66908.html | Mailing List Vendor Advisory |
| http://www.openwall.com/lists/oss-security/2026/08/24/12 | Mailing List Third Party Advisory |
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-66908 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-66908
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-66908 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-66908 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Translated by [email protected]
Oct. 24, 2026
Action Type Old Value New Value Changed Translation Title: Apache Camel de Apache Software Foundation, Description: Vulnerabilidad de autenticación incorrecta en el componente principal HTTP de la plataforma Apache Camel. Este problema afecta a Apache Camel: desde la 4.8.0 antes de la 4.22.0. El servidor HTTP embebido de camel-main puede proteger sus puntos finales con autenticación JWT, configurado a través de authenticationEnabled junto con las propiedades del almacén de claves JWT. JWTAuthenticationConfigurer.buildJwtOptions devolvió nulo cuando ni jwtIssuer ni jwtAudience estaban configurados, y el llamador entonces omitió la llamada a JWTAuthOptions.setJWTOptions por completo, por lo que la instancia de Vert.x JWTAuth se construyó solo a partir del almacén de claves. El resultado fue que los tokens entrantes se verificaron solo por firma y caducidad: las reclamaciones iss y aud no se validaron en absoluto. Nada señaló esto -el servidor se inició normalmente y no informó ninguna advertencia- por lo que una implementación configurada de la manera documentada aplicó silenciosamente menos de lo que el operador creía haber habilitado, y la propia documentación del componente presentó la verificación de firma y caducidad como predeterminada con el emisor y la audiencia como un extra opcional. Tanto el servidor de aplicaciones como el servidor de gestión se vieron afectados, porque la omisión estaba en cada una de las dos rutas de configureAuthentication. Cualquier token no caducado firmado por cualquier clave en la que confía el almacén de claves configurado fue, por lo tanto, aceptado, independientemente de qué emisor lo acuñó o para qué audiencia estaba destinado. Hasta dónde llega eso depende del conjunto de confianza del almacén de claves: donde la clave de firma pertenece a un proveedor de identidad compartido o multi-inquilino, se acepta un token emitido legítimamente para una audiencia completamente diferente, mientras que un almacén de claves que contiene un firmante dedicado lo restringe a la reutilización de tokens acuñados para otros servicios dentro del mismo dominio de confianza. Las opciones jwtIssuer y jwtAudience no existían antes de la 4.21.0, por lo que en versiones anteriores no había una forma compatible de hacer cumplir estas reclamaciones en absoluto. Se recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. A partir de la 4.22.0, el servidor se niega a iniciar cuando un almacén de claves JWT está configurado pero ni jwtIssuer ni jwtAudience están establecidos, nombrando las propiedades involucradas, y una implementación que genuinamente solo desea la validación de firma y caducidad debe indicarlo explícitamente con la nueva opción jwtAllowMissingIssuerAndAudience, que por defecto es falso. Este comportamiento se corrige solo en la 4.22.0. Las versiones 4.14.9 y 4.18.4 no cambian el valor predeterminado: añaden las opciones jwtIssuer y jwtAudience para que los operadores en esas líneas de mantenimiento puedan hacer cumplir las reclamaciones mediante configuración, y una instalación que actualiza a la 4.14.9 o 4.18.4 sin establecer también al menos una de esas dos propiedades sigue aceptando cualquier token no caducado firmado por una clave de confianza. Por lo tanto, los usuarios de 4.14.x o 4.18.x deben actualizar a la 4.14.9 o 4.18.4 y luego establecer jwtIssuer, jwtAudience, o ambos. Las versiones desde la 4.8.0 hasta la 4.21.x inclusive no ofrecen ninguna forma de hacer cumplir estas reclamaciones y deben ser trasladadas a una versión que sí lo haga. Independientemente de la versión, restrinja el almacén de claves JWT al conjunto de confianza más pequeño posible -idealmente un firmante dedicado a este servicio en lugar de una clave de proveedor de identidad compartida- y donde una pasarela ya valida el emisor y la audiencia delante del servidor, asegúrese de que no pueda ser eludida. Notas: El ticket de JIRA: https://issues.apache.org/jira/browse/CAMEL-24281 se refiere a las diversas confirmaciones que resolvieron el problema, y tiene más detalles. La protección de fallo cerrado no pudo ser retroportada. Title: Apache Camel de Apache Software Foundation, Description: Vulnerabilidad de autenticación incorrecta en el componente principal HTTP de la plataforma Apache Camel. Este problema afecta a Apache Camel: desde la 4.8.0 antes de la 4.22.0. El servidor HTTP embebido de camel-main puede proteger sus puntos finales con autenticación JWT, configurado a través de authenticationEnabled junto con las propiedades del almacén de claves JWT. JWTAuthenticationConfigurer.buildJwtOptions devolvió nulo cuando ni jwtIssuer ni jwtAudience estaban configurados, y el llamador entonces omitió la llamada a JWTAuthOptions.setJWTOptions por completo, por lo que la instancia de Vert.x JWTAuth se construyó solo a partir del almacén de claves. El resultado fue que los tokens entrantes se verificaron solo por firma y caducidad: las reclamaciones iss y aud no se validaron en absoluto. Nada señaló esto -el servidor se inició normalmente y no informó ninguna advertencia- por lo que una implementación configurada de la manera documentada aplicó silenciosamente menos de lo que el operador creía haber habilitado, y la propia documentación del componente presentó la verificación de firma y caducidad como predeterminada con el emisor y la audiencia como un extra opcional. Tanto el servidor de aplicaciones como el servidor de gestión se vieron afectados, porque la omisión estaba en cada una de las dos rutas de configureAuthentication. Cualquier token no caducado firmado por cualquier clave en la que confía el almacén de claves configurado fue, por lo tanto, aceptado, independientemente de qué emisor lo acuñó o para qué audiencia estaba destinado. Hasta dónde llega eso depende del conjunto de confianza del almacén de claves: donde la clave de firma pertenece a un proveedor de identidad compartido o multi-inquilino, se acepta un token emitido legítimamente para una audiencia completamente diferente, mientras que un almacén de claves que contiene un firmante dedicado lo restringe a la reutilización de tokens acuñados para otros servicios dentro del mismo dominio de confianza. Las opciones jwtIssuer y jwtAudience no existían antes de la 4.21.0, por lo que en versiones anteriores no había una forma compatible de hacer cumplir estas reclamaciones en absoluto. Se recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. A partir de la 4.22.0, el servidor se niega a iniciar cuando un almacén de claves JWT está configurado pero ni jwtIssuer ni jwtAudience están establecidos, nombrando las propiedades involucradas, y una implementación que genuinamente solo desea la validación de firma y caducidad debe indicarlo explícitamente con la nueva opción jwtAllowMissingIssuerAndAudience, que por defecto es falso. Este comportamiento se corrige solo en la 4.22.0. Las versiones 4.14.9 y 4.18.4 no cambian el valor predeterminado: añaden las opciones jwtIssuer y jwtAudience para que los operadores en esas líneas de mantenimiento puedan hacer cumplir las reclamaciones mediante configuración, y una instalación que actualiza a la 4.14.9 o 4.18.4 sin establecer también al menos una de esas dos propiedades sigue aceptando cualquier token no caducado firmado por una clave de confianza. Por lo tanto, los usuarios de 4.14.x o 4.18.x deben actualizar a la 4.14.9 o 4.18.4 y luego establecer jwtIssuer, jwtAudience, o ambos. Las versiones desde la 4.8.0 hasta la 4.21.x inclusive no ofrecen ninguna forma de hacer cumplir estas reclamaciones y deben ser trasladadas a una versión que sí lo haga. Independientemente de la versión, restrinja el almacén de claves JWT al conjunto de confianza más pequeño posible -idealmente un firmante dedicado a este servicio en lugar de una clave de proveedor de identidad compartida- y donde una pasarela ya valida el emisor y la audiencia delante del servidor, asegúrese de que no pueda ser eludida. Notas: El ticket de JIRA: https://issues.apache.org/jira/browse/CAMEL-24281 se refiere a las diversas confirmaciones que resolvieron el problema, y tiene más detalles. La protección de fallo cerrado no pudo ser retroportada --TRUNCADO-- -
CVE Translated by [email protected]
Oct. 23, 2026
Action Type Old Value New Value Added Translation Title: Apache Camel de Apache Software Foundation, Description: Vulnerabilidad de autenticación incorrecta en el componente principal HTTP de la plataforma Apache Camel. Este problema afecta a Apache Camel: desde la 4.8.0 antes de la 4.22.0. El servidor HTTP embebido de camel-main puede proteger sus puntos finales con autenticación JWT, configurado a través de authenticationEnabled junto con las propiedades del almacén de claves JWT. JWTAuthenticationConfigurer.buildJwtOptions devolvió nulo cuando ni jwtIssuer ni jwtAudience estaban configurados, y el llamador entonces omitió la llamada a JWTAuthOptions.setJWTOptions por completo, por lo que la instancia de Vert.x JWTAuth se construyó solo a partir del almacén de claves. El resultado fue que los tokens entrantes se verificaron solo por firma y caducidad: las reclamaciones iss y aud no se validaron en absoluto. Nada señaló esto -el servidor se inició normalmente y no informó ninguna advertencia- por lo que una implementación configurada de la manera documentada aplicó silenciosamente menos de lo que el operador creía haber habilitado, y la propia documentación del componente presentó la verificación de firma y caducidad como predeterminada con el emisor y la audiencia como un extra opcional. Tanto el servidor de aplicaciones como el servidor de gestión se vieron afectados, porque la omisión estaba en cada una de las dos rutas de configureAuthentication. Cualquier token no caducado firmado por cualquier clave en la que confía el almacén de claves configurado fue, por lo tanto, aceptado, independientemente de qué emisor lo acuñó o para qué audiencia estaba destinado. Hasta dónde llega eso depende del conjunto de confianza del almacén de claves: donde la clave de firma pertenece a un proveedor de identidad compartido o multi-inquilino, se acepta un token emitido legítimamente para una audiencia completamente diferente, mientras que un almacén de claves que contiene un firmante dedicado lo restringe a la reutilización de tokens acuñados para otros servicios dentro del mismo dominio de confianza. Las opciones jwtIssuer y jwtAudience no existían antes de la 4.21.0, por lo que en versiones anteriores no había una forma compatible de hacer cumplir estas reclamaciones en absoluto. Se recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. A partir de la 4.22.0, el servidor se niega a iniciar cuando un almacén de claves JWT está configurado pero ni jwtIssuer ni jwtAudience están establecidos, nombrando las propiedades involucradas, y una implementación que genuinamente solo desea la validación de firma y caducidad debe indicarlo explícitamente con la nueva opción jwtAllowMissingIssuerAndAudience, que por defecto es falso. Este comportamiento se corrige solo en la 4.22.0. Las versiones 4.14.9 y 4.18.4 no cambian el valor predeterminado: añaden las opciones jwtIssuer y jwtAudience para que los operadores en esas líneas de mantenimiento puedan hacer cumplir las reclamaciones mediante configuración, y una instalación que actualiza a la 4.14.9 o 4.18.4 sin establecer también al menos una de esas dos propiedades sigue aceptando cualquier token no caducado firmado por una clave de confianza. Por lo tanto, los usuarios de 4.14.x o 4.18.x deben actualizar a la 4.14.9 o 4.18.4 y luego establecer jwtIssuer, jwtAudience, o ambos. Las versiones desde la 4.8.0 hasta la 4.21.x inclusive no ofrecen ninguna forma de hacer cumplir estas reclamaciones y deben ser trasladadas a una versión que sí lo haga. Independientemente de la versión, restrinja el almacén de claves JWT al conjunto de confianza más pequeño posible -idealmente un firmante dedicado a este servicio en lugar de una clave de proveedor de identidad compartida- y donde una pasarela ya valida el emisor y la audiencia delante del servidor, asegúrese de que no pueda ser eludida. Notas: El ticket de JIRA: https://issues.apache.org/jira/browse/CAMEL-24281 se refiere a las diversas confirmaciones que resolvieron el problema, y tiene más detalles. La protección de fallo cerrado no pudo ser retroportada. -
Initial Analysis by [email protected]
Aug. 28, 2026
Action Type Old Value New Value Added CPE Configuration OR *cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:* versions from (including) 4.8.0 up to (excluding) 4.22.0 Added Reference Type Apache Software Foundation: https://camel.apache.org/security/CVE-2026-66908.html Types: Mailing List, Vendor Advisory Added Reference Type CVE: http://www.openwall.com/lists/oss-security/2026/08/24/12 Types: Mailing List, Third Party Advisory -
CVE Modified by 134c704f-9b21-4f2e-91b3-4a467353bcc0
Aug. 25, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N Added SSVC {'id': 'CVE-2026-66908', 'role': 'CISA Coordinator', 'options': [{'exploitation': 'none'}, {'automatable': 'yes'}, {'technicalImpact': 'partial'}], 'version': '2.0.3', 'timestamp': '2026-08-25T19:38:05.072472Z'} -
CVE Modified by af854a3a-2127-422b-91ae-364da2661108
Aug. 24, 2026
Action Type Old Value New Value Added Reference http://www.openwall.com/lists/oss-security/2026/08/24/12 -
New CVE Received by [email protected]
Aug. 24, 2026
Action Type Old Value New Value Added Affected [{'vendor': 'Apache Software Foundation', 'product': 'Apache Camel', 'versions': [{'status': 'affected', 'version': '4.8.0', 'lessThan': '4.22.0', 'versionType': 'semver'}], 'packageURL': 'pkg:maven/org.apache.camel/camel-platform-http-main', 'packageName': 'org.apache.camel:camel-platform-http-main', 'collectionURL': 'https://repo.maven.apache.org/maven2', 'defaultStatus': 'unaffected'}] Added Description Improper Authentication vulnerability in Apache Camel Platform HTTP Main component. This issue affects Apache Camel: from 4.8.0 before 4.22.0. The camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legitimately issued for an entirely different audience is accepted, while a keystore holding a dedicated signer narrows it to reuse of tokens minted for other services within the same trust domain. The jwtIssuer and jwtAudience options did not exist before 4.21.0, so on earlier releases there was no supported way to have these claims enforced at all. Users are recommended to upgrade to version 4.22.0, which fixes the issue. From 4.22.0 the server refuses to start when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set, naming the properties involved, and a deployment that genuinely wants signature and expiry validation only must say so explicitly with the new jwtAllowMissingIssuerAndAudience option, which defaults to false. This behaviour is fixed only on 4.22.0. The 4.14.9 and 4.18.4 releases do not change the default: they add the jwtIssuer and jwtAudience options so that operators on those maintenance lines can enforce the claims by configuration, and an installation that upgrades to 4.14.9 or 4.18.4 without also setting at least one of those two properties is still accepting any unexpired token signed by a trusted key. Users on 4.14.x or 4.18.x should therefore upgrade to 4.14.9 or 4.18.4 and then set jwtIssuer, jwtAudience, or both. Releases from 4.8.0 up to and including 4.21.x offer no way to enforce these claims and should be moved to a version that does. Independently of version, restrict the JWT keystore to the smallest possible trust set - ideally a signer dedicated to this service rather than a shared identity-provider key - and where a gateway already validates issuer and audience in front of the server, ensure it cannot be bypassed. Notes: The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24281 refers to the various commits that resolved the issue, and has more details. The fail-closed guard could not be backported. The jwtIssuer and jwtAudience options were themselves only introduced in 4.21.0 by CAMEL-23525, so on camel-4.18.x and camel-4.14.x there was nothing an operator could set to satisfy the requirement and the guard would have broken every JWT deployment on those branches with no remedy available. Added CWE CWE-287 Added Reference https://camel.apache.org/security/CVE-2026-66908.html