Apache Camel CVE-2026-80312

Exploitation requires the target to be running Apache Camel in the affected ranges (4.11.0 before 4.18.5, or 4.19.0 before 4.22.1) with the camel-oauth component used to guard a route - specifically the OAuthBearerTokenProcessor or OAuthCodeFlow processors protecting an HTTP-reachable endpoint. No credentials, user interaction, or non-default configuration on the caller's side is needed; the fail-open path triggers on the ordinary request path when authentication cannot be completed (missing Authorization header, non-bearer header, invalid token, or missing authorization code). The only real limiting factor is that the deployment must actually use camel-oauth route guarding rather than an external/explicit authorization check; deployments without the camel-oauth component or with a separate post-OAuth authorization step are not exposed.

This is a genuine high-priority issue, not an inflated high-CVSS score. The vendor CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2) describes a network-reachable, low-complexity, unauthenticated flaw, and the description corroborates it fully: the camel-oauth processors fail open, so an unauthenticated caller on the ordinary request path reaches the protected endpoint with no special configuration or prior access. The CVSS signals and the description are internally consistent, which raises confidence in the severity. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is currently no evidence of active or at-scale exploitation - exploitation status is therefore 'no public exploit identified at time of analysis', and the risk is driven by exploitability and impact rather than observed attacks. The source-code evidence (PRs 25567/25575/25576 adding setRouteStop(true) and fail-closed reject/rejectUnauthorized handling, plus a dedicated fail-closed test) confirms the root cause and that a patch exists, making this a real priority for any deployment using camel-oauth to guard routes. One caveat: the vendor rated impact C:H/I:L/A:N and scope Unchanged, but actual impact depends entirely on what the protected route exposes, so real-world severity could be higher or lower per deployment - verify against your own route behavior.

An attacker sends an ordinary HTTP request to a Camel route configured to require OAuth, either omitting the Authorization header or supplying a non-bearer/invalid credential. Because the guarding processor fails open instead of stopping the exchange, the request falls through to the protected endpoint and is processed as if authentication had succeeded. Given AV:N/AC:L/PR:N/UI:N, this requires no authentication, no user interaction, and only a single crafted request; no public exploit code is identified at time of analysis.