<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-09T11:47:40.741196+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2026-46428</id>
    <title>CVE-2026-46428 — lettre has TLS hostname verification disabled when using Boring TLS backend</title>
    <updated>2026-10-09T11:47:40.742884+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> lettre</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-46428"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-4pj9-g833-qx53</id>
    <title>GHSA-4pj9-g833-qx53 — lettre has TLS hostname verification disabled when using Boring TLS backend</title>
    <updated>2026-10-09T11:47:40.742959+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: lettre</p>
<p>### 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.</p>
<p>### 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   (explici…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-4pj9-g833-qx53"/>
  </entry>
</feed>
