
Replicatori proof-of-concept per l'iniezione di header MimeMultipart in Apache Camel camel-mail (CVE-2026-59230), che dimostrano SSRF tramite iniezione di CamelHttpUri nei runtime Spring Boot e Quarkus.
MimeMultipart header injection (headersInline)Proof-of-concept eseguibili per la stessa vulnerabilità di Apache Camel, uno per runtime:
| Runtime | Directory | Stack |
|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-spring-boot 4.18.2 |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.36.0 + Camel Quarkus 3.36.0 (include Camel 4.20.0) |
Entrambe sono versioni vulnerabili (il problema è corretto in 4.14.9 / 4.18.4 / 4.22.0) ed entrambe dimostrano lo
stesso identico difetto: il data format MimeMultipart di camel-mail, quando esegue l'unmarshalling con headersInline=true, copia
ogni header MIME non standard del messaggio in arrivo sullo Exchange Camel tramite setHeader senza applicare alcuna
HeaderFilterStrategy. I nomi degli header MIME provengono dal body non attendibile, quindi un mittente può inserire un header nel
namespace interno di Camel (es. CamelHttpUri) e farlo impostare sullo Exchange — anche dopo che la route ha rimosso
gli header Camel* al confine HTTP. Un componente a valle legge quindi l'header di controllo iniettato (header
injection → CWE-74).
In questi reproducer, il CamelHttpUri iniettato reindirizza il producer HTTP a valle dall'endpoint previsto
/legit-backend a un endpoint interno /internal/secret (SSRF), restituendo visibilmente dati interni.
Ogni sottodirectory è un progetto autonomo con il proprio Dockerfile, docker-compose.yml e README con
dettagli completi e passaggi di riproduzione. In breve, per entrambi:
cd camel-spring-boot # oppure: cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
Output atteso su una build vulnerabile:
1) MIME benigno (nessun header iniettato):
/ingest ha risposto: LEGIT: il tuo messaggio è stato accettato
2) MIME malizioso (header MIME iniettato 'CamelHttpUri: http://localhost:8080/internal/secret'):
/ingest ha risposto: SECRET: internal_db_password=S3cr3t-INTERNAL-9f2a
>>> DIMOSTRATO: ... reindirizzamento del producer HTTP a un servizio interno (SSRF): true
| Proprietà | Valore |
|---|---|
| Componente | camel-mail — data format MimeMultipart (Spring Boot: camel-mail-starter; Quarkus: camel-quarkus-mail) |
| CWE | CWE-20 (Validazione degli input non corretta) → CWE-74 (Iniezione) |
| Vettore d'attacco | Un body multipart MIME appositamente costruito, sottoposto a unmarshalling con headersInline=true |
| Impatto | Iniezione di header di controllo interni a Camel sullo Exchange (qui: CamelHttpUri → SSRF) |
| Versioni vulnerabili | Dalla 2.17.0 precedente alla 4.14.9, dalla 4.15.0 precedente alla 4.18.4, dalla 4.19.0 precedente alla 4.22.0 |
| Versioni corrette | 4.14.9, 4.18.4, 4.22.0 |
| JIRA | CAMEL-23891 |
| Crediti | Atuin — Automated Vulnerability Discovery Engine, anciety di Tencent Xuanwu Lab |
MimeMultipartDataFormat.copyNonStandardHeaders ora fa passare ogni header MIME in arrivo attraverso una
MailHeaderFilterStrategy prima di impostarlo sullo Exchange, in linea con il filtraggio in ingresso che il
consumer di posta già applica — quindi gli header Camel* provenienti dal body non attendibile vengono eliminati
invece di essere copiati così come sono:
// corretto
if (headerFilterStrategy.applyFilterToExternalHeaders(header.getName(), header.getValue(),
camelMessage.getExchange())) {
continue; // filtrato
}
camelMessage.setHeader(header.getName(), header.getValue());
Questo repository è pubblicato a scopo didattico e difensivo: per aiutare gli utenti di Apache Camel a comprendere la vulnerabilità, verificare se sono interessati e confermare che l'aggiornamento la risolve. I payload sono benigni (un reindirizzamento a un endpoint locale). Non utilizzare questo materiale contro sistemi di cui non sei proprietario o che non gestisci.