Apache Camel Patches Five High-Severity Vulnerabilities
TL;DR
Apache Camel has patched five high-severity flaws in its connectors. Three let a remote attacker forge server-side requests and steal secrets. Another skips a Keycloak login check, and one abuses JMS messages. Users should upgrade to 4.21.0, 4.18.3, or 4.14.8.
Why it matters
Apache Camel moves data between systems in thousands of companies. It links queues, APIs, files, and cloud services in one flow. So one weak link can expose a whole pipeline. These Apache Camel vulnerabilities all rate high. Three enable server-side request forgery through header tricks. That path can reach internal services or a cloud metadata endpoint. It can also leak secrets, config values, and vault keys. Attackers love that trick, since it turns a trusted server into a proxy. The Keycloak flaw is the worst in a common setup. There, it can lead to remote code execution by anyone.
How the attack works
Header injection and SSRF
Three connectors map untrusted input straight into Camel headers. Camel-Iggy copies inbound message headers without any filter. The two WebSocket consumers do the same with query values. Vertx-WebSocket also trusts path values in that way. Camel headers quietly control routing and outbound targets. As a result, an attacker can set control headers like CamelHttpUri. That header points a later HTTP request at any target. This is classic server-side request forgery from inside the route. The producer then fills in property values on that URL. So injected values send real secrets back to the attacker. Both WebSocket flaws need no login when the endpoint is open.
JMS deserialization bypass
CVE-2026-43866 sidesteps an earlier security fix. A crafted DefaultExchangeHolder object passes the class allow-list. That class sits in a trusted Camel namespace, so the check clears it. The sending side gates this handling, yet the receiver did not. The receiver then unpacks it into the Exchange with no extra checks. This lets an attacker inject the body, headers, and settings. No gadget chain is needed, only common Java types. The same weakness reaches the AMQP and ActiveMQ connectors.
Keycloak fail-open authentication
CVE-2026-53913 checks a bearer token only during role checks. The default setup defines no roles or rules. So that token check never runs. Therefore any non-null token, even a forged one, passes. A missing token is still rejected, which hides the gap. Routes behind this policy often do real server-side work. The request then reaches the guarded route with no real check.
Exploitation status
No public exploit has surfaced for these bugs. CISA has not added them to its exploited-bug list. Still, one vendor reports probing against the Keycloak flaw. Nobody has confirmed a real attack yet.
Affected versions
The flaws span the Camel 3.x and 4.x lines. All five Apache Camel vulnerabilities rate high. Fixed builds are 4.21.0, 4.18.3, and 4.14.8. Exact ranges differ by connector, per the advisory. The JMS bug reaches back to version 3.0.0. The Keycloak and Iggy issues start in the 4.15 and 4.17 lines. Both WebSocket flaws begin at 4.0.0.
Patch and mitigation
Upgrade to 4.21.0 wherever you can. LTS users can move to 4.14.8 or 4.18.3 instead. After the fix, JMS ObjectMessage handling stays off by default. Turn it on only for queues fed by trusted senders. The Keycloak fix also needs a non-empty role or rule list. Where upgrades must wait, limit who can publish to Camel. Also strip Camel* headers at the start of each route. Require a login on any open WebSocket endpoint. For each fix and range, read the Apache Camel security advisories.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
