EUVD-2026-64959
GHSA-fpm2-m4qq-wghr
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify exposed Apache Camel HTTP endpoint
-
DeliveryObtain valid JWT from shared identity provider
-
ExploitPresent cross-service JWT to Camel endpoint
-
ExecutionSignature and expiry validated, iss/aud silently skipped
-
ImpactUnauthorized access granted to protected API
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK
2 techniques across 2 tactics: Defense Evasion, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires three conditions to hold simultaneously. First, the target Apache Camel deployment must be running a version between 4.8.0 and 4.21.x inclusive with the camel-platform-http-main embedded HTTP server and JWT authentication enabled via authenticationEnabled=true plus JWT keystore properties. Second, neither jwtIssuer nor jwtAudience must be configured - this was the silent default for all affected versions, as these properties did not exist before 4.21.0. Third, and most critically, the JWT keystore must trust a signing key also used by another service or identity provider (shared IdP scenario); in a single-service dedicated-key deployment, an attacker would additionally need to possess the private signing key itself. What limits exploitation: if a dedicated per-service signer is used, cross-service token reuse is not possible; if jwtIssuer or jwtAudience is set on versions 4.14.9 or 4.18.4+, the bypass is closed; if the Camel HTTP endpoints are not network-exposed or are behind an authenticating gateway that cannot be bypassed, attack surface is reduced. The CVSS vector PR:N reflects that no authentication to the Camel service itself is required - only possession of any valid token trusted by the keystore. |
| Impact | The vendor-assigned CVSS score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) warrants scrutiny: the integrity-only impact is accurate, but the AC:L and PR:N ratings assume the worst-case deployment where a shared or multi-tenant identity provider key is in the keystore, making any legitimate credential holder from that IdP a potential attacker. In deployments with a dedicated per-service signing key, the practical attack surface is substantially narrower - exploitation would require compromising the private key itself, making the real-world AC much higher than the vector suggests. The EPSS score of 0.32% (24th percentile) is consistent with a configuration-dependent flaw that requires specific deployment conditions rather than a broadly exploitable network service. There is no CISA KEV listing and no public exploit code identified, so urgency is elevated primarily for organizations using shared IdP keystores. The most dangerous scenario - a multi-tenant environment where employees hold valid tokens for other internal services - is common enough in large enterprises that this should not be dismissed. The silent failure mode (no startup warning, no runtime error) is a significant aggravating factor: operators who believed they had issuer and audience enforcement did not, and cannot determine this from logs alone. Patch priority should be high for any deployment relying on a shared identity provider keystore and moderate elsewhere. |
| Exploit ScenarioDerived | An attacker who has obtained a valid, unexpired JWT token issued by a shared enterprise identity provider - such as a token for an internal HR application - presents it to the Apache Camel Platform HTTP endpoint of a separate service sharing the same IdP keystore. The Camel server validates the signature and expiry, both of which pass, but silently skips iss and aud validation, accepting the cross-service token as legitimate. The attacker gains unauthorized access to the Camel HTTP API as if they were an authorized caller for that specific service. No public exploit code exists at time of analysis, so this scenario requires an attacker with an existing valid token in the same IdP trust domain. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 25, 2026
JWT claim validation in Apache Camel's Platform HTTP Main component silently fails to enforce issuer and audience constraints when neither jwtIssuer nor jwtAudience is configured, causing the embedded Vert.x HTTP server to accept any unexpired token signed by any key in the trusted keystore. Affected are Apache Camel versions 4.8.0 through 4.21.x across both the application server and management server paths. An attacker who possesses a valid JWT from any identity provider trusted by the configured keystore - such as a token legitimately issued for a different service in a shared IdP environment - can authenticate to the Camel HTTP endpoints without holding credentials intended for that service. No public exploit has been identified at time of analysis, and CISA KEV listing is absent.
RemediationAI
The definitive fix is upgrading to Apache Camel 4.22.0, which introduces fail-closed behavior: the server refuses to start when a JWT keystore is configured without at least one of jwtIssuer or jwtAudience set. Deployments that intentionally want only signature and expiry validation must explicitly opt in by setting jwtAllowMissingIssuerAndAudience=true, reversing the insecure-by-default behavior of prior releases. Operators on the 4.14.x maintenance line should upgrade to 4.14.9 and then explicitly configure jwtIssuer, jwtAudience, or both - the 4.14.9 release adds these properties but does not change the default, so an upgrade without also setting at least one of them remains vulnerable. The same applies to 4.18.x: upgrade to 4.18.4 and configure the claim properties. Regardless of version, the vendor strongly recommends restricting the JWT keystore to the smallest possible trust set - ideally a signing key dedicated to this specific service rather than a shared identity provider key. Where a gateway upstream already validates iss and aud, verify that the gateway cannot be bypassed to reach the Camel endpoint directly. All advisory details are at https://camel.apache.org/security/CVE-2026-66908.html.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache Camel's camel-platform-http-main component provides an embedded HTTP server (built on Vert.x) that supports JWT-based endpoint protection. The root cause is CWE-287 (Improper Authentication): JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was specified, causing the caller in configureAuthentication to skip the JWTAuthOptions.setJWTOptions call entirely. The resulting Vert.x JWTAuth instance was initialized from the keystore alone, validating only token signature and expiry - the standard JWT iss and aud claims were never evaluated. Because the configureAuthentication code path exists in two locations (one for the application server, one for the management server), both surfaces were affected identically. Critically, the jwtIssuer and jwtAudience configuration properties did not exist prior to version 4.21.0, meaning there was no supported mechanism to enforce these claims on earlier maintenance branches. The affected product is identified by CPE cpe:2.3:a:apache_software_foundation:apache_camel:*:*:*:*:*:*:*:* covering versions 4.8.0 up to but not including 4.22.0.
Know when Apache Camel gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
AC:H because exploitation requires a shared IdP keystore (non-default hardened setup); PR:L because attacker must hold a valid JWT from a trusted issuer.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
4DescriptionCVE.org
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.
Blast Radius
ecosystem impact- 8 maven packages depend on org.apache.camel:camel-platform-http-main (2 direct, 6 indirect)
Ecosystem-wide dependent count for version 4.8.0.
Executive ViewAI
Apache Camel versions 4.8.0-4.21.x contain a JWT validation bypass in the Platform HTTP Main component affecting both application and management servers. An attacker holding a valid JWT from any trusted identity provider can authenticate to Camel endpoints intended for different services, effectively bypassing service-level access controls. Organizations using multi-service deployments with shared identity providers face elevated risk of unauthorized cross-service access and potential data exposure.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Apache Camel
View allRemote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0)
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoS
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket messag
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remot
Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy im
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an a
Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize)
Cypher injection in Apache Camel's camel-neo4j producer allows attackers who control JSON key names in the CamelNeo4jMat
Remote code execution in the Apache Camel camel-hazelcast component allows an attacker who can join or reach the Hazelca
Remote code execution in Apache Camel's camel-vertx-http component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0) arises when a p
Blind out-of-band data exfiltration in Apache Camel 4.14.0-4.20.x arises because the default ObjectInputFilter pattern b
Exploit-DB