CVE-2026-46428

lettre is a a mailer library for Rust. Starting in version 0.10.1 and prior to version 0.11.22, 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. Version 0.11.22 patches the issue.

lettre is a a mailer library for Rust. Starting in version 0.10.1 and prior to version 0.11.22, 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. Version 0.11.22 patches the issue.

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::set_verify_hostname(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.set_verify_hostname) lettre's TlsParametersBuilder exposes the opposite-named flag accept_invalid_hostnames: 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) .verify_hostname(*accept_invalid_hostnames) src/transport/smtp/client/async_net.rs:377 (async) config.set_verify_hostname(accept_invalid_hostnames); Concrete behaviour under boring-tls:

• accept_invalid_hostnames = false (the strict default) → set_verify_hostname(false) → hostname verification SKIPPED (wrong; the caller asked for strict verification)
• accept_invalid_hostnames = true (explicit opt-in to "dangerous") → set_verify_hostname(true) → hostname verification ENFORCED (wrong; the caller opted into accepting any name) Boring's own warning on set_verify_hostname: "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 danger_accept_invalid_hostnames(self.accept_invalid_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 accept_invalid_hostnames 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:
  • .verify_hostname(*accept_invalid_hostnames)
  • .verify_hostname(!*accept_invalid_hostnames)
  • config.set_verify_hostname(accept_invalid_hostnames);
  • config.set_verify_hostname(!accept_invalid_hostnames); 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).
2. 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.
3. 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…

lettre is a a mailer library for Rust. Starting in version 0.10.1 and prior to version 0.11.22, 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. Version 0.11.22 patches the issue.

lettre is a a mailer library for Rust. Starting in version 0.10.1 and prior to version 0.11.22, 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. Version 0.11.22 patches the issue.

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::set_verify_hostname(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.set_verify_hostname) lettre's TlsParametersBuilder exposes the opposite-named flag accept_invalid_hostnames: 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) .verify_hostname(*accept_invalid_hostnames) src/transport/smtp/client/async_net.rs:377 (async) config.set_verify_hostname(accept_invalid_hostnames); Concrete behaviour under boring-tls:

• accept_invalid_hostnames = false (the strict default) → set_verify_hostname(false) → hostname verification SKIPPED (wrong; the caller asked for strict verification)
• accept_invalid_hostnames = true (explicit opt-in to "dangerous") → set_verify_hostname(true) → hostname verification ENFORCED (wrong; the caller opted into accepting any name) Boring's own warning on set_verify_hostname: "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 danger_accept_invalid_hostnames(self.accept_invalid_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 accept_invalid_hostnames 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:
  • .verify_hostname(*accept_invalid_hostnames)
  • .verify_hostname(!*accept_invalid_hostnames)
  • config.set_verify_hostname(accept_invalid_hostnames);
  • config.set_verify_hostname(!accept_invalid_hostnames); 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).
2. 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.
3. 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…

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.

The bug was introduced in v0.10.1 and persists through v0.11.21 (latest).