Apache Camel code injection, attacker-controlled (CVE-2026-83531) [PoC]

Exploitation confirmed - public proof-of-concept - CVE-2026-83531 is a high-severity code injection in Apache Camel 4.4.0 before 4.18.5 and 4.19.0 before 4.22.1 that lets anyone able to send a message on a transport feeding a dynamic-router-control endpoint compile and run an expression of their choosing with the privileges of the Camel process. Fixed in 4.23.0, 4.22.1 and 4.18.5 - upgrade immediately.

Overview

The dynamic-router-control endpoint, introduced in Camel 4.4.0, lets routing participants manage Dynamic Router subscriptions by sending control messages. When handling a subscribe or update request, DynamicRouterControlProducer took the subscription predicate and the name of the language used to compile it straight from the incoming message: either the predicate and expressionLanguage fields of a DynamicRouterControlMessage body, or the CamelDynamicRouterPredicate and CamelDynamicRouterExpressionLanguage headers. DynamicRouterControlService then resolved that language from the CamelContext and compiled the expression into a Predicate, with no allow-list and no opt-in.

That compiled predicate was added to the channel’s rule base and evaluated against every exchange routed through the corresponding dynamic-router endpoint for as long as the subscription lived. A route that forwards messages from an external transport to the control endpoint - the pattern shown in the component documentation for routing participants in other JVMs or applications - therefore let any actor able to send a message on that transport supply an expression of their choosing.

Impact

Any expression language on the classpath could be selected, including the simple language, which is always present and was the default on the header path. Stripping optional expression languages from the classpath does not prevent the issue. Exploitation needs only the ability to send a message on a transport whose route forwards it to a dynamic-router-control endpoint; no other authentication or user interaction is required. The result is arbitrary code execution under the Camel process identity, rated CVSS 8.8 (AV:N/AC:L/PR:L/UI:N). Releases before 4.4.0 are not affected, because their control channel took predicate expressions only from the endpoint URI configured by the route author. This vulnerability is not confirmed as actively exploited; treat it as a serious exposure for any deployment with an externally reachable control endpoint.

Remediation and Mitigation

• Upgrade to 4.23.0. On the 4.22.x stream, move to 4.22.1; on the 4.18.x stream, move to 4.18.5. The 4.14.x stream and earlier reached end of life before this issue was resolved and will not receive a fix, so those deployments must move to a supported release.
• After upgrading, control messages carrying a predicate expression or expression language are rejected unless the new allowPredicateFromMessage option is enabled on the dynamic-router-control endpoint. Enable it only when every sender of control messages is trusted.
• If you cannot upgrade immediately, do not forward messages from untrusted or shared transports to a dynamic-router-control endpoint. Where control messages must cross such a transport, authenticate the sender and set the predicate and expression language by the route rather than from the incoming message, for example by removing the CamelDynamicRouterPredicate and CamelDynamicRouterExpressionLanguage headers and clearing the predicate and expressionLanguage fields of a DynamicRouterControlMessage before it reaches the endpoint. Removing optional expression languages from the classpath is not a sufficient workaround.
• As defence in depth, restrict who can send to the transports that feed the control endpoint, and on 4.23.0 and 4.22.1 set the allowedSchemes option of the dynamic-router endpoint to limit which endpoints a subscription’s destinationUri may name.

The same trust boundary problems keep surfacing in Apache messaging components; see our coverage of Apache ActiveMQ CVE-2026-34197 added to CISA KEV amid active exploitation for a parallel case.

Security Insight

What makes this bug notable is that the safe design was available all along: routing participants could have been restricted to predicates defined by the route author, as pre-4.4.0 releases effectively were. Instead, a management channel documented for cross-JVM use assumed that anyone who could reach it was trusted, an assumption that rarely holds when the transport is a message broker or an HTTP listener reachable from other network zones. The fix’s decision to gate message-supplied predicates behind an explicit opt-in is the right shape, but it lands more than twenty minor releases after the endpoint shipped, which says something about how integration middleware treats its own introspection planes.

Further Reading

• Apache ActiveMQ CVE-2026-34197 added to CISA KEV catalo
• All High Vulnerabilities
• Recent Critical Vulnerabilities
• Top Critical CVEs