EUVD-2026-64962
GHSA-v7h8-xhh6-gfj4
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend HTTP request with websocket.* headers
-
DeliveryConsumer maps unfiltered headers to Exchange
-
ExploitRoute forwards to undertow WebSocket producer
-
ExecutionProducer reads headers as dispatch directives
-
ImpactMessage delivered to attacker-chosen peer
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | Requires a Camel route using the camel-undertow component where an undertow HTTP consumer feeds an undertow WebSocket producer, AND the endpoint relies on the default header-filter behaviour - i.e. no custom UndertowHttpBinding and no explicit headerFilterStrategy configured on the endpoint. Under those conditions the attacker supplies inbound wire headers using the legacy 'websocket.' prefix (or header names Undertow would otherwise reject). Limiting factors: Rest DSL consumers are immune (they force UndertowRestHeaderFilterStrategy); deployments that already bind an explicit UndertowHeaderFilterStrategy are not affected; and the impact is confined to WebSocket dispatch redirection / header mapping rather than code execution. Auth requirements are not asserted as authenticated because the CVSS vector states PR:N, but exploitation still depends on this specific vulnerable route topology being present. |
| Impact | The signals conflict sharply. The published CVSS 3.1 base score is 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), but the description does not support full high impact across confidentiality, integrity and availability: the concrete effect is unfiltered dispatch headers letting a WebSocket producer misdeliver a message to the wrong peer plus unexpected header mapping - an information-disclosure / limited-integrity issue (vendor tags it 'Information Disclosure'), not remote code execution. EPSS is very low (0.16%, 5th percentile) and there is no KEV listing and no known POC, consistent with a bug that is real but hard to weaponize broadly. Exploitation also requires a specific route topology - an undertow HTTP consumer feeding an undertow WebSocket producer with no custom binding or explicit headerFilterStrategy - which raises real-world attack complexity above the AC:L the vector claims. Net assessment: this is a moderate-severity defence-in-depth gap, not a 9.8 emergency; the headline score appears inflated relative to the described impact and should be treated with caution. It is explicitly NOT a regression of CVE-2025-30177 (the base class kept the inbound Camel-prefix filter working). |
| Exploit ScenarioDerived | An attacker sends an HTTP request to an undertow HTTP consumer with crafted 'websocket.*' headers (for example a header naming a target connection/peer key). Because undertow-specific filtering never runs, those headers are mapped onto the Camel Exchange, and when the route forwards to an undertow WebSocket producer they are interpreted as dispatch directives, causing the message to be delivered to a peer other than the one the route intended. No POC is publicly known and no authentication is indicated by the vector. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 26, 2026
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 remote senders smuggle legacy 'websocket.' dispatch headers across the undertow transport boundary. Because UndertowEndpoint overwrote the UndertowHeaderFilterStrategy with the base HttpHeaderFilterStrategy, undertow-specific filtering never ran on endpoint-configured routes, so an undertow HTTP consumer maps attacker-controlled 'websocket.*' wire headers onto the Exchange and a downstream undertow WebSocket producer can be steered to deliver to a peer other than the one the route selected. No public exploit identified at time of analysis, EPSS is low (0.16%, 5th percentile), and the fix is available from Apache.
RemediationAI
Vendor-released patch: upgrade to Apache Camel 4.22.0; 4.14.x LTS users upgrade to 4.14.9, and 4.18.x users upgrade to 4.18.4. If you cannot upgrade immediately, configure the strategy explicitly instead of relying on the default - bind an UndertowHeaderFilterStrategy in the registry and reference it on the endpoint, e.g. undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy - and additionally strip dispatch headers at the trust boundary with removeHeaders("websocket.*"). Be aware of a residual limitation the upgrade does not remove: the undertow component deliberately keeps the 'websocket.' values as part of its externally visible API contract, and UndertowProducer reads them via in.getHeader(), which does not consult any HeaderFilterStrategy; the restored filtering is defence in depth at the undertow transport boundary only, so a route carrying an untrusted message from a non-undertow consumer into an undertow producer must strip those headers itself. See https://camel.apache.org/security/CVE-2026-78329.html.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache Camel is a Java enterprise-integration framework; the camel-undertow component provides HTTP and WebSocket endpoints backed by the Undertow web server. The affected classes are UndertowEndpoint, DefaultUndertowHttpBinding, and the HeaderFilterStrategy hierarchy. DefaultUndertowHttpBinding installs an UndertowHeaderFilterStrategy in its constructor, but UndertowEndpoint defaulted its headerFilterStrategy field to the generic HttpHeaderFilterStrategy and pushed that instance into the lazily-created binding, replacing the undertow-specific strategy before it was ever consulted. This is a classic CWE-20 (Improper Input Validation) root cause: header names Undertow itself rejects, and the legacy 'websocket.' prefix used as internal dispatch directives, were mapped onto the Exchange in both directions instead of being skipped. Two later corrections (skip undertow-rejected header names; filter the 'websocket.' prefix bidirectionally) were written into the orphaned strategy class and therefore never took effect in the shipped releases. CPE coverage is cpe:2.3:a:apache_software_foundation:apache_camel, matching only the affected version ranges.
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:N/UI:N/S:U/C:H/I:H/A:H
Network-reachable and unauthenticated (PR:N), but AC:H because it needs a specific undertow-consumer-to-websocket-producer topology using default filtering; impact is limited misdelivery/header injection (C:L/I:L), no availability effect.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
4DescriptionCVE.org
Improper input validation vulnerability in Apache Camel Undertow component.
This issue affects Apache Camel: from 4.11.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.
UndertowEndpoint defaulted its headerFilterStrategy field to the base HttpHeaderFilterStrategy and pushed that instance into the UndertowHttpBinding it creates lazily, overwriting the UndertowHeaderFilterStrategy that DefaultUndertowHttpBinding installs in its own constructor. Unless a deployment supplied a custom binding or an explicit headerFilterStrategy, the undertow-specific filtering therefore never executed on endpoint-configured routes: the strategy object was constructed and immediately replaced before it could be consulted. The consequence is that the legacy websocket. Exchange-header prefix was not filtered at the undertow transport boundary in either direction, so an undertow HTTP consumer mapped inbound wire headers of that form onto the Exchange, where an undertow WebSocket producer reads them as dispatch directives and can be made to deliver to a peer other than the one the route selected; and header names that undertow itself does not accept were mapped onto the Exchange rather than being skipped. Rest DSL consumers were never affected, because UndertowComponent assigns UndertowRestHeaderFilterStrategy explicitly, which extends the undertow strategy. This is not a regression of CVE-2025-30177: the base HttpHeaderFilterStrategy configures the inbound Camel-prefix filter itself, so the protection introduced by that advisory continued to work through the base class and was never lost. What the change did was leave the undertow strategy orphaned on the endpoint path, with the effect that two subsequent corrections written into it - one skipping header names undertow rejects, one filtering the legacy websocket. prefix in both directions - were applied to a class the endpoint no longer used and never took effect in the releases that shipped them.
Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, configure the strategy explicitly rather than relying on the default, for example by binding an UndertowHeaderFilterStrategy in the registry and referencing it on the endpoint as undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, and additionally strip the dispatch headers at the trust boundary with removeHeaders(“websocket.*”). Note a residual limitation that upgrading does not remove: the undertow component deliberately keeps the websocket. values as part of its externally visible API contract, and UndertowProducer reads them with in.getHeader, which does not consult a HeaderFilterStrategy at all. The restored filtering is therefore defence in depth at the undertow transport boundary only. A route that carries an untrusted message from a non-undertow consumer into an undertow producer is not protected by this fix and must strip those headers itself.
Blast Radius
ecosystem impact- 5 maven packages depend on org.apache.camel:camel-undertow (3 direct, 2 indirect)
Ecosystem-wide dependent count for version 4.11.0.
Executive ViewAI
Apache Camel Undertow-based message routing in versions 4.11.0-4.21.x can be exploited to redirect critical business messages to unintended recipients, enabling data interception or service disruption. Organizations running Camel in integration infrastructure using WebSocket routing face exposure to message hijacking and potential data loss. Vendor patches are available to address this vulnerability.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
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
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)
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
Exploit-DB