Which versions of lettre are affected by CVE-2026-46428?

The lettre Rust mailer library (versions 0.10.1-0.11.21 using boring-tls) contains a critical TLS hostname verification bypass enabling man-in-the-middle attacks on SMTP connections.. A patch is available.

How to fix or mitigate CVE-2026-46428?

Within 24 hours: identify all systems and applications using lettre versions 0.10.1 through 0.11.21 with boring-tls feature enabled, and assess criticality of affected email workflows. Within 7 days: upgrade lettre to the patched version per vendor advisory, validate boring-tls configuration post-upgrade, and verify SMTP hostname verification is properly enforced. Within 30 days: complete email functionality regression testing, document all affected systems and remediation status in your asset registry, and confirm TLS certificate validation is functioning correctly.

lettre CVE-2026-46428

Q: What is the CVSS score of CVE-2026-46428?

CVE-2026-46428 has a CVSS 4.0 base score of 9.1 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

EUVD-2026-45982 CRITICAL

Improper Certificate Validation (CWE-295)

2026-07-20 GitHub_M

GHSA-4pj9-g833-qx53

Information Disclosure Lettre

9.1

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

9.1 CRITICAL

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.4 HIGH

AC:H because a man-in-the-middle position is required; PR:N/UI:N as no auth or victim action is needed; C:H/I:H for exposed credentials/contents and message tampering, A:N.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 20, 2026 - 17:53 vuln.today

Analysis Generated

Jul 20, 2026 - 17:53 vuln.today

Patch available

Jul 20, 2026 - 17:02 EUVD

CVE Published

Jul 20, 2026 - 15:37 cve.org

CRITICAL 9.1

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

19 cargo packages depend on lettre (15 direct, 4 indirect)

Ecosystem-wide dependent count for version 0.10.1.

DescriptionCVE.org

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.

AnalysisAI

TLS hostname verification bypass in the lettre Rust mailer library (0.10.1 through 0.11.21) exposes users of the boring-tls feature to man-in-the-middle attacks; an inverted boolean caused the default strict configuration to silently disable hostname checking. An on-path attacker holding any chain-valid certificate for any domain can transparently intercept SMTP submission, harvesting PLAIN/LOGIN credentials and full message contents. There is no public exploit identified at time of analysis, but the one-line root cause is visible in the public fix commit, making the flaw trivially understandable; native-tls and rustls backends are not affected.

Technical ContextAI

lettre is the de-facto SMTP client library for the Rust ecosystem, and this issue lives in its optional boring-tls backend (an integration with Google's BoringSSL via the boring crate). The root cause is CWE-295 (Improper Certificate Validation): in both the sync (net.rs) and async (async_net.rs) transports, the code passed the user's accept_invalid_hostnames flag directly into set_verify_hostname()/verify_hostname() instead of its negation. Because the boring API expects a 'verify hostname' boolean, feeding it the 'accept invalid hostnames' value inverted the meaning - with the default accept_invalid_hostnames=false, verification was set to false, disabling the check entirely while callers believed they were in strict mode. Certificate chain validation still occurred, so only the hostname-to-certificate binding was broken, which is precisely what lets any valid-but-mismatched certificate pass.

RemediationAI

Vendor-released patch: 0.11.22 - upgrade the lettre dependency to >= 0.11.22 (release: https://github.com/lettre/lettre/releases/tag/v0.11.22, fix commit f5efffc88360dbdbfcef80f465e42d5bce68ca35). This is the correct and complete remediation and should be applied by anyone using the boring-tls feature. As an interim measure until you can upgrade, switch the TLS backend to rustls or native-tls, which are unaffected - the trade-off is a dependency/feature change and a rebuild rather than a code change. If neither is possible immediately, restrict SMTP submission to trusted network paths (e.g., a fixed relay reachable only over a VPN or private link) so that no on-path attacker can interpose; this reduces exposure but does not restore hostname verification and adds operational/network constraints. Do not rely on rotating credentials alone, since message contents are also exposed. Advisory: https://github.com/lettre/lettre/security/advisories/GHSA-4pj9-g833-qx53.