CVE-2026-66908: Apache Camel Platform HTTP Auth Bypass

CVE-2026-66908 Overview

CVE-2026-66908 is an improper authentication vulnerability [CWE-287] affecting the Apache Camel Platform HTTP Main component. The flaw exists in the camel-main embedded HTTP server, which supports JWT authentication configured through authenticationEnabled and the JWT keystore properties. Affected releases build the Vert.x JWTAuth instance from the keystore alone when neither jwtIssuer nor jwtAudience is configured. Inbound tokens are checked only for signature and expiry, and the iss and aud claims are never validated. The issue affects Apache Camel from 4.8.0 before 4.22.0 and impacts both the application server and the management server.

Critical Impact
Any unexpired token signed by a key trusted by the configured JWT keystore is accepted, regardless of issuer or intended audience, silently weakening authentication on affected deployments.

Affected Products

Apache Camel 4.8.0 through 4.21.x (camel-main HTTP component)
Apache Camel 4.14.x prior to 4.14.9
Apache Camel 4.18.x prior to 4.18.4

Discovery Timeline

2026-08-24 - CVE-2026-66908 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-66908

Vulnerability Analysis

The camel-main embedded HTTP server can enforce JWT authentication on its endpoints when authenticationEnabled and the JWT keystore properties are configured. The intended flow builds a JWTAuthOptions structure that combines keystore configuration with issuer and audience claims. Operators reading the component documentation are led to treat issuer and audience validation as an optional hardening step layered on top of signature and expiry checking.

In practice, the server accepts any unexpired token signed by a key present in the trusted keystore. The blast radius depends on the keystore's trust set. A keystore that trusts a shared or multi-tenant identity provider accepts tokens minted for entirely different audiences. A keystore holding a dedicated signer limits abuse to token reuse across services within the same trust domain. The server logs no warning, so operators cannot detect the weakened posture from runtime signals.

Root Cause

The method JWTAuthenticationConfigurer.buildJwtOptions returns null when neither jwtIssuer nor jwtAudience is configured. The caller then skips the JWTAuthOptions.setJWTOptions call entirely. As a result, the Vert.x JWTAuth instance is constructed from keystore material only, and no iss or aud validation is registered. The defect exists in both configureAuthentication paths, so the application server and management server are affected equally. On releases prior to 4.21.0, the jwtIssuer and jwtAudience options did not exist, meaning claim enforcement was not achievable by configuration.

Attack Vector

An attacker who obtains a valid, unexpired JWT signed by any key the target keystore trusts can authenticate to the camel-main HTTP endpoints. In multi-tenant identity provider deployments, tokens minted for unrelated audiences satisfy the check. Where a gateway performs issuer and audience checks in front of Camel, an attacker who bypasses the gateway reaches an unprotected server.

No verified public exploit code is available. See the Apache Camel CVE-2026-66908 Advisory and the OpenWall OSS-Security Discussion for vendor detail.

Detection Methods for CVE-2026-66908

Indicators of Compromise

Successful authentications to camel-main HTTP endpoints using JWTs whose iss claim does not match the expected identity provider for the deployment.
Successful authentications carrying aud claims that name services other than the Camel application or management server.
Reuse of tokens across services that share a signing key or identity provider trust anchor.

Detection Strategies

Inventory Camel deployments running versions 4.8.0 through 4.21.x and confirm whether authenticationEnabled is set with a JWT keystore.
Inspect access logs for the application server and management server ports and correlate authenticated requests against expected iss and aud values decoded from the presented tokens.
Compare the keystore trust set against the population of tokens observed in production to identify unexpected signers or audiences being accepted.

Monitoring Recommendations

Enable request-level logging that captures the decoded iss and aud claims for JWT-authenticated requests to Camel HTTP endpoints.
Alert on any request where the decoded aud does not match a defined allow list for the Camel service.
Monitor upstream gateway configurations for changes that could allow requests to reach Camel directly, bypassing gateway-side claim enforcement.

How to Mitigate CVE-2026-66908

Immediate Actions Required

Upgrade to Apache Camel 4.22.0, which fails closed when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set.
On the 4.14.x line, upgrade to 4.14.9 and explicitly set jwtIssuer, jwtAudience, or both. On the 4.18.x line, upgrade to 4.18.4 and configure the same properties.
Move deployments on 4.8.0 through 4.21.x that cannot reach 4.22.0 to a version that supports claim enforcement, since earlier releases offer no configuration option.
Restrict the JWT keystore to the smallest possible trust set, ideally a dedicated signer rather than a shared identity provider key.

Patch Information

Apache Camel 4.22.0 introduces a fail-closed guard: the server refuses to start when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set, and it names the properties involved. Deployments that intentionally rely on signature and expiry checking alone must set the new jwtAllowMissingIssuerAndAudience option, which defaults to false. Releases 4.14.9 and 4.18.4 do not change the default; they add the jwtIssuer and jwtAudience options so operators on those maintenance lines can enforce the claims by configuration. Refer to the Apache Camel CVE-2026-66908 Advisory and JIRA ticket CAMEL-24281 for commit details.

Workarounds

Place a gateway in front of the Camel HTTP endpoints that validates the iss and aud claims, and ensure the gateway cannot be bypassed by direct network access to the server.
Reduce the JWT keystore trust set to a dedicated signer for this service so tokens minted for other audiences cannot be accepted.
Where feasible, terminate JWT authentication upstream and enforce mutual TLS between the gateway and the Camel server.

bash

# Apache Camel 4.22.0 configuration example enforcing issuer and audience claims
camel.main.authentication-enabled=true
camel.main.jwt-keystore-path=/etc/camel/jwt-keystore.jks
camel.main.jwt-keystore-password=${JWT_KEYSTORE_PASSWORD}
camel.main.jwt-issuer=https://idp.example.com/
camel.main.jwt-audience=camel-main-app
# Leave jwtAllowMissingIssuerAndAudience at its default (false)