The Camel‑OAuth component caches bearer tokens it obtains via the client credentials grant in a static, JVM‑wide store keyed only on the token endpoint and client ID. When two OAuth profiles share a token endpoint and client ID but request different scopes or use different client secrets, the first profile to resolve a token populates the cache and the second profile is subsequently served that same token. This can result in an outbound request carrying a token that grants broader authority than the calling profile was intended to use, or even a token for a different service if the audience is derived from the requested scope. The flaw is a use‑of‑cache‑containing‑sensitive‑information vulnerability, allowing a component or application to use an unauthorized token within its own JVM process.

Apache Camel 4.19.0 through 4.22.1 (inclusive). Versions 4.18.x and earlier are not affected. The affected component is the Oauth module used by various Camel integrations such as camel‑openai, camel‑langchain4j‑agent, camel‑huggingface, and others. Deployments that define multiple OAuth profiles sharing the same token endpoint and client ID while differing in scope or client secret are vulnerable.

The CVSS base score of 4.8 indicates moderate severity. EPSS data is not available, and the vulnerability is not listed in CISA KEV, suggesting a lower likelihood of widespread exploitation, but the attack vector requires a misconfigured deployment with multiple profiles sharing credentials. If such a configuration exists, an attacker within the same JVM process could obtain a token with a wider scope, enabling unauthorized access to protected resources.