Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain token from unauthorized issuer
-
DeliveryPresent bearer token to Camel route
-
ExploitIntrospection returns active without iss claim
-
ExecutionIssuer validation silently skipped
-
ImpactAuthenticate as rejected caller
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 | Requires ALL of the following non-default conditions: (1) the camel-keycloak security policy configured to use token introspection (isUseTokenIntrospection), (2) the opt-in validateIssuer flag explicitly enabled, (3) the introspection endpoint omitting the 'iss' claim from its active response (RFC 7662 makes iss optional - reachable when the endpoint is a broker, gateway, or minimal implementation rather than the issuing realm), and (4) that endpoint accepting/serving tokens from more than one issuer. The attacker must possess a token minted by an issuer other than the configured one that the endpoint will mark active. Limiting factors: the standard Keycloak realm introspection endpoint returns iss and serves a single issuer, so default deployments are NOT affected; validateIssuer is off by default. These constraints, not raw network reachability, are what cap real-world risk. |
| Impact | This is a genuinely low-priority issue despite being an authentication flaw. The input CVSS is 4.8 (Medium) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, and all signals point the same direction: AC:H reflects the substantial non-default preconditions, and C:L/I:L/A:N reflect limited impact. No EPSS score, KEV listing, or public POC was provided - exploitation status is 'no public exploit identified at time of analysis.' There is no signal conflict to resolve; rather, the data is consistent and uniformly low-urgency. The vulnerability is only reachable in a specific deployment topology (introspection endpoint that omits the RFC 7662 'iss' claim AND brokers tokens from more than one issuer, with the opt-in validateIssuer check enabled), which the vendor explicitly notes 'is not the default Keycloak arrangement.' Note that while PR:N technically means unauthenticated, the attacker must still present a token the introspection endpoint marks active - so 'unauthenticated' here means 'using a token from an issuer other than the configured one,' not fully anonymous access. Treat this as patch-on-normal-cycle unless you operate the exact multi-issuer broker configuration described. |
| Exploit ScenarioDerived | In a deployment where Camel's Keycloak security uses token introspection with validateIssuer enabled, and the introspection endpoint is a broker/gateway that omits the iss claim and accepts tokens from multiple issuers, an attacker obtains a valid token minted by an issuer other than the configured one. The introspection response returns active=true with no issuer, the issuer check is silently skipped, and the attacker's foreign-issuer token is accepted, bypassing the intended issuer restriction. No public exploit code was identified; the fix and tests are visible in the referenced GitHub PRs. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Apache Camel's camel-keycloak security processor can accept a token minted by an issuer other than the configured one when token introspection is in use, the opt-in issuer validation is enabled, and the introspection endpoint returns an active response that omits the 'iss' claim - the check was skipped instead of failing. The flaw affects Apache Camel releases from 4.15.0 up to but not including 4.18.5, and from 4.19.0 up to but not including 4.22.1, specifically deployments using the camel-keycloak component with token introspection. Exploitation is unauthenticated per the CVSS vector (PR:N) but demands a non-default chain - introspection enabled, validateIssuer explicitly turned on, and a broker/gateway/minimal introspection endpoint that omits iss and serves multiple issuers - which caps the score at 4.8; no public exploit identified at time of analysis, and vendor-released patches exist in 4.23.0, 4.18.5 and 4.22.1.
RemediationAI
Vendor-released patch: upgrade to Apache Camel 4.23.0; users on the 4.18.x LTS stream should move to 4.18.5 and users on the 4.22.x LTS stream to 4.22.1, which treat an absent iss claim as a validation failure (fix commits referenced in https://github.com/apache/camel/pull/25827, https://github.com/apache/camel/pull/25858 and https://github.com/apache/camel/pull/25859, advisory at https://camel.apache.org/security/CVE-2026-85301.html). For deployments that cannot upgrade immediately, configure the introspection endpoint so it always returns the iss claim and serves exactly one issuer - for Keycloak this means pointing camel-keycloak at the issuing realm's own introspection endpoint rather than a broker or gateway, at the cost of losing multi-issuer brokering; verify the endpoint's response actually contains iss for active tokens before relying on this. Turning off validateIssuer is not a mitigation: it removes issuer checking entirely rather than restoring it, so it should only be used as a deliberate acceptance of the risk in environments where the introspection endpoint is already restricted to a single trusted issuer and reachable only by the Camel application.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The issue is an improper authentication weakness (CWE-287) in the KeycloakSecurityProcessor of the camel-keycloak component, which validates bearer tokens either by local verification or by RFC 7662 token introspection. In the introspection path, the private method validateIssuerFromIntrospection() compared the configured expected issuer (derived from serverUrl plus '/realms/' plus realm) against the 'iss' claim of the introspection response, but only when that claim was actually present; when 'iss' was absent the code logged a warning and returned, effectively treating a missing claim as a pass. RFC 7662 makes 'iss' optional in an introspection response, so any endpoint that is a broker, a gateway, or a minimal implementation rather than the issuing realm can return an active token without an issuer, and the operator's explicit opt-in to issuer validation is silently bypassed. The fix in KeycloakSecurityProcessor.java replaces the warning-and-return with an error log and a thrown CamelAuthorizationException ('Token issuer missing: expected ... but the introspection result carries no issuer'), so an absent iss is now a validation failure; the accompanying tests (testActiveIntrospectionWithoutIssuerClaimRejected and testActiveIntrospectionWithTheExpectedIssuerAccepted) confirm the route body is never reached for an issuer-less token. Audience validation already rejected a missing 'aud' claim, so the patch simply makes the two validation paths consistent; the high attack complexity (AC:H) in the CVSS vector reflects the environmental preconditions rather than any cryptographic hardness.
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:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Network-facing introspection (AV:N), but the multi-issuer/no-iss broker configuration plus opt-in validateIssuer makes it AC:H; attacker needs only a foreign-issuer token (PR:N) yielding limited auth bypass (C:L/I:L).
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
DescriptionCVE.org
Improper Authentication vulnerability in Apache Camel Keycloak component.
This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1.
The security processor validated the issuer of an introspected token only when the introspection response actually carried an iss claim. When the claim was absent the check was skipped rather than treated as a failure, so a token that the configured issuer did not mint could be accepted provided the introspection endpoint answered without naming an issuer. Reaching this requires an introspection endpoint that omits iss and accepts tokens from more than one issuer, which is not the default Keycloak arrangement, hence the low severity; where that arrangement exists the consequence is that the deployment authenticates a caller it should have rejected.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. An absent iss claim is now treated as a validation failure rather than as a reason to skip the check. For deployments that cannot upgrade immediately, ensure the introspection endpoint returns the iss claim, and that it serves exactly one issuer.
Threat Intelligence Overview
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
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.1
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)
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to rem
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticate
EUVD-2026-104198
GHSA-73pw-28wr-vh7r
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB