CVE-2026-85317: Apache Camel: Camel-HTTP OAuth2 Token Confusion via an Under-Keyed JVM-Global Token Cache
Use of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The OAuth2 client token cache is global to the JVM, and its key omitted several of the fields that determine what a token actually authorises: the requested scope, the resource indicator, and the token endpoint the token was obtained from. Two endpoints differing only in those fields therefore shared a cache entry, and an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server. The consequence is a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for. Reaching it requires a deployment that configures more than one OAuth2 endpoint differing in exactly those fields, which is why the severity is assessed low.
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. The cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them. For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Camelto a version that resolves this vulnerability.Fixed in 4.23.0 - Upgrade
Upgrade
Apache Camel 4.18.x LTSto a version that resolves this vulnerability.Fixed in 4.18.5 - Upgrade
Upgrade
Apache Camel 4.22.x LTSto a version that resolves this vulnerability.Fixed in 4.22.1 - Compensating control
For deployments that cannot upgrade immediately, run endpoints differing in scope, resource indicator, or token endpoint in separate JVMs so they do not share the OAuth2 client token cache.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Exposure requires a single JVM deployment with more than one OAuth2 endpoint whose configurations differ only by requested scope, resource indicator, or token endpoint. Endpoints that do not create this specific cache-key collision are not described as affected in the same way.
What could happen if the cache entries collide?
An endpoint can receive a token obtained for a different scope, resource, or authorization server. This can cause a request to carry broader authority than configured or present a token to a party for which it was not issued.
Does exploitation require authentication or user interaction?
The supplied vector indicates no privileges and no user interaction are required, but exploitation has high attack complexity. The necessary precondition is the affected multi-endpoint OAuth2 configuration in the same JVM.
What should teams do if they are running an affected release?
Upgrade to Apache Camel 4.23.0. For the LTS streams identified, upgrade 4.18.x to 4.18.5 or 4.22.x to 4.22.1; the fix adds all token-shaping fields to the cache key.
How can I determine whether my configuration is at risk before upgrading?
Review OAuth2 endpoints configured in the same JVM and identify endpoint pairs that are otherwise shared but differ in scope, resource indicator, or token endpoint. Such pairs could share the prior global token-cache entry.