Apache Camel EUVD-2026-109957

Requires a single JVM deployment that defines more than one Camel OAuth profile (via components such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat, the IBM watsonx components, or direct use of the OAuthClientAuthenticationFactory SPI) where the profiles share the same token endpoint and client ID but differ in requested scope or client secret, with token caching left at its default-enabled state. Limiting factors: the vulnerable configuration is set by the trusted deployment, so no untrusted attacker input is involved; both profiles' token requests must overlap while a cached token is still valid; the benefiting party is the service that receives the mis-scoped token, and impact is bounded to that token's scope. Affects org.apache.camel:camel-oauth 4.19.0 before 4.22.2; 4.18.x and earlier never shipped the resolver and are unaffected.

Signals point consistently to a lower-tier, conditional issue rather than an urgent one. The vendor CVSS 3.1 score is 4.8 (medium) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N: although network-reachable and nominally unauthenticated, the high attack complexity reflects that the flaw only manifests in a specific multi-profile deployment, and impact is limited to low confidentiality and low integrity with no availability effect. No EPSS score is present in the supplied data, so exploitation probability cannot be quantified. The vuln.today decision label is 'awaiting_data', and there is no CISA KEV listing and no public exploit identified at time of analysis - the GitHub pull-request references (26681, 27779) and the Jira ticket are the vendor's remediation, not proof-of-concept exploit code. The threat model is also atypical: the description states that profiles are configured by the trusted deployment and no untrusted input reaches the cache, so the party that benefits is an unintended downstream service that receives a token issued for a different scope or secret and could replay it within that scope. Taken together these signals indicate a real but narrow correctness/least-privilege weakness, not a high-real-risk mass-exploitation candidate; EPSS being absent (not low) should be noted rather than assumed benign.

An integration app configures two Camel OAuth profiles (for example feeding camel-openai and an IBM watsonx component) that point at the same token endpoint and client ID but request different scopes. With default token caching on, whichever profile resolves first populates the shared static cache, and the second profile's outbound call is sent carrying the first profile's token - potentially a broader scope or a token whose audience targets a different service. No public exploit code is identified; realizing the cross-scope token requires the specific shared-client, differing-scope/secret configuration (reflected by CVSS AC:H).