CVE-2026-78329: Apache Camel Information Disclosure Vulnerability

CVE-2026-78329 Overview

CVE-2026-78329 is an improper input validation vulnerability [CWE-20] in the Apache Camel Undertow component. The UndertowEndpoint class defaults its headerFilterStrategy field to the base HttpHeaderFilterStrategy and pushes that instance into the lazily created UndertowHttpBinding. This action overwrites the UndertowHeaderFilterStrategy that DefaultUndertowHttpBinding installs in its own constructor. As a result, undertow-specific filtering never executes on endpoint-configured routes unless a deployment supplies a custom binding or explicit strategy. Attackers can send crafted websocket.* prefixed headers that a WebSocket producer reads as dispatch directives, redirecting messages to unintended peers.

Critical Impact
Remote attackers can hijack WebSocket message dispatch by injecting websocket.* headers over the network without authentication or user interaction.

Affected Products

Apache Camel 4.11.0 through 4.14.8
Apache Camel 4.15.0 through 4.18.3
Apache Camel 4.19.0 through 4.21.x

Discovery Timeline

2026-08-24 - CVE-2026-78329 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-78329

Vulnerability Analysis

The vulnerability affects the Apache Camel Undertow component's header filtering logic. UndertowEndpoint constructs the correct UndertowHeaderFilterStrategy inside DefaultUndertowHttpBinding, then immediately replaces it with the base HttpHeaderFilterStrategy before it can be consulted. The transport-boundary filtering therefore never runs on endpoint-configured routes.

Two concrete consequences follow. First, the legacy websocket.* Exchange-header prefix is not filtered at the undertow transport boundary in either direction. An undertow HTTP consumer maps inbound wire headers of that form onto the Exchange, and an undertow WebSocket producer subsequently reads them as dispatch directives. Second, header names that undertow itself rejects are mapped onto the Exchange rather than skipped.

Rest DSL consumers are unaffected. UndertowComponent assigns UndertowRestHeaderFilterStrategy explicitly, which extends the undertow strategy and survives the override path.

Root Cause

The root cause is a lazy initialization ordering defect. UndertowEndpoint field defaults are applied after DefaultUndertowHttpBinding runs its constructor. Two subsequent corrections written into UndertowHeaderFilterStrategy - one skipping headers undertow rejects, one filtering the websocket.* prefix bidirectionally - were applied to a class the endpoint no longer used. This is not a regression of CVE-2025-30177: the base HttpHeaderFilterStrategy still configures the inbound Camel-prefix filter, so that protection was never lost.

Attack Vector

An unauthenticated remote attacker sends HTTP requests containing headers prefixed with websocket. to an undertow HTTP consumer. The consumer maps these headers onto the Camel Exchange without filtering. When the route forwards the Exchange to an undertow WebSocket producer, UndertowProducer reads those headers via in.getHeader and treats them as dispatch directives. The attacker can therefore direct WebSocket delivery to a peer other than the one the route selected.

The vulnerability requires a route topology that combines an undertow HTTP consumer with an undertow WebSocket producer without custom header filtering configured on the endpoint.

Detection Methods for CVE-2026-78329

Indicators of Compromise

Inbound HTTP requests containing headers with the websocket. prefix, particularly websocket.connectionKey, websocket.sendToAll, or similar dispatch directives.
WebSocket messages delivered to endpoints that do not match the routing logic defined in Camel routes.
Unexpected Camel Exchange header values referencing undertow dispatch semantics originating from external HTTP callers.

Detection Strategies

Inspect deployed Camel route configurations for undertow endpoints that omit an explicit headerFilterStrategy parameter and rely on defaults.
Enumerate installed Apache Camel versions across build manifests (pom.xml, build.gradle) and match against affected version ranges.
Enable Camel debug tracing on undertow endpoints and audit Exchange headers propagating between HTTP consumers and WebSocket producers.

Monitoring Recommendations

Log all HTTP request headers arriving at undertow consumers and alert on any header name beginning with websocket..
Correlate WebSocket peer connection identifiers with expected route destinations to detect misdirected messages.
Monitor upstream proxy or WAF logs for anomalous header names not present in normal application traffic.

How to Mitigate CVE-2026-78329

Immediate Actions Required

Upgrade Apache Camel to version 4.22.0 on the main release line.
Upgrade to 4.14.9 for deployments running the 4.14.x LTS stream.
Upgrade to 4.18.4 for deployments running the 4.18.x release stream.
Audit all undertow routes and add removeHeaders("websocket.*") at trust boundaries where untrusted messages cross into undertow producers.

Patch Information

The Apache Camel project has released fixed versions 4.14.9, 4.18.4, and 4.22.0. Refer to the Apache Camel CVE-2026-78329 Advisory for full remediation guidance. Note a residual limitation: the undertow component keeps websocket.* values as part of its externally visible API contract, and UndertowProducer reads them with in.getHeader, which does not consult a HeaderFilterStrategy. The restored filtering is defence in depth at the undertow transport boundary only. Routes carrying untrusted messages from a non-undertow consumer into an undertow producer must strip these headers explicitly.

Workarounds

Bind an UndertowHeaderFilterStrategy instance in the Camel registry and reference it on each endpoint, for example undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy.
Add removeHeaders("websocket.*") to any route that carries messages from untrusted sources toward an undertow producer.
Restrict network exposure of undertow HTTP consumers to trusted upstream systems until patches can be deployed.

bash

# Configuration example
# Register the correct strategy and reference it on the endpoint
# Java DSL:
#   registry.bind("myStrategy", new UndertowHeaderFilterStrategy());
#
# Route:
from("undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy")
    .removeHeaders("websocket.*")
    .to("undertow:ws://backend:8080/events");