EUVD-2026-104212
GHSA-68m6-7hmq-4c53
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend crafted control message on feeding transport
-
DeliveryMessage forwarded to dynamic-router-control endpoint
-
ExploitSupply attacker-chosen expression-language predicate
-
ExecutionPredicate compiled and evaluated per exchange
-
ImpactArbitrary code execution as Camel process
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Code injection prevention, sandbox exec
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a deployment that uses the dynamic-router-control endpoint (introduced in 4.4.0) AND a route that forwards messages from an external, untrusted, or shared transport into that control endpoint - the pattern documented for routing participants in other JVMs or applications. The attacker must be able to send a message on that feeding transport; given PR:L, some level of access/authentication to the transport is expected, but no application-level authentication or user interaction beyond that is needed, and the attacker controls both the expression language and the expression. Limiting factors that reduce real-world exposure: deployments that do not expose the control endpoint over an external transport, or that set the predicate/expressionLanguage in the route rather than from the message, are not exploitable. On patched releases (4.23.0/4.22.1/4.18.5) the message-supplied predicate is rejected unless allowPredicateFromMessage is explicitly enabled. Note: removing optional expression languages from the classpath is NOT sufficient, because the always-present simple language is the default on the header path. Releases before 4.4.0 are not affected. |
| Impact | The CVSS 3.1 base score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects network-reachable, low-complexity code injection (CWE-94) that yields full confidentiality, integrity and availability impact - effectively remote code execution in the Camel process. A patch is confirmed available from Apache. However, the real-world risk is strongly gated by a deployment prerequisite not captured by the raw score: exploitation is only possible where a route forwards messages from an external or shared transport into a dynamic-router-control endpoint (the documented cross-JVM 'routing participant' pattern). This is an opt-in architecture, not a default configuration, so a large fraction of Camel deployments are not exposed. No EPSS score, KEV listing, or POC was provided in the input: there is no public exploit identified at time of analysis and no evidence of active exploitation, so this should be treated as a high-severity-but-conditionally-exploitable issue rather than a confirmed widespread threat. Note the apparent tension between CVSS PR:L and the description's phrasing 'any actor able to send a message on that transport ... no other authentication' - if the feeding transport is itself unauthenticated, effective access may be closer to PR:N, so the practical privilege barrier depends on how the transport is secured. |
| Exploit ScenarioDerived | An attacker who can place messages on a shared or external transport (for example a message broker or queue) that a Camel route forwards to a dynamic-router-control endpoint sends a subscribe/update control message whose predicate and expressionLanguage fields (or CamelDynamicRouterPredicate/CamelDynamicRouterExpressionLanguage headers) contain a malicious simple-language expression. With no allow-list or opt-in, the expression is compiled into a live predicate and evaluated against every exchange routed through the dynamic-router endpoint, executing attacker-chosen code with the privileges of the Camel process. No public exploit identified at time of analysis; the simple language is always on the classpath, so removing optional languages does not help. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message on a transport feeding that endpoint to choose both the expression language and the predicate expression that Camel compiles and then evaluates against every exchange routed through the corresponding dynamic-router endpoint, running with the full privileges of the Camel process - effectively code execution. The issue affects Camel 4.4.0 through 4.18.4 and 4.19.0 through 4.22.0 (releases before 4.4.0 are not affected), scored CVSS 3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), so some access to the feeding transport is expected but no application-level authentication or user interaction is required. Exposure is limited to deployments that expose the control endpoint through a route forwarding messages from an external, shared or untrusted transport; no public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
RemediationAI
Upgrade to Apache Camel 4.23.0, or to 4.22.1 if remaining on the 4.22.x stream, or to 4.18.5 if remaining on the 4.18.x stream; the 4.14.x and earlier streams are end-of-life and will not be patched, so those deployments must migrate to a supported line (vendor advisory: https://camel.apache.org/security/CVE-2026-83531.html). After upgrading, control messages that carry a message-supplied predicate expression or expression language are rejected by default; only enable the new allowPredicateFromMessage option on a dynamic-router-control endpoint when every sender of control messages is trusted, since enabling it restores the vulnerable behavior. If immediate upgrade is impossible, do not forward messages from untrusted or shared transports to a dynamic-router-control endpoint, and where control messages must cross such a transport, authenticate the sender and force the predicate and expression language to come from the route rather than the message - strip the CamelDynamicRouterPredicate and CamelDynamicRouterExpressionLanguage headers and clear the predicate and expressionLanguage fields of any DynamicRouterControlMessage before it reaches the endpoint (note that removing optional expression languages from the classpath is explicitly not a sufficient workaround, since the always-present simple language is the default on the header path). As defense in depth, restrict which principals can publish to the transports that feed the control endpoint - with the trade-off that this narrows legitimate participant integrations - and on 4.23.0/4.22.1 set the allowedSchemes option of the dynamic-router endpoint to constrain which destinations a subscription's destinationUri may name, which may break subscriptions that legitimately target schemes outside the allow-list.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is CWE-94 (Improper Control of Generation of Code), manifesting concretely as expression language injection (CWE-917 class) in Apache Camel's dynamic-router component. The dynamic-router-control endpoint, introduced in 4.4.0, accepts DynamicRouterControlMessage bodies carrying subscribe/update requests; DynamicRouterControlProducer took the subscription predicate and the name of the language used to compile it either from the predicate and expressionLanguage fields of the message body or from the CamelDynamicRouterPredicate and CamelDynamicRouterExpressionLanguage headers. DynamicRouterControlService then looked that language up in the CamelContext and compiled the expression into a live Predicate without any allow-list or opt-in, and the resulting rule was evaluated against every exchange traversing the dynamic-router endpoint for the lifetime of the subscription. Because any expression language on the classpath could be named - including the always-present simple language, which is the default on the header path - trimming optional expression languages from the classpath did not mitigate the issue. The upstream fix (apache/camel PRs 25992, 26018, 26019, 26020) introduces an allowPredicateFromMessage endpoint option, defaulting to false and flagged as insecure when enabled, so that the predicate and expressionLanguage configured on the endpoint are used instead of message-supplied values; a related allowedSchemes option on the dynamic-router endpoint restricts which destinations a subscription's destinationUri may name. Pre-4.4.0 releases derived control-channel predicates only from the route author's endpoint URI and are therefore unaffected.
Know when Apache Camel gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Network-reachable via the feeding transport with low complexity; PR:L reflects needing send access to that transport; arbitrary code execution in the Camel process gives full C/I/A impact.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
DescriptionCVE.org
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.
Executive ViewAI
Apache Camel's dynamic-router-control endpoint contains an expression language injection flaw that lets anyone able to place a message on the transport feeding that endpoint execute arbitrary code with the full privileges of the Camel process - in practice, takeover of the integration service and any credentials, data, or downstream systems it can reach. Only deployments that expose this control endpoint through a route forwarding messages from an external, shared, or untrusted transport are exposed, but those that do should treat this as a priority patching item because exploitation requires only low-privileged access to that transport and no user interaction. Leadership should care because a compromised integration layer sits at the center of data flows and often carries broad system-to-system trust.
Apply vendor patch. If patching cannot be completed immediately, remove or block network access to the dynamic-router-control endpoint from external, shared, or untrusted transports, and restrict it to trusted internal sources until the upgrade is in place.
Threat Intelligence Overview
NVD
CVE.org
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
More in Apache Camel
View allRemote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0)
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoS
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.1
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket messag
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remot
Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy im
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an a
Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize)
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to rem
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticate
Cypher injection in Apache Camel's camel-neo4j producer allows attackers who control JSON key names in the CamelNeo4jMat
Exploit-DB