Skip to content
Heist/ feed
Back to feed
Critical

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

Type: advisorySources: OSV

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 source

Published 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"
}