SecBoard
Zurück zur CVE-Übersicht

CVE-2026-78329

CRITICAL(9.8)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Risk Signal Score25/100 — MITTEL
  • CVSS 9.8 — Kritisch

Erwähnungen (letzte 60 Tage)

Artikel

EPSS-Score

0.4%

Exploit-Wahrscheinlichkeit (30 Tage)

CVSS Score

9.8

Technische Schwere

Beschreibung

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.

Erkennung & Indikatoren

Ausnutzung

In den geprüften Quellen nicht genannt

Behobene Versionen

  • 4.14.9
  • 4.18.4
  • 4.22.0

Threat-Hunting-Queries

Diese Schwachstelle betrifft die Header-Filterstrategie in Apache Camel Undertow. Eine Verhaltenserkennung könnte versuchen, ungewöhnliche oder nicht gefilterte Header-Nutzung in Apache Camel-Anwendungen zu identifizieren, insbesondere solche, die mit 'websocket.' beginnen oder Header-Namen verwenden, die Undertow normalerweise ablehnen würde. Dies erfordert jedoch tiefgreifende Kenntnisse der Anw

Sentinel/Defender KQL

DeviceProcessEvents
| where FileName contains "java" or ProcessCommandLine contains "camel" or ProcessCommandLine contains "undertow"
| where RemotePort != "" // Beispiel: Überwachung von Netzwerkverbindungen
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, RemoteIP, RemotePort, Protocol
// Weitere Filter für ungewöhnliche Header-Nutzung in Logs der Anwendung selbst wären hier ideal, sind aber generisch schwer abbildbar.

Splunk SPL

index=your_apache_camel_logs sourcetype=your_undertow_logs
| regex _raw="websocket\..*" OR regex _raw="(header_name_undertow_rejects)" // Platzhalter für Header-Namen, die Undertow ablehnen würde
| table _time, host, source, _raw
// Dies ist ein generischer Ansatz. Spezifische Log-Formate und Header-Namen müssten angepasst werden.

Sigma

title: Apache Camel Undertow Header Filter Bypass Attempt
id: 00000000-0000-0000-0000-000000000000
status: experimental
description: Detects potential attempts to bypass header filtering in Apache Camel Undertow by observing unusual header patterns.
author: SecBoard
date: 2024/07/30
logsource:
  product: apache
  service: camel
detection:
  selection:
    - message|contains: 'websocket.'
    - message|contains: 'X-Undertow-Invalid-Header'
  condition: selection
level: medium

Elastic ES|QL

from logs-apache.camel-*
| where message : "websocket." or message : "X-Undertow-Invalid-Header" // Platzhalter für ungewöhnliche Header
| limit 100

SecBoard-generated · behavioral · requires customizationVon SecBoard erzeugt und nicht in einer Zielumgebung validiert. Vor dem Einsatz an die eigene Protokollierung anpassen.

Betroffene Produkte

  • cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*
  • cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*
  • cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*

GitHub Advisories

GHSA-v7h8-xhh6-gfj4CRITICAL

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

maven/org.apache.camel:camel-undertow4.14.9
GitHub Advisory

Referenzen