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
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 itse
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-78329
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 6 Nov 2026, 01:33 UTC · Revision 1
Source evidence
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
core-osv · Original sourcePublished 24 Aug 2026, 16:22 UTC
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 itse
osv:CVE-2026-78329
Complete source record
{
"id": "5e911c04c99c35395ccb17aa6b1ef3387a16c3e83f94c99662052ad71ac5f633",
"url": "https://osv.dev/vulnerability/CVE-2026-78329",
"method": "structured",
"payload": {
"kind": "advisory",
"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",
"summary": "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 itse",
"evidence": "osv:CVE-2026-78329",
"products": [],
"severity": "critical",
"structured": {
"id": "CVE-2026-78329",
"aliases": [
"CVE-2026-78329",
"GHSA-v7h8-xhh6-gfj4"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/apache/camel",
"type": "GIT",
"events": [
{
"introduced": "7b67c915f082ff670541bec58b11e8098e2723d1"
},
{
"fixed": "65a5006348be3c4543cf722466c62c7947cc4f3b"
},
{
"introduced": "038f1b2acd0b2ee78e4bb84cd3139e64610bb259"
},
{
"fixed": "db322df8384554f65000afdce120a26c2e942617"
},
{
"introduced": "3e9f3011ad48de66fef582ade9794c7340c23af7"
},
{
"fixed": "1a54683f4becad3b32df42507e709526d8563f35"
}
],
"database_specific": {
"extracted_events": [
{
"cpe": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "4.11.0"
},
{
"fixed": "4.14.9"
}
],
"source": "CPE_RANGE"
},
{
"cpe": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.4"
}
],
"source": "CPE_RANGE"
},
{
"cpe": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.22.0"
}
],
"source": "CPE_RANGE"
}
]
}
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-78329.json"
}
}
],
"modified": "2026-10-28T02:30:45.771705008Z",
"provider": "osv",
"references": [
"https://repo.maven.apache.org/maven2",
"https://camel.apache.org/security/CVE-2026-78329.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/78xxx/CVE-2026-78329.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-78329"
],
"provider_metadata": {
"cwe_ids": [
"CWE-20"
],
"cna_assigner": "apache",
"unresolved_ranges": [
{
"extracted_events": [
{
"range": [
{
"introduced": "4.11.0"
},
{
"fixed": "4.14.9"
},
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.4"
},
{
"introduced": "4.19.0"
},
{
"fixed": "4.22.0"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
}
]
}
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/78xxx/CVE-2026-78329.json"
}
},
"related_cves": [
{
"value": "CVE-2026-78329",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 513896,
"published_at": "2026-08-24T16:22:17.528+00:00"
}