Apache Camel EUVD-2026-104211

Exploitation requires the camel-platform-http-vertx CORS handler to be enabled AND camel.server.cors.origins to be left unset (the vulnerable default once CORS is turned on), which causes the handler to reflect the caller's Origin and send Access-Control-Allow-Credentials: true to any origin. Realistic impact additionally requires the Camel HTTP endpoint to rely on ambient credentials (cookies/HTTP auth) that the browser will attach cross-origin, and a victim with an active authenticated session who visits an attacker-controlled page (UI:R). Limiting factors: setting camel.server.cors.origins to an explicit allow-list fully mitigates (and is the documented workaround); endpoints without credentialed/sensitive responses, or deployments where CORS is disabled, are not meaningfully exposed; and affected versions are bounded to Apache Camel 4.0.0-4.18.4 and 4.19.0-4.22.0.

This is a credible medium-severity information-disclosure issue, but not an emergency. The vendor CVSS of 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) is internally consistent with the description: the flaw is a CORS misconfiguration (CWE-942) in the camel-platform-http-vertx component where createCorsHandler() emitted Access-Control-Allow-Credentials: true outside the origin check, and - because an unset camel.server.cors.origins reflects the caller's Origin back - produced the credentialed any-origin configuration the fetch spec forbids as a literal wildcard. UI:R correctly reflects that a victim must visit an attacker-controlled page, and C:H/I:N/A:N correctly scope impact to read-only disclosure of responses. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The absence of these signals, combined with the UI:R requirement and the dependency on a non-standard-but-default configuration (CORS enabled with no origin list), means this is a real-but-conditional priority rather than a mass-exploitation threat. No signals are in direct conflict; the main caveat is that realized impact depends on whether the exposed Camel HTTP endpoints actually serve credential-gated sensitive data.

An attacker hosts a malicious web page and lures a user who has an authenticated session (e.g., cookie-based) with a Camel platform-http-vertx endpoint that has CORS enabled but no explicit origin list. When the victim visits the page, attacker JavaScript issues a credentialed cross-origin fetch to the Camel endpoint; the handler reflects the attacker's origin and returns Access-Control-Allow-Credentials: true, letting the script read the authenticated response. No public exploit code was identified in the provided data, though the vendor's regression tests demonstrate the exact header behavior.