Live › vulnerability › CVE-2026-85317
Go to dashboardThe OAuth2 client token cache in Apache Camel's HTTP component uses a key that omits scope, resource indicator and token endpoint. Two endpoints differing only in those fields can receive a token minted for the other, giving a request broader authority or sending a token to a party it was not issued for.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only deployments of Apache Camel 4.0.0 to before 4.18.5, or 4.19.0 to before 4.22.1, that use the HTTP component's OAuth2 client and configure more than one OAuth2 endpoint differing in scope, resource indicator or token endpoint. A single-endpoint setup is not exposed in the same way. Teams with one OAuth2 endpoint per JVM can skip it.
No product ranges from the sources yet.
mvn dependency:list | grep camel-http, and compare it to the fixed versions.4.23.0.4.18.5.4.22.1.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-85317")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.