CVE-2026-83531
Camel-Dynamic-Router: The dynamic-router-control endpoint compiled the subscription predicate from an expression and an expression language supplied by the control message, allowing an actor who can send messages to a route that forwards them to the control endpoint to execute code in the Camel process
Description
The dynamic-router-control endpoint, introduced in 4.4.0, lets routing participants manage Dynamic Router subscriptions by sending control messages. When it handled a subscribe or update request, DynamicRouterControlProducer took the subscription predicate and the name of the language used to compile it from the incoming message, either from the predicate and expressionLanguage fields of a DynamicRouterControlMessage body or from 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. The 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 existed. A route that forwards messages from an external transport to the control endpoint, as 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, which was evaluated with the privileges of the Camel process. Any expression language available on the classpath could be selected, including the simple language, which is always present and was the default on the header path, so removing optional expression languages from the classpath did not prevent the issue. Exploitation requires 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 needed. 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.
Mitigation
Credit
This issue was discovered by Leon Zlobecki
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24576 refers to the commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/25992 (commit 1d5d3e983c3a3fb64b6bfe238d614726191ee977), and backported to camel-4.22.x in https://github.com/apache/camel/pull/26018 (commit e09d945d9458d57d580fa88029ba1cd62d0837cc) and to camel-4.18.x in https://github.com/apache/camel/pull/26019 (commit a1132971f3d64fd4d1dc748c3bfa87c49130ac9b). A follow-up documentation change, https://github.com/apache/camel/pull/26020 (commit b74fcd1ae8d17a9fd74322b02127c9bd4b41faef), placed the upgrade-guide entries for every affected release line on main.
A new allowPredicateFromMessage option on the dynamic-router-control endpoint, defaulting to false, now decides whether the subscription predicate and its expression language may be taken from a control message. When it is false, a subscribe or update request whose DynamicRouterControlMessage body or headers carry a predicate expression or an expression language is rejected with an IllegalArgumentException, and the predicate and expressionLanguage configured on the endpoint are used instead. The option is not mapped from any message header, and the toD optimisation keeps it on the endpoint URI, so only the route author can enable it. The header form of a control message now also falls back to the endpoint configuration for parameters the message does not carry, so a subscription can be declared entirely on a static endpoint URI. Subscriptions that reference a predicate bean from the registry, or that pass a Predicate instance in the message body, are unchanged. On 4.23.0 and 4.22.1 the option is additionally marked as an insecure:dev security option, so the security policy framework treats an endpoint that enables it as insecure, which fails by default when camel.main.profile is set to prod, and the dynamic-router endpoint gains an allowedSchemes option, unset by default, that restricts which endpoint schemes a subscription’s destinationUri may use. The 4.18.5 release carries the allowPredicateFromMessage option only, because the security-option metadata and the recipient-list scheme allow-list that the other two releases build on are not present on that maintenance line.
This is a change of default behaviour for applications whose control messages supply their own predicate expression: they must set allowPredicateFromMessage=true on the control endpoint, which should only be done when every sender of control messages is trusted. The change is documented in the upgrade guides for each affected release line. The issue is classified as CWE-94 (Improper Control of Generation of Code (‘Code Injection’)) and CWE-917 (Improper Neutralization of Special Elements used in an Expression Language Statement (‘Expression Language Injection’)).