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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-78329)

ID	Name	Product	Family	Type	Severity
464187	Echo: org.apache.camel:camel-undertow: security update to 4.14.9	Tenable Cloud Security	Echo Local Security Checks	Local	critical
464187	Echo: org.apache.camel:camel-undertow: security update to 4.14.9	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	critical

Detections

Analytics

CVE-2026-78329

critical

Tenable Plugins

critical

critical