Inverted TLS Hostname Verification in lettre's boring-tls Backend Enables SMTP MitM (CVE-2026-46428)

What happened

A GitHub Security Advisory (GHSA-4pj9-g833-qx53, CVE-2026-46428) reports an inverted-boolean bug in the Rust lettre email library's boring-tls backend. According to the advisory, lettre's accept_invalid_hostnames flag is passed directly to boring's set_verify_hostname() API without negation, at two call sites (src/transport/smtp/client/net.rs:202 and src/transport/smtp/client/async_net.rs:377). Since boring's flag means "verify" while lettre's flag means "accept invalid," the semantics are reversed: callers using the default, strict configuration (accept_invalid_hostnames = false) actually get hostname verification disabled. The report states this affects every released version with the boring-tls feature, from v0.10.1 through the latest v0.11.21, and that native-tls and rustls backends are unaffected. A PoC and a two-line fix are described in the advisory; exploit status is listed as PoC-public.

Why it matters

Per the advisory, any application built with lettre's boring-tls feature and relying on default-strict TLS is silently exposed to on-path interception, despite believing hostname checks are enforced. An attacker positioned on the network path who holds any chain-valid certificate for a domain they control — a free CA-issued cert is sufficient — can present it during the STARTTLS/implicit-TLS handshake to a lettre client and have it accepted. The advisory describes resulting exposure of SMTP envelope data, message bodies/attachments, and SMTP AUTH credentials (PLAIN/LOGIN/CRAM-MD5), with high confidentiality/integrity impact. This is notable because the affected population is specifically the users who explicitly asked for strict verification and did nothing wrong — the bug is invisible from calling code.

What defenders should do now

• Inventory Rust services and internal tooling that send mail via lettre, and check whether the boring-tls feature is enabled (vs. native-tls or rustls, which the advisory states are unaffected).
• Until an upstream fix ships, consider pinning to or switching the TLS backend feature to native-tls or rustls for affected builds, per the advisory's stated mitigation path.
• For SMTP infrastructure you control, monitor for TLS handshakes where the certificate SAN does not match the intended MX hostname — the advisory notes Cloudflare's email-fwdr mitigated a related issue by hard-failing on post-handshake SAN mismatches.
• Review logs/telemetry for anomalous SMTP relay endpoints, unexpected certificate issuers on mail submission paths, or credential reuse patterns that could indicate prior interception.
• Track the upstream patch (a two-line negation of the flag at the two call sites named in the advisory) and prioritize upgrading once released.

Developing intel

This is a same-day advisory and the fix has not yet shipped in a released lettre version as of this writing; details may be updated by the maintainers. For the full technical writeup, PoC, and patch discussion, see the original advisory: GHSA-4pj9-g833-qx53.