CVE-2026-66908: CWE-287 Improper Authentication in Apache Software Foundation Apache Camel

Apache Camel's embedded HTTP server component improperly authenticates JWT tokens by not validating the issuer and audience claims unless these are explicitly configured via jwtIssuer and jwtAudience options introduced in version 4.21.0. Prior to 4.22.0, if these options are not set, the server only checks token signature and expiry, accepting any token signed by a trusted key regardless of issuer or intended audience. This flaw affects versions from 4.8.0 before 4.22.0. Version 4.22.0 fixes the issue by refusing to start if a JWT keystore is configured without jwtIssuer or jwtAudience set, unless the new jwtAllowMissingIssuerAndAudience option is explicitly enabled. Maintenance releases 4.14.9 and 4.18.4 add the options but do not enforce them by default. The vulnerability allows tokens issued for other services or audiences within the trust domain to be accepted, potentially leading to unauthorized access. Operators are advised to restrict the JWT keystore to the smallest trust set possible and ensure front-end gateways validate issuer and audience claims to prevent bypass.

The vulnerability allows acceptance of any unexpired JWT token signed by a key trusted by the configured keystore, regardless of the token's issuer or intended audience. This can lead to unauthorized access to the affected Apache Camel HTTP endpoints if tokens issued for other services or audiences within the same trust domain are presented. The impact depends on the trust scope of the keystore's signing keys. There is no indication of confidentiality or availability impact beyond improper authentication. No known exploits in the wild have been reported.

Users should upgrade to Apache Camel version 4.22.0 or later, which enforces validation of issuer and audience claims or requires explicit configuration to allow missing claims. For users on maintenance branches 4.14.x or 4.18.x, upgrade to versions 4.14.9 or 4.18.4 and configure jwtIssuer, jwtAudience, or both to enforce claim validation. Independently of version, restrict the JWT keystore to the smallest possible trust set, ideally a dedicated signer for the service, and ensure any front-end gateway performing issuer and audience validation cannot be bypassed. Note that versions prior to 4.21.0 do not support enforcing these claims and should be upgraded to a version that does.