An OAuth2 client token cache in Apache Camel’s HTTP component uses a global cache whose key omitted several fields that determine the token’s authorisation, namely the requested scope, the resource indicator and the token endpoint. As a result, two endpoints that differ only in those fields could receive the same cached token. The consequence is that a request may carry a token authorising a broader scope than the endpoint was intended for, or a token may be presented to a resource that did not issue it. The type of weakness is a use of a cache containing sensitive information.

Vulnerable Apache Camel versions start at 4.0.0 and extend up to before 4.18.5, 4.19.0 through 4.22.1. The issue exists in the Apache Camel HTTP component and affects any deployment that configures multiple OAuth2 endpoints differing in scope, resource indicator or token endpoint within a single JVM. Users on the 4.18.x LTS line should install 4.18.5, users on the 4.22.x LTS line should install 4.22.1, and all other affected releases should upgrade to 4.23.0 or later.

The CVSS base score of 4.8 indicates low severity, primarily because exploitation requires a deployment that hosts multiple OAuth2 endpoints with differing scopes, resources or token issuers. The EPSS score is not available, and the vulnerability is not listed in the CISA KEV catalog. A likely attack vector involves re‑using the same JVM process for distinct OAuth2 endpoints; an attacker could, by configuring or influencing the endpoints, cause a token with broader authorisation to be cached and subsequently used. Because the issue derives from improper cache key construction (CWE‑524), the vulnerability is limited in scope and deployment complexity but remains actionable for systems with multi‑endpoint OAuth2 configurations.