CVE-2026-78329 in Camel
Summary
by MITRE • 08/24/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The Apache Camel Undertow component contains a critical improper input validation vulnerability stemming from a defect in its header filtering mechanism, specifically affecting versions 4.11.0 through 4.14.9, 4.15.0 through 4.18.4, and 4.19.0 through 4.22.0 prior to the patch release. This flaw arises from an initialization sequence error where the UndertowEndpoint defaults its headerFilterStrategy field to the base HttpHeaderFilterStrategy instance. During endpoint construction, this generic strategy is passed into the UndertowHttpBinding, which subsequently overwrites the specialized UndertowHeaderFilterStrategy that DefaultUndertowHttpBinding attempts to install in its own constructor. Consequently, unless a deployment explicitly supplies a custom binding or an explicit header filter strategy configuration, the undertow-specific filtering logic never executes on endpoint-configured routes. The specific strategy object is constructed and immediately replaced before it can be consulted by the runtime, effectively leaving the specialized validation mechanisms orphaned and inactive within the transport boundary layer.
The operational impact of this defect manifests in two distinct security failures related to header handling at the undertow HTTP consumer boundary. First, because the legacy websocket exchange-header prefix was not filtered during inbound processing, wire headers bearing this prefix were mapped directly onto the Camel Exchange object. When an undertow WebSocket producer subsequently reads these headers, it interprets them as dispatch directives rather than standard metadata. This allows a malicious actor to manipulate message routing by injecting specific header values that cause the system to deliver messages to peers other than the one originally selected by the route logic, potentially leading to unauthorized data exposure or service disruption. Second, header names that undertow itself does not accept were mapped onto the Exchange rather than being skipped as intended. This lack of validation can lead to unexpected behavior in downstream components that rely on clean exchange headers, creating potential vectors for injection attacks or application instability.
This vulnerability is distinct from CVE-2025-30177 and represents a regression caused by subsequent code corrections failing to take effect due to the initialization order flaw. The base HttpHeaderFilterStrategy correctly configures inbound Camel-prefix filtering, so that specific protection remained active through the base class inheritance chain. However, two critical enhancements written into the UndertowHeaderFilterStrategy—one designed to skip header names rejected by undertow and another intended to filter the legacy websocket prefix in both directions—were applied only to the orphaned strategy instance. Since the endpoint no longer used this instance, these security controls were effectively nullified in all affected releases that shipped with them. Rest DSL consumers remained unaffected because UndertowComponent explicitly assigns the UndertowRestHeaderFilterStrategy, which correctly extends the undertow-specific logic and bypasses the defective initialization path.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation, as the system fails to adequately sanitize or validate incoming HTTP headers before processing them within the application context. The ability to manipulate message routing via header injection also touches upon aspects of ATT&CK technique T1568 Dynamic Resolution, where an attacker leverages protocol features to redirect traffic or exfiltrate data indirectly through misconfigured service mesh behaviors. While not a direct remote code execution vector, it enables unauthorized access control bypasses and potential denial of service conditions by disrupting the intended message flow architecture.
Users are strongly recommended to upgrade Apache Camel to version 4.22.0 immediately if they are on newer release streams, or to version 4.14.9 for those on the 4.14.x LTS stream, and 4.18.4 for users on the 4.18.x releases stream. For deployments that cannot upgrade immediately due to operational constraints, a mitigation strategy involves explicitly configuring the header filter strategy rather than relying on defaults. This can be achieved by binding an UndertowHeaderFilterStrategy instance in the registry and referencing it directly on the endpoint configuration using parameters such as undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy. Additionally, administrators should implement explicit header stripping at trust boundaries using removeHeaders directives targeting websocket-prefixed headers to mitigate the routing manipulation risk.
It is crucial to note a residual limitation that persists even after upgrading to patched versions. The undertow component deliberately retains websocket values as part of its externally visible API contract for backward compatibility reasons. Furthermore, the UndertowProducer reads these headers using in.getHeader, which does not consult any HeaderFilterStrategy instance during retrieval. This means the restored filtering provides defense-in-depth only at the initial transport boundary upon message ingestion. It does not protect routes that carry untrusted messages from non-undertow consumers into an undertow producer endpoint. In such scenarios, the application logic itself must be responsible for stripping or validating these dispatch headers before they are processed by the producer to ensure complete security coverage across all integration paths.