Description
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.
Published: 2026-08-24
Score: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: Unrestricted Header Manipulation
Action: Update Version
AI Analysis

Impact

The vulnerability arises because the UndertowEndpoint replaces the Undertow‑specific header filter with a base HTTP filter before the Undertow transport can inspect request headers. As a result, headers that the Undertow transport normally rejects or strips—including the legacy websocket.Exchange‑header prefix—are forwarded to the Camel Exchange. An Undertow WebSocket producer can then consume these headers as dispatch instructions and deliver messages to an unintended peer, or allow otherwise unsafe header names to be propagated. The weakness is an improper input validation flaw (CWE‑20). Apart from changing routing behavior, this can lead to information disclosure or interference with message integrity.

Affected Systems

Apache Camel versions 4.11.0 through 4.14.8, 4.15.0 through 4.18.3, and 4.19.0 through 4.21.9 are vulnerable. The fix is included in Camel 4.14.9, 4.18.4 and 4.22.0. Users running any of the affected releases should update to the corresponding fixed version.

Risk and Exploitability

The EPSS score is < 1% and the vulnerability is not listed in CISA’s KEV catalogue, indicating a low but known exploit probability. The CVSS score of 9.8 signals a high severity, and the design flaw permits a remote attacker controlling HTTP headers to subvert routing logic. The attack vector is inferred to be external HTTP/HTTPS traffic sent to an Undertow endpoint. Although the vulnerability does not deliver direct code execution, it can compromise confidentiality, integrity, and availability by redirecting messages or exposing internal transport details. Hence, the risk is high in environments where Camel exposes Undertow endpoints to untrusted clients.

Generated by OpenCVE AI on August 26, 2026 at 22:20 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade Apache Camel to a fixed release: 4.22.0, or for 4.14.x users upgrade to 4.14.9; for 4.18.x users upgrade to 4.18.4.
  • If upgrading immediately is not possible, configure the endpoint to use an explicit UndertowHeaderFilterStrategy (bind it in the registry and reference it with `headerFilterStrategy=#myStrategy`) and strip dangerous headers at the trust boundary with `removeHeaders("websocket.*")`.
  • Harden exposure by restricting public access to Undertow endpoints through network controls or by reviewing routes to ensure no untrusted headers are propagated into Undertow producers.

Generated by OpenCVE AI on August 26, 2026 at 22:20 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Github GHSA Github GHSA GHSA-v7h8-xhh6-gfj4 Apache 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
History

Thu, 27 Aug 2026 18:00:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*

Wed, 26 Aug 2026 20:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Mon, 24 Aug 2026 18:15:00 +0000

Type Values Removed Values Added
First Time appeared Apache
Apache camel
Vendors & Products Apache
Apache camel

Mon, 24 Aug 2026 16:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Apache Camel: 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
Weaknesses CWE-20
References

cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-08-26T18:47:32.653Z

Reserved: 2026-08-24T09:47:36.708Z

Link: CVE-2026-78329

cve-icon Vulnrichment

Updated: 2026-08-26T18:46:51.567Z

cve-icon NVD

Status : Analyzed

Published: 2026-08-24T17:18:20.230

Modified: 2026-08-27T18:19:40.410

Link: CVE-2026-78329

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-26T22:30:04Z

Weaknesses
  • CWE-20

    Improper Input Validation