CVE-2026-78329

{"id": "CVE-2026-78329", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-78329", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "yes"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-08-26T18:47:09.326728Z"}}], "cvssMetricV31": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.8, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 3.9}]}, "affected": [{"source": "security@apache.org", "affectedData": [{"vendor": "Apache Software Foundation", "product": "Apache Camel", "versions": [{"status": "affected", "version": "4.11.0", "lessThan": "4.14.9", "versionType": "semver"}, {"status": "affected", "version": "4.15.0", "lessThan": "4.18.4", "versionType": "semver"}, {"status": "affected", "version": "4.19.0", "lessThan": "4.22.0", "versionType": "semver"}], "packageURL": "pkg:maven/org.apache.camel/camel-undertow", "packageName": "org.apache.camel:camel-undertow", "collectionURL": "https://repo.maven.apache.org/maven2", "defaultStatus": "unaffected"}]}], "published": "2026-08-24T17:18:20.230", "references": [{"url": "https://camel.apache.org/security/CVE-2026-78329.html", "tags": ["Mailing List", "Vendor Advisory"], "source": "security@apache.org"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Secondary", "source": "security@apache.org", "description": [{"lang": "en", "value": "CWE-20"}]}], "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('websocket.*'). 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."}], "lastModified": "2026-10-12T15:10:00.207", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "262D2560-E9A1-4859-BC15-B702606603B6", "versionEndExcluding": "4.14.9", "versionStartIncluding": "4.11.0"}, {"criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "7BC98A81-8301-4163-A47E-C6A9332A2454", "versionEndExcluding": "4.18.4", "versionStartIncluding": "4.15.0"}, {"criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "10DE8B35-C125-4461-A7F7-3BDA3E3CB316", "versionEndExcluding": "4.22.0", "versionStartIncluding": "4.19.0"}], "operator": "OR"}]}], "sourceIdentifier": "security@apache.org"}