CVE-2026-46584: Apache Camel Mail Component Input Validation Vulnerability

Technical summary

The MailProducer.getSender method interprets Camel-internal mail.smtp.* and mail.smtps.* headers as JavaMail session properties, applying them per-message without validation or filtering. These namespaces are not enforced by HeaderFilterStrategy, allowing headers from untrusted inbound protocols (HTTP query parameters, request headers, JMS/Kafka messages) to propagate through routes and override SMTP endpoint configuration. On versions before 4.19.0, mail.smtp.host injection enables credential exfiltration by redirecting connections to attacker infrastructure. Versions 4.19.0+ lock the host to the configured endpoint, but mail.smtp.ssl.trust, mail.smtp.starttls.enable, and mail.smtp.socks.host remain exploitable for weakening TLS enforcement or routing through attacker proxies. Exploitation requires a route path that channels untrusted input to an SMTP producer without intervening header removal.

Business impact

Organizations using Apache Camel for email workflows face credential theft and message interception risks if routes accept external input without sanitization. On pre-4.19.0 deployments, SMTP credentials configured in Camel endpoints could be compromised and reused against email infrastructure. Even on patched versions, attackers can force cleartext email transmission or proxy mail through their infrastructure for espionage. The blast radius is limited to affected routes and depends entirely on architectural choices (whether untrusted data touches mail producers). Patched versions and correct mitigation reduce risk to negligible levels.

Affected systems

Apache Camel versions 4.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.x are affected. The 4.14.x, 4.18.x, and 4.21.0+ branches have fixes available. Any deployment using the camel-mail component in a route that processes external input is potentially vulnerable if no header filtering is in place. This includes integrations that route HTTP requests, message queue data, or third-party API responses to SMTP producers.

Exploitability

Exploitation is straightforward for attackers if the conditions align: a route must accept untrusted input and feed it directly to an SMTP producer without header filtering. The attack is passive—no user interaction or special privileges required—but assumes the attacker can control inbound data (e.g., query string parameters, message headers, or JMS payloads). The CVSS score of 3.7 (LOW) reflects the conditional nature of exploitation (requires specific route architecture) and the limited impact on patched versions (4.19.0+). However, organizations on legacy versions face higher practical risk due to credential exposure potential. The vulnerability is not known to be exploited in the wild.

Remediation

Upgrade to Apache Camel 4.21.0 (latest), 4.18.3 (4.18.x LTS), or 4.14.8 (4.14.x LTS). After patching, the mail.smtp.* / mail.smtps.* header override is disabled by default and must be explicitly enabled via useJavaMailSessionPropertiesFromHeaders=true only on trusted endpoints. For immediate mitigation on unpatched systems, insert removeHeaders('mail.smtp.*') and removeHeaders('mail.smtps.*') filters between any untrusted data source and the mail producer. This is a defense-in-depth measure even after upgrading, recommended for routes handling external input.

Patch guidance

Apply the latest version available for your branch: 4.21.0+ (current), 4.18.3+ (if on 4.18.x), or 4.14.8+ (if on 4.14.x LTS). Verify the patch version against the official Apache Camel release notes before deployment. Test in a staging environment to confirm email workflows remain functional. After patching, audit routes to identify any that explicitly enable useJavaMailSessionPropertiesFromHeaders=true and confirm such enablement is warranted. Reapply removeHeaders filters as a secondary control on all routes accepting external input.

Detection guidance

Monitor Camel route logs and metrics for unexpected changes to SMTP connection endpoints or TLS settings. Inspect route configurations in your Camel deployment to identify any that process external input without HeaderFilterStrategy or removeHeaders filters applied before mail producers. Check endpoint definitions for useJavaMailSessionPropertiesFromHeaders settings and verify they are only enabled where documented and necessary. Review inbound data sources (HTTP endpoints, message brokers) connected to SMTP producers for misconfiguration. Network detection is limited unless the attacker redirects to an external SMTP server; log SMTP connection attempts to unexpected hosts.

Why prioritize this

This vulnerability requires specific route architecture to exploit and is rated LOW severity. However, organizations on versions before 4.19.0 face credential exposure risk, which warrants timely patching regardless of the CVSS score. Patching is straightforward and low-risk. Prioritize based on whether your routes accept external input and feed it to mail producers without filtering; if so, upgrade immediately. If your routes only process trusted internal data, the risk is negligible, but patching is still recommended as a hygiene measure.

Risk score, explained

CVSS 3.7 (LOW) is driven by three factors: (1) the attack requires specific route architecture (AC:H—high complexity), (2) on patched versions the impact is limited to TLS weakening rather than credential theft (C:L—low confidentiality impact), and (3) no authentication is required but the attacker must control inbound data. The conditional nature of exploitation—most routes may not be vulnerable—and the fact that CISA has not flagged this as exploited in the wild keep the score low. For organizations with vulnerable route patterns, practical risk is higher than the CVSS score suggests.

Frequently asked questions