CVE-2026-46428: lettre has TLS hostname verification disabled when using Boring TLS backend

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• Not in CISA KEV, but CISA’s SSVC assessment records a public proof-of-concept, so attack code exists.
• EPSS 0.3%, percentile 24: FIRST’s model estimates a 0.3% chance of exploitation activity in the next 30 days, higher than 24% of all scored CVEs (low). EPSS is a probability, not a verdict.
• Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
• Only applies if your dependency tree includes lettre (crates.io (Rust)) >= 0.10.1, < 0.11.22, fixed in 0.11.22. Check your lockfile, including transitive dependencies.

What it is

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.

From the GitHub advisory

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) / verifyhostname(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(acceptinvalidhostnames) src/transport/smtp/client/asyncnet.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.acceptinvalidhostnames), 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…

Weakness type: CWE-295.

Product: lettre (crates.io (Rust)) · Assigned by: GitHub_M · Published: 2026-07-20

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Attack requirements: present (depends on deployment conditions)
• Privileges required: none (no login)
• User interaction: none

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation poc, automatable no, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.32% probability of exploitation activity in the next 30 days; percentile 24.

Timeline

• 2026-07-20 — CVE record published by GitHub_M
• 2026-07-21 — CVE record last updated
• 2026-07-28 — GitHub-reviewed advisory GHSA-4pj9-g833-qx53 published (critical)

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-4pj9-g833-qx53 github.com
2. CVE.org record CVE-2026-46428 cve.org
3. NVD entry CVE-2026-46428 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com
3. github.com github.com
4. rustsec.org rustsec.org

Critical crates.io (Rust) advisories · Today’s Security Digest