Severity:
CVSS 3.1: 8.8 (high) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Affected versions:
- Apache Camel (org.apache.camel:camel-dynamic-router) 4.4.0 before 4.18.5
- Apache Camel (org.apache.camel:camel-dynamic-router) 4.19.0 before 4.22.1
Description:
Improper Control of Generation of Code ('Code Injection'), Improper
Neutralization of Special Elements used in an Expression Language Statement
('Expression Language Injection') vulnerability in Apache Camel.
This issue affects Apache Camel: from 4.4.0 before 4.18.5, from 4.19.0 before
4.22.1.
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.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If
users are on the 4.22.x releases stream, then they are suggested to upgrade to
4.22.1. If users are on the 4.18.x releases stream, then they are suggested to
upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life
before this issue was resolved and will not receive a fix, so deployments on
those lines must move to a supported release. After upgrading, a control
message that carries a predicate expression or an expression language is
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. For deployments that 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 make sure the predicate and expression
language of each subscription are set by the route rather than taken 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.
Solution:
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If
users are on the 4.22.x releases stream, then they are suggested to upgrade to
4.22.1. If users are on the 4.18.x releases stream, then they are suggested to
upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life
before this issue was resolved and will not receive a fix, so deployments on
those lines must move to a supported release. After upgrading, a control
message that carries a predicate expression or an expression language is
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. 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.
Work Arounds:
For deployments that 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 make
sure the predicate and expression language of each subscription are set by the
route rather than taken 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.
Credit:
Leon Zlobecki (finder)
Andrea Cosentino (remediation developer)
References:
https://camel.apache.org/security/CVE-2026-83531.html
https://issues.apache.org/jira/browse/CAMEL-24576
https://github.com/apache/camel/pull/25992
https://github.com/apache/camel/pull/26018
https://github.com/apache/camel/pull/26019
https://github.com/apache/camel/pull/26020
https://camel.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-83531
