TL;DR
The Apache Camel project patched four high-severity flaws across five components. Three Apache Camel vulnerabilities let an attacker inject Camel control headers, which triggers server-side request forgery and leaks secrets. A fourth flaw in camel-keycloak opens a fail-open authentication bypass that can reach code-execution routes.
Why It Matters
Camel drives integration routes inside many enterprise systems. Therefore, a header trick that redirects an internal HTTP call can reach a cloud metadata endpoint or an internal service. Worse, the HTTP producer then resolves property placeholders on the attacker-supplied URI. As a result, environment variables, application properties, and vault secrets travel straight to the attacker.
The Keycloak flaw fails in a different way. In its default setup, the policy accepts any non-null bearer token. Consequently, an attacker can slip past the guard, and on some routes reach a producer that runs code. Crucially, that default is the documented starter configuration, so many deployments may match it. No public proof-of-concept or in-the-wild exploitation has been confirmed for any of the four issues.
How the Attack Works
Header injection across three connectors
Three consumers copied external input into the Camel Exchange without a HeaderFilterStrategy. The camel-iggy consumer mapped inbound message user-headers directly, as detailed in the CVE-2026-55994 advisory. Meanwhile, the camel-atmosphere-websocket consumer copied WebSocket query parameters, covered in the CVE-2026-55993 advisory. Similarly, the camel-vertx-websocket consumer mapped query and path parameters, described in the CVE-2026-46726 advisory.
Because nothing blocked the Camel namespace, an attacker could set CamelHttpUri as a plain header or parameter. That value then steers a downstream HTTP producer to a chosen destination. On an unauthenticated WebSocket endpoint, a remote attacker can reach this path without any credentials.
The secret leak follows from that first move. When the producer builds the request, it resolves Camel property placeholders on the attacker-supplied URI. So a placeholder that points at an environment variable, an application property, or a vault reference gets expanded to its real value. That value then rides along in the outbound request to the attacker-chosen host.
Authentication bypass in camel-keycloak
The KeycloakSecurityPolicy verifies a token only inside its role and permission checks. However, the default “Basic Setup” leaves both lists empty, so the verification path never runs. The CVE-2026-53913 advisory explains that any non-null bearer value then passes the guard. Where a protected route forwards to a code-execution producer, that gap can enable unauthenticated remote code execution. Novee Security researcher Lidor Ben Shitrit reported the flaw.
Affected Versions
The header-injection flaws span several 4.x streams. CVE-2026-55994 affects 4.17.0 before 4.18.3, and 4.19.0 before 4.21.0. CVE-2026-55993 and CVE-2026-46726 affect 4.0.0 before 4.14.8, then 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0. Finally, the camel-keycloak bypass affects 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0. Because that component arrived in 4.15.0, the 4.14.x line stays clear of it.
Patch and Mitigation
Upgrade first. Version 4.21.0 fixes all four issues, while 4.18.3 covers the 4.18.x stream, and 4.14.8 covers the affected WebSocket flaws on 4.14.x. If you cannot patch yet, strip Camel control headers at the start of the route with removeHeaders(‘Camel*’) and removeHeaders(‘camel*’).
Next, require authentication on WebSocket endpoints, and restrict who can publish to a consumed Iggy stream. Also avoid feeding an untrusted consumer straight into a header-driven HTTP producer. For the Keycloak policy, set a non-empty requiredRoles or requiredPermissions, or turn allowTokenFromHeader off so the token path runs. These steps close the exposure until you move to a fixed release.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.