EUVD-2026-25806
GHSA-2vqf-x7g4-7c2g
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
Email is delivered over the network with no attacker privileges or victim interaction (AV:N/PR:N/UI:N), but exploitation depends on a specific vulnerable route topology (camel-mail consumer plus header-sensitive downstream component), justifying AC:H.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
Lifecycle Timeline
6Blast Radius
ecosystem impact- 24 maven packages depend on org.apache.camel:camel-mail (6 direct, 18 indirect)
Ecosystem-wide dependent count for version 3.0.0.
DescriptionCVE.org
The Camel-Mail component is vulnerable to Camel message header injection. The custom header filter strategy used by the component (MailHeaderFilterStrategy) only filters the 'out' direction via setOutFilterStartsWith, while it does not configure the 'in' direction via setInFilterStartsWith. As a result, when a Camel application consumes mail through camel-mail (for example via from(\"imap://...\") or from(\"pop3://...\")) the inbound filter check is skipped and Camel-prefixed MIME headers are mapped unfiltered into the Exchange. An attacker who can deliver an email to a mailbox monitored by such a consumer can inject Camel-specific headers that, for some Camel components downstream of the mail consumer (such as camel-bean, camel-exec, or camel-sql), can alter the behaviour of the route. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177) and the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891).
This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.1.
Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.1. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6.
AnalysisAI
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 attacker who can email a monitored mailbox smuggle Camel-prefixed MIME headers into the Exchange. Because MailHeaderFilterStrategy filters only the outbound direction and never sets an inbound filter, inbound Camel headers reach downstream components such as camel-bean, camel-exec, or camel-sql where they can alter route behavior, potentially reaching command or query execution. There is no public exploit identified at time of analysis and EPSS is very low (0.02%), but the vendor rates it CVSS 9.4 and SSVC marks it automatable.
Technical ContextAI
Apache Camel is a widely used Java integration framework where 'components' bridge protocols (here IMAP/POP3/SMTP mail) into a common Exchange abstraction carrying message headers. The camel-mail component uses MailHeaderFilterStrategy, which calls setOutFilterStartsWith to strip Camel-internal headers on the outbound direction but omits the corresponding setInFilterStartsWith, so inbound MIME headers prefixed as Camel headers are mapped straight into the Exchange without filtering. Although tagged CWE-502 (deserialization) and 'Deserialization', the actual root cause is missing input-header sanitization - an injection/trust-boundary flaw. This mirrors prior Camel filter fixes: camel-undertow (CVE-2025-30177) and the general incoming-header filter work (CVE-2025-27636, CVE-2025-29891).
RemediationAI
Vendor-released patch: upgrade to Apache Camel 4.19.0, which fixes the issue; LTS users should move to 4.18.1 (4.18.x stream) or 4.14.6 (4.14.x stream) per https://camel.apache.org/security/CVE-2026-33454.html. Red Hat consumers should apply the fixes referenced in RHSA-2026:17668 and RHSA-2026:19835. If immediate upgrade is not possible, apply a compensating control by explicitly configuring an inbound header filter on the mail consumer - set a custom HeaderFilterStrategy that filters inbound headers starting with the Camel prefix (equivalent to setInFilterStartsWith), or add a route processor that removes/rejects Camel-prefixed headers immediately after from("imap://...")/from("pop3://...") before any camel-bean, camel-exec, or camel-sql step; the trade-off is that legitimately-needed inbound headers must be re-added explicitly. Where feasible, avoid passing raw mail headers into command- or query-executing components. Red Hat VEX/errata provide per-product guidance.
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
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
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)
Cypher injection in Apache Camel's camel-neo4j producer allows attackers who control JSON key names in the CamelNeo4jMat
Remote code execution in the Apache Camel camel-hazelcast component allows an attacker who can join or reach the Hazelca
Remote code execution in Apache Camel's camel-vertx-http component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0) arises when a p
Blind out-of-band data exfiltration in Apache Camel 4.14.0-4.20.x arises because the default ObjectInputFilter pattern b
JWT claim validation in Apache Camel's Platform HTTP Main component silently fails to enforce issuer and audience constr
Same weakness CWE-502 – Deserialization of Untrusted Data
View allSame technique Deserialization
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today