Apache Camel CVE-2026-85317

Requires a single JVM running Apache Camel (4.0.0-4.18.4 or 4.19.0-4.22.0) with at least two camel-http OAuth2 client-credentials endpoints that share the same request URI, oauth2ClientId and oauth2ClientSecret but differ in oauth2Scope, oauth2ResourceIndicator, or oauth2TokenEndpoint, with token caching enabled (oauth2CacheTokens=true). Because the token cache is a static map shared across every configurer instance and CamelContext in the JVM, these endpoints collide on the incomplete cache key. Limiting factors that make this non-default and low-risk: deployments with only one OAuth2 endpoint, or endpoints that also differ in URI or credentials, are unaffected; the outcome also depends on which route populates the cache first; and there is no external attacker vector - the authority confusion occurs between the operator's own routes.

This is a genuine-but-low-priority issue, and the signals are internally consistent. The vendor-supplied CVSS of 4.8 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) reflects limited confidentiality and integrity impact with high attack complexity, and the description explicitly states severity was assessed low because exploitation depends on an uncommon deployment shape. No EPSS score, no CISA KEV listing, and no public POC were provided - consistent with no public exploit identified at time of analysis. There is no SSVC decision data supplied. Importantly, the PR:N / AV:N framing is misleading for this flaw: this is not a classic remote attacker scenario but an unintentional in-JVM token-confusion bug (CWE-524) where a route is served a cached OAuth2 token minted for a different scope, resource, or authorization server. There is no external attacker action required and arguably no attacker at all - the 'exploitation' is an operator's own routes crossing authority boundaries. The network vector applies only in the sense that an over-privileged token may be presented to an upstream resource server. Net: real correctness/security defect worth patching on normal maintenance cadence, but not an urgent, widely-exploitable threat.

An organization runs Apache Camel with two camel-http routes using the same client credentials and request URI but different oauth2Scope (e.g. 'read' vs 'read+write') and token caching enabled, in the same JVM. The route needing only 'read' runs first and caches its token; the second route - or on different timing, the first - is then handed the other route's cached token, so a narrow-scope endpoint receives broad-scope authority or a token meant for a different resource/authorization server. No public exploit code exists, and triggering it requires the specific multi-endpoint configuration plus the ordering in which routes populate the shared static cache.