GHSA-4pj9-g833-qx53: lettre has TLS hostname verification disabled when using Boring TLS backend
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
Details
Original advisory: https://github.com/advisories/GHSA-4pj9-g833-qx53
Exploitation outlook
EPSS (FIRST.org) estimates each CVE’s probability of exploitation in the next 30 days — here is the CSIRTS.com read on those numbers.
- Low exploitation riskCVE-2026-464280.19% 30-day exploitation probability — currently an unlikely target, but scores change as exploit code circulates. Riskier than 9% of all scored CVEs.
Referenced CVEs
| CVE | CSIRTS overview | External |
|---|---|---|
| CVE-2026-46428 | coverage & exploitation status | NVD · CVE.org |
Same CVEs, other sources
How other CERTs, PSIRTs and databases cover the vulnerabilities in this advisory.
More from GitHub Security Advisories
- mediumGHSA-jr6p-8pjj-mfx6: Capsule has an incomplete fix of CVE-2026-22872: TenantResource RawItems and Generators s…2026-07-31
- mediumGHSA-68cj-mvg9-rgm2: Capsule: CapsuleConfiguration NodeMetadata regex fields lack webhook validation, allowing…2026-07-31
- mediumGHSA-ff84-5f28-78qj: re2: Out-of-bounds heap read in `exec`/`test`/`match` via attacker-influenced `lastIndex`…2026-07-31
- mediumGHSA-6hxr-mr5r-9836: re2: Global `String.prototype.match` with an empty-matchable pattern never advances → inf…2026-07-31
- mediumGHSA-x83g-979r-f5fh: Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII2026-07-31