CVE-2026-78329 (GCVE-0-2026-78329)

Vulnerability from cvelistv5 – Published: 2026-08-24 16:22 – Updated: 2026-08-26 18:47
VLAI
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 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.
Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
SSVC
Exploitation: none Automatable: yes Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-26 18:47 UTC
CWE
  • CWE-20 - Improper input validation
Assigner
apache CNA under the mitre root
CNA scorecard B 76/100 over 943 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
Apache Software Foundation Apache Camel Affected: 4.11.0 , < 4.14.9 (semver)
Affected: 4.15.0 , < 4.18.4 (semver)
Affected: 4.19.0 , < 4.22.0 (semver)
guessed Create a notification for this product.
Credits
Andrea Cosentino from Apache Software Foundation Barak Srour from Apiiro Andrea Cosentino from Apache Software Foundation
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "HIGH",
              "baseScore": 9.8,
              "baseSeverity": "CRITICAL",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "HIGH",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-78329",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-26T18:47:09.326728Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-26T18:47:32.653Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-undertow",
          "packageURL": "pkg:maven/org.apache.camel/camel-undertow",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.14.9",
              "status": "affected",
              "version": "4.11.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.18.4",
              "status": "affected",
              "version": "4.15.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.22.0",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Andrea Cosentino from Apache Software Foundation"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "Barak Srour from Apiiro"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino from Apache Software Foundation"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eImproper input validation vulnerability in Apache Camel Undertow component.\u003c/p\u003e\u003cp\u003eThis 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.\u003c/p\u003e\u003cp\u003eUndertowEndpoint 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.\u003c/p\u003e\u003cp\u003eUsers 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(\u201cwebsocket.*\u201d). 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.\u003c/p\u003e"
            }
          ],
          "value": "Improper input validation vulnerability in Apache Camel Undertow component.\n\n\n\nThis 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.\n\n\n\nUndertowEndpoint 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.\n\n\n\nUsers 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(\u201cwebsocket.*\u201d). 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."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual severity rating"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper input validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-24T16:22:17.528Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-78329.html"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "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",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-78329",
    "datePublished": "2026-08-24T16:22:17.528Z",
    "dateReserved": "2026-08-24T09:47:36.708Z",
    "dateUpdated": "2026-08-26T18:47:32.653Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-78329",
      "date": "2026-10-17",
      "epss": "0.00738",
      "percentile": "0.53663"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "collectionURL": "https://repo.maven.apache.org/maven2",
                "defaultStatus": "unaffected",
                "packageName": "org.apache.camel:camel-undertow",
                "packageURL": "pkg:maven/org.apache.camel/camel-undertow",
                "product": "Apache Camel",
                "vendor": "Apache Software Foundation",
                "versions": [
                  {
                    "lessThan": "4.14.9",
                    "status": "affected",
                    "version": "4.11.0",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.18.4",
                    "status": "affected",
                    "version": "4.15.0",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.22.0",
                    "status": "affected",
                    "version": "4.19.0",
                    "versionType": "semver"
                  }
                ]
              }
            ],
            "source": "security@apache.org"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "262D2560-E9A1-4859-BC15-B702606603B6",
                    "versionEndExcluding": "4.14.9",
                    "versionStartIncluding": "4.11.0",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "7BC98A81-8301-4163-A47E-C6A9332A2454",
                    "versionEndExcluding": "4.18.4",
                    "versionStartIncluding": "4.15.0",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "10DE8B35-C125-4461-A7F7-3BDA3E3CB316",
                    "versionEndExcluding": "4.22.0",
                    "versionStartIncluding": "4.19.0",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "Improper input validation vulnerability in Apache Camel Undertow component.\n\n\n\nThis 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.\n\n\n\nUndertowEndpoint 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.\n\n\n\nUsers 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(\u201cwebsocket.*\u201d). 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."
          },
          {
            "lang": "es",
            "value": "Vulnerabilidad de validaci\u00f3n de entrada incorrecta en el componente Undertow de Apache Camel.\n\nEste problema afecta a Apache Camel: desde 4.11.0 antes de 4.14.9, desde 4.15.0 antes de 4.18.4, desde 4.19.0 antes de 4.22.0.\n\nUndertowEndpoint estableci\u00f3 por defecto su campo headerFilterStrategy a la HttpHeaderFilterStrategy base y empuj\u00f3 esa instancia en el UndertowHttpBinding que crea de forma perezosa, sobrescribiendo la UndertowHeaderFilterStrategy que DefaultUndertowHttpBinding instala en su propio constructor. A menos que una implementaci\u00f3n suministrara un binding personalizado o una headerFilterStrategy expl\u00edcita, el filtrado espec\u00edfico de undertow, por lo tanto, nunca se ejecut\u00f3 en rutas configuradas por el endpoint: el objeto de estrategia fue construido e inmediatamente reemplazado antes de que pudiera ser consultado. La consecuencia es que el prefijo de cabecera de intercambio websocket. heredado no fue filtrado en el l\u00edmite de transporte de undertow en ninguna direcci\u00f3n, por lo que un consumidor HTTP de undertow mape\u00f3 las cabeceras de cable entrantes de esa forma en el Exchange, donde un productor WebSocket de undertow las lee como directivas de despacho y puede ser hecho para entregarlas a un par diferente al seleccionado por la ruta; y los nombres de cabecera que undertow mismo no acepta fueron mapeados en el Exchange en lugar de ser omitidos. Los consumidores de Rest DSL nunca se vieron afectados, porque UndertowComponent asigna UndertowRestHeaderFilterStrategy expl\u00edcitamente, que extiende la estrategia de undertow. Esto no es una regresi\u00f3n de CVE-2025-30177: la HttpHeaderFilterStrategy base configura el filtro de prefijo Camel entrante en s\u00ed misma, por lo que la protecci\u00f3n introducida por ese aviso continu\u00f3 funcionando a trav\u00e9s de la clase base y nunca se perdi\u00f3. Lo que hizo el cambio fue dejar la estrategia de undertow hu\u00e9rfana en la ruta del endpoint, con el efecto de que dos correcciones posteriores escritas en ella - una omitiendo nombres de cabecera que undertow rechaza, una filtrando el prefijo websocket. heredado en ambas direcciones - fueron aplicadas a una clase que el endpoint ya no usaba y nunca tuvieron efecto en las versiones que las incluyeron.\n\nSe recomienda a los usuarios actualizar a la versi\u00f3n 4.22.0, que corrige el problema. Si los usuarios est\u00e1n en la rama de versiones LTS 4.14.x, entonces se les sugiere actualizar a 4.14.9. Si los usuarios est\u00e1n en la rama de versiones 4.18.x, entonces se les sugiere actualizar a 4.18.4. Para implementaciones que no pueden actualizarse inmediatamente, configure la estrategia expl\u00edcitamente en lugar de depender de la predeterminada, por ejemplo, vinculando una UndertowHeaderFilterStrategy en el registro y referenci\u00e1ndola en el endpoint como undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, y adicionalmente elimine las cabeceras de despacho en el l\u00edmite de confianza con removeHeaders(\u0027websocket.*\u0027). Tenga en cuenta una limitaci\u00f3n residual que la actualizaci\u00f3n no elimina: el componente undertow mantiene deliberadamente los valores websocket. como parte de su contrato de API visible externamente, y UndertowProducer los lee con in.getHeader, que no consulta ninguna HeaderFilterStrategy en absoluto. El filtrado restaurado es, por lo tanto, una defensa en profundidad solo en el l\u00edmite de transporte de undertow. Una ruta que transporta un mensaje no confiable desde un consumidor que no es de undertow a un productor de undertow no est\u00e1 protegida por esta correcci\u00f3n y debe eliminar esas cabeceras por s\u00ed misma."
          }
        ],
        "id": "CVE-2026-78329",
        "lastModified": "2026-10-12T15:10:00.207",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 9.8,
                "baseSeverity": "CRITICAL",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 5.9,
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-78329",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "yes"
                  },
                  {
                    "technicalImpact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-26T18:47:09.326728Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-08-24T17:18:20.230",
        "references": [
          {
            "source": "security@apache.org",
            "tags": [
              "Mailing List",
              "Vendor Advisory"
            ],
            "url": "https://camel.apache.org/security/CVE-2026-78329.html"
          }
        ],
        "sourceIdentifier": "security@apache.org",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-20"
              }
            ],
            "source": "security@apache.org",
            "type": "Secondary"
          }
        ]
      }
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "cvssV3_1": {
                  "attackComplexity": "LOW",
                  "attackVector": "NETWORK",
                  "availabilityImpact": "HIGH",
                  "baseScore": 9.8,
                  "baseSeverity": "CRITICAL",
                  "confidentialityImpact": "HIGH",
                  "integrityImpact": "HIGH",
                  "privilegesRequired": "NONE",
                  "scope": "UNCHANGED",
                  "userInteraction": "NONE",
                  "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                  "version": "3.1"
                }
              },
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-78329",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "yes"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-08-26T18:47:09.326728Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-08-26T18:46:51.567Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "collectionURL": "https://repo.maven.apache.org/maven2",
              "defaultStatus": "unaffected",
              "packageName": "org.apache.camel:camel-undertow",
              "packageURL": "pkg:maven/org.apache.camel/camel-undertow",
              "product": "Apache Camel",
              "vendor": "Apache Software Foundation",
              "versions": [
                {
                  "lessThan": "4.14.9",
                  "status": "affected",
                  "version": "4.11.0",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.18.4",
                  "status": "affected",
                  "version": "4.15.0",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.22.0",
                  "status": "affected",
                  "version": "4.19.0",
                  "versionType": "semver"
                }
              ]
            }
          ],
          "credits": [
            {
              "lang": "en",
              "type": "finder",
              "value": "Andrea Cosentino from Apache Software Foundation"
            },
            {
              "lang": "en",
              "type": "finder",
              "value": "Barak Srour from Apiiro"
            },
            {
              "lang": "en",
              "type": "remediation developer",
              "value": "Andrea Cosentino from Apache Software Foundation"
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "\u003cp\u003eImproper input validation vulnerability in Apache Camel Undertow component.\u003c/p\u003e\u003cp\u003eThis 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.\u003c/p\u003e\u003cp\u003eUndertowEndpoint 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.\u003c/p\u003e\u003cp\u003eUsers 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(\u201cwebsocket.*\u201d). 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.\u003c/p\u003e"
                }
              ],
              "value": "Improper input validation vulnerability in Apache Camel Undertow component.\n\n\n\nThis 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.\n\n\n\nUndertowEndpoint 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.\n\n\n\nUsers 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(\u201cwebsocket.*\u201d). 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."
            }
          ],
          "metrics": [
            {
              "other": {
                "content": {
                  "text": "moderate"
                },
                "type": "Textual severity rating"
              },
              "scenarios": [
                {
                  "lang": "en",
                  "value": "GENERAL"
                }
              ]
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-20",
                  "description": "CWE-20 Improper input validation",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-08-24T16:22:17.528Z",
            "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
            "shortName": "apache"
          },
          "references": [
            {
              "tags": [
                "vendor-advisory"
              ],
              "url": "https://camel.apache.org/security/CVE-2026-78329.html"
            }
          ],
          "source": {
            "discovery": "UNKNOWN"
          },
          "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",
          "x_generator": {
            "engine": "Vulnogram 1.0.3"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "assignerShortName": "apache",
        "cveId": "CVE-2026-78329",
        "datePublished": "2026-08-24T16:22:17.528Z",
        "dateReserved": "2026-08-24T09:47:36.708Z",
        "dateUpdated": "2026-08-26T18:47:32.653Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.