Apache Camel EUVD-2026-104209

Exploitation requires that the deployment actually uses the Apache Camel OAuth component's authorization code callback (OAuthCodeFlowCallback / OAuthCodeFlowProcessor) to authenticate users - this is an optional component, so deployments not using camel-oauth for OAuth login are unaffected. The attacker needs no authentication or special privileges, but DOES require victim interaction: the victim must follow an attacker-supplied link or otherwise present the attacker's authorization code to the callback (UI:R). The vulnerable condition is the default behavior of affected versions, which issued no session-bound state parameter and performed no state validation at the callback; there is no configuration toggle required to be vulnerable. Limiting factors: affected versions are 4.11.0 before 4.18.5 and 4.19.0 before 4.22.1 only, exploitation depends on social-engineering the victim, and impact is confined to the OAuth login identity rather than the host.

This is a medium-severity CSRF/login-CSRF issue in the Apache Camel OAuth component, and the signals are internally consistent rather than conflicting. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, 6.1) matches the description: network-reachable, no attacker privileges, but requiring victim interaction (following/submitting through an attacker-prepared flow), with a scope change reflecting the open-redirect-from-trusted-origin and the cross-session identity binding. No EPSS score, KEV listing, or public POC was provided in the input, so exploitation likelihood cannot be quantified; the absence of these is not evidence of safety but does argue against widespread automated exploitation. The realistic ceiling is limited: this is not RCE and grants no direct confidentiality/integrity over the host - the impact is that a victim is silently signed into an attacker-controlled identity, so subsequently entered data lands in the attacker's account, plus an open redirect usable for phishing. That makes it a real priority for deployments actually using the camel-oauth code-flow callback for user authentication, but a low-urgency or non-applicable issue for the many Camel deployments that do not use this component at all. Net: a genuine but moderate, interaction-dependent and configuration-dependent risk rather than a drop-everything critical.

An attacker initiates an OAuth authorization code flow against the identity provider in their own browser, obtains a valid authorization code, and crafts a link embedding that code into the victim-facing Camel callback URL. When a victim follows the attacker's link, the stateless callback redeems the code and binds the victim's session to the attacker-controlled identity, after which any data the victim submits is stored under the attacker's account; the same flaw also lets the attacker set the post-authentication redirect to an external site. No public exploit code was identified at time of analysis, but the technique is well-understood and requires no interaction with the identity provider beyond the attacker's own.