CVE-2026-46428

Summary

An inverted-boolean bug in lettre's boring-tls integration silently

disables TLS hostname verification for callers using the default (strict)

configuration. An on-path attacker presenting any chain-valid certificate

for any domain can intercept SMTP submission, including PLAIN/LOGIN

credentials and message contents, against any lettre user built with the

boring-tls feature. Other TLS backends (native-tls, rustls) are

unaffected.

Details

boring's SslConnectorBuilder::setverifyhostname(bool) /

verify_hostname(bool) API takes a verify flag — true means enforce

hostname verification, false means skip it. (Boring docs:

https://docs.rs/boring/latest/boring/ssl/struct.ConnectConfiguration.html#method.setverifyhostname)

lettre's TlsParametersBuilder exposes the opposite-named flag

acceptinvalidhostnames: bool — true means accept invalid (skip

verification), false means verify. lettre passes this flag directly to

boring at both TLS-upgrade sites, inverting the semantics:

src/transport/smtp/client/net.rs:202 (sync)

    .verifyhostname(*acceptinvalid_hostnames)

src/transport/smtp/client/async_net.rs:377 (async)

    config.setverifyhostname(acceptinvalidhostnames);

Concrete behaviour under boring-tls:

• acceptinvalidhostnames = false  (the strict default)

      → setverifyhostname(false)  → hostname verification SKIPPED

        (wrong; the caller asked for strict verification)

• acceptinvalidhostnames = true   (explicit opt-in to "dangerous")

      → setverifyhostname(true)   → hostname verification ENFORCED

        (wrong; the caller opted into accepting any name)

Boring's own warning on setverifyhostname:

    "If hostname verification is not used, any valid certificate for

    any site will be trusted for use from any other. This introduces

    a significant vulnerability to man-in-the-middle attacks."

native-tls (src/transport/smtp/client/tls.rs:355) uses

dangeracceptinvalidhostnames(self.acceptinvalid_hostnames), whose

flag name and semantics match lettre's — unaffected. rustls uses a

separate verifier path — unaffected.

The bug was introduced in PR #797 ("Add support for boring TLS"), commit

985fa7e, first released in v0.10.1, and persists unchanged through v0.11.21

(latest). Zero existing tests cover acceptinvalidhostnames end-to-end

with any backend, which is why the inversion has gone undetected.

Fix: negate the flag at both call sites. Two-line patch:

• •    .verifyhostname(*acceptinvalid_hostnames)

    +    .verifyhostname(!*acceptinvalid_hostnames)

• •    config.setverifyhostname(acceptinvalidhostnames);

    +    config.setverifyhostname(!acceptinvalidhostnames);

I have the patch ready locally and can push to a private fork if a

collaborative fix branch is preferred.

PoC

Setup (any lettre version >= v0.10.1, built with the boring-tls

feature, default-strict configuration):

1. Generate a TLS cert for any hostname the attacker controls, e.g.

   attacker.example, signed by any CA in the client's trust store

   (e.g. a Let's Encrypt cert is sufficient).

1. Stand up an attacker SMTP server on the network path between the

   lettre client and the intended MX. Have it present the

   attacker.example cert on STARTTLS or implicit TLS.

1. Use lettre with default-strict TLS to send to the real MX hostname,

   e.g. mail.example.com:

       use lettre::transport::smtp::client::{Tls, TlsParameters};

       use lettre::{AsyncSmtpTransport, Tokio1Executor, Message};

       let tls = TlsParameters::builder("mail.example.com".to_owned())

           .build_boring()

           .unwrap();

       let mailer = AsyncSmtpTransport::<Tokio1Executor>::relay(

               "mail.example.com",

           )?

           .tls(Tls::Required(tls))

           .build();

       mailer.send(message).await?;     // succeeds against attacker

Expected with hostname verification: handshake fails because the

presented leaf cert's SAN does not match mail.example.com.

Actual on boring-tls: handshake succeeds. lettre proceeds with the

SMTP transaction, sending MAIL FROM, RCPT TO, message body, and any

configured SMTP AUTH credentials to the attacker.

Symmetric inverse PoC (proves the inversion, not just a missing check):

configure .dangerousacceptinvalid_hostnames(true) and try to connect

to a server whose cert SAN matches the connect domain. With the bug,

the handshake fails because lettre passes true to verify_hostname

and boring rejects... actually wait, it succeeds (SAN matches). Better

inverse demonstration: connect to a server whose cert SAN matches the

connect domain with acceptinvalidhostnames=true, then connect to a

mismatched-SAN server with the same flag — the latter is rejected,

proving the flag is inverted (the user opted into accepting any name,

yet lettre enforces strict verification).

A reproducer cargo project can be produced on request.

Impact

Who is impacted: any lettre user who

1. enables the boring-tls feature, AND
2. relies on default-strict hostname verification

     (i.e. does NOT call .dangerousacceptinvalid_hostnames(true)).

This is the entire "I want strict TLS" population on boring-tls. They

get the opposite of what they asked for: a TLS handshake that ignores

hostname mismatch.

Exploitation: an attacker on the network path between the lettre client

and the target SMTP server, holding any chain-valid TLS certificate

(e.g. a free Let's Encrypt cert for a domain the attacker owns), can

present that certificate when the lettre client connects to the intended

MX. boring accepts the handshake, lettre proceeds, and the attacker

gains read/write access to:

• SMTP envelope (MAIL FROM, RCPT TO)
• Message bodies, attachments, headers
• Any SMTP AUTH credentials (PLAIN, LOGIN, CRAM-MD5, etc.)
• Any DKIM signatures and DMARC alignment downstream depends on

    can be inspected and selectively dropped

Confidentiality and integrity impact: High. Availability impact: None

direct (the attacker can choose to forward or drop, but the bug itself

does not deny service).

Cloudflare's email-fwdr independently identified and mitigated this

downstream by promoting a previously-metric-only post-handshake SAN

check to a hard error (fix landed 2026-05-12). Because we're mitigated

downstream, we are not on a publication clock; we are reporting so the

upstream fix can ship and other lettre+boring-tls deployments can stop

relying on per-caller workarounds. Happy to coordinate on embargo

timing.

Affected versions: every released lettre version with boring-tls

support, from v0.10.1 (PR #797, commit 985fa7e) through v0.11.21

(latest). No prior advisory or fix.

Suggested fix: two-line negation of the flag at the boring call sites

(see Details). Patch is ready locally and can be attached to a private

collaboration fork.