RustSec flags critical lettre TLS flaw, exposes SMTP credentials to attackers

A single feature flag was enough to turn lettre’s encrypted SMTP transport into a trust failure. RustSec assigned the bug RUSTSEC-2026-0141, rated it CRITICAL with a CVSS score of 9.1, and tied it to the GitHub alias GHSA-4pj9-g833-qx53 after finding that lettre’s boring-tls backend disabled TLS hostname verification.

The failure matters because it breaks the core assumption behind SMTP submission over TLS. In affected builds, an on-path attacker who can present any chain-valid certificate for any domain can intercept traffic, and the advisory says that includes PLAIN and LOGIN credentials as well as message contents. That makes the bug especially dangerous for production mail paths that handle password resets, transactional messages, and notification flows, where a compromised submission channel can expose both secrets and the mail itself.

The scope is narrower than the headline might suggest, but it is still sharp. native-tls and rustls are unaffected, and the problem only appears when lettre is compiled with the boring-tls feature. The bug was introduced in v0.10.1 and persists through v0.11.21, which the advisory identified as the latest release when it was issued on May 14, 2026. The patched version is 0.11.22 or later. That version range makes Cargo.lock audits and feature checks just as important as semver upgrades, because a team can be on the newest compatible crate and still be carrying the vulnerable backend.

The underlying docs line up with the advisory’s warning. lettre’s SmtpTransport describes itself as the right option for most SMTP servers and says it creates an encrypted transport over the submissions port using the provided domain to validate TLS certificates. lettre’s TLS parameter docs warn that if hostname verification is disabled, any valid certificate, including one from another site, is trusted. The boring crate says the same thing in harsher terms: without hostname verification, any valid certificate for any site can be trusted from any other site, creating a significant MITM vulnerability.

For operators, the fastest mitigation is to upgrade to lettre 0.11.22 or newer and confirm the build is not pulling in boring-tls. If hostile network interference is a realistic concern, move to a safe backend rather than assuming encryption alone is enough. lettre’s SECURITY.md says security reports should be sent privately to security@lettre.rs, a reminder that this was not a memory-safety break so much as a configuration-level collapse of the trust boundary Rust mail senders thought they already had.