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
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 legitimat
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-66908
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 19:43 UTC · Revision 1
Source evidence
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
core-osv · Original sourcePublished 24 Aug 2026, 16:14 UTC
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 legitimat
osv:CVE-2026-66908
Complete source record
{
"id": "9d553c9370894aee60311e453064eca496493692a704652d2f02df149dd477f6",
"url": "https://osv.dev/vulnerability/CVE-2026-66908",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "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 ",
"summary": "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 legitimat",
"evidence": "osv:CVE-2026-66908",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-66908",
"aliases": [
"CVE-2026-66908",
"GHSA-fpm2-m4qq-wghr"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/apache/camel",
"type": "GIT",
"events": [
{
"introduced": "071f95d5647b8597ca1c4ae6201b3442f87d120d"
},
{
"fixed": "1a54683f4becad3b32df42507e709526d8563f35"
}
],
"database_specific": {
"extracted_events": [
{
"cpe": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "4.8.0"
},
{
"fixed": "4.22.0"
}
],
"source": "CPE_RANGE"
}
]
}
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-66908.json"
}
}
],
"modified": "2026-10-28T02:30:31.789308137Z",
"provider": "osv",
"references": [
"https://repo.maven.apache.org/maven2",
"https://camel.apache.org/security/CVE-2026-66908.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/66xxx/CVE-2026-66908.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-66908"
],
"provider_metadata": {
"cwe_ids": [
"CWE-287"
],
"cna_assigner": "apache",
"unresolved_ranges": [
{
"extracted_events": [
{
"range": [
{
"introduced": "4.8.0"
},
{
"fixed": "4.22.0"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
}
]
}
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/66xxx/CVE-2026-66908.json"
}
},
"related_cves": [
{
"value": "CVE-2026-66908",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 498794,
"published_at": "2026-08-24T16:14:18.202+00:00"
}