Apache Camel Security Advisory - CVE-2026-78329

Apache Camel security advisory: CVE-2026-78329

Severity

MEDIUM

Summary

Camel-Undertow: the endpoint discarded the undertow-specific header filter strategy in favour of the base HTTP one, so the undertow filtering never ran on endpoint-configured routes

Versions affected

From 4.11.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.

Versions fixed

4.14.9, 4.18.4 and 4.22.0

Description

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.

Notes

The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24360 refers to the various commits that resolved the issue, and has more details.

The fix was merged on main in https://github.com/apache/camel/pull/25367 (commit 859e93b4b37fe41918c50812cb1fedb20ca6b8e1) and backported to camel-4.18.x in https://github.com/apache/camel/pull/25379 (commit 1574902d79cc5d36a2e618f7470bf0cba005d5e5) and to camel-4.14.x in https://github.com/apache/camel/pull/25381 (commit 0484842201ed53fb52f3223f9b698868644f5b6f). It restores UndertowHeaderFilterStrategy as the endpoint default, so the strategy the binding installs is no longer replaced by the base one. A follow-up documentation change on main, https://github.com/apache/camel/pull/25414 (commit 7226ce876b1432e27e390516401b287501816ddc), corrects the upgrade-guide text that described the earlier websocket-prefix filtering as active in releases where it did not in fact run; that documentation correction is not part of any release yet.

The endpoint default was changed to the base strategy by a refactoring that deprecated the component-specific HTTP header filter strategies, first released in 4.11.0; before that release the endpoint used the undertow strategy correctly, which is why the affected range starts there and not at the introduction of the component. The issue is classified as CWE-20 (Improper Input Validation), reflecting the effect of the unapplied filter on inbound headers rather than the wiring defect itself.

Mitigation

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.

Credit

This issue was discovered by Andrea Cosentino from Apache Software Foundation and Barak Srour from Apiiro

References

PGP signed advisory data: CVE-2026-78329.txt.asc
Mitre CVE Entry: https://www.cve.org/CVERecord?id=CVE-2026-78329