Both are affected versions (fixed in 4.14.8 / 4.18.3 / 4.21.0), and both demonstrate the identical defect: the mail producer's getSender() folds any inbound mail.smtp.* message header into the JavaMail session before connecting. Those names are bare, non-Camel-prefixed strings, so the HTTP boundary filter (HttpHeaderFilterStrategy, which strips only Camel*) lets an unauthenticated HTTP client set them. Two extra request headers (mail.smtp.socks.host / mail.smtp.socks.port) tunnel the victim's authenticated SMTP connection through an attacker-controlled SOCKS proxy, which harvests the plaintext AUTH LOGIN credentials — while the victim's send still succeeds, so the interception is silent.

Each subdirectory is a self-contained project with its own Dockerfile, docker-compose.yml, and README — the "legit" SMTP server and the attacker's SOCKS proxy both run in-JVM, so no external service is required. In short, for either:

Vulnerability Summary

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

Disclaimer

These reproducers are provided for security research and authorized testing only, for a publicly disclosed and fixed vulnerability. Do not use them against systems without explicit permission.