Impact
Apache Camel Mail accepts headers prefixed with mail.smtp. or mail.smtps. from an incoming Exchange and injects them as JavaMail session properties on a per‑message basis, bypassing internal validation. In versions prior to 4.19.0 this allows an attacker to set mail.smtp.host to an arbitrary SMTP server, causing the producer to use the configured username and password and deliver them to the attacker. In 4.19.0 and later the host override is disabled, but an attacker can still weaken transport security by manipulating properties such as mail.smtp.ssl.trust, mail.smtp.starttls.enable, or mail.smtp.socks.host, or intercept the message content.
Affected Systems
The flaw affects the Apache Camel Mail component from the Apache Software Foundation in all releases 4.0.0 through 4.14.8, 4.15.0 through 4.18.3, and 4.19.0 through 4.21.0. Any Camel route that produces email via SMTP or SMTPS and does not strip the mail.smtp.* and mail.smtps.* headers from untrusted input is vulnerable.
Risk and Exploitability
The CVSS base score of 3.7 indicates low severity, and the EPSS score of less than 1 % indicates an extremely low likelihood of exploitation. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires untrusted data to reach the mail producer without header removal, which can occur through HTTP query parameters, JMS, or Kafka messages. In pre‑4.19.0 releases this can trigger credential leakage, while in 4.19.0 and later the impact is limited to transport security weakening or message interception. Overall risk remains low, but the potential for credential exposure warrants prompt remediation.
OpenCVE Enrichment