Vulnerability-Lookup

RUSTSEC-2026-0141 (CVE-2026-46428)

Vulnerability from osv_rustsec – Published: 2026-05-14 12:00 – Updated: 2026-07-29 06:03 – Source website

Summary

TLS hostname verification disabled when using Boring TLS backend

Details

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).

Severity

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

References

URL

Type

	https://crates.io/crates/lettre	PACKAGE
	https://rustsec.org/advisories/RUSTSEC-2026-0141.html	ADVISORY
	https://github.com/lettre/lettre/security/advisor…	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "crypto-failure"
        ],
        "cvss": "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",
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "lettre",
        "purl": "pkg:cargo/lettre"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.1"
            },
            {
              "fixed": "0.11.22"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "CVE-2026-46428",
    "GHSA-4pj9-g833-qx53"
  ],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "An inverted-boolean bug in lettre\u0027s `boring-tls` integration silently\ndisables TLS hostname verification for callers using the default (strict)\nconfiguration. An on-path attacker presenting any chain-valid certificate\nfor any domain can intercept SMTP submission, including PLAIN/LOGIN\ncredentials and message contents, against any lettre user built with the\n`boring-tls` feature. Other TLS backends (`native-tls`, `rustls`) are\nunaffected.\n\nThe bug was introduced in v0.10.1 and persists through v0.11.21 (latest).",
  "id": "RUSTSEC-2026-0141",
  "modified": "2026-07-29T06:03:48Z",
  "published": "2026-05-14T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/lettre"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0141.html"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/lettre/lettre/security/advisories/GHSA-4pj9-g833-qx53"
    }
  ],
  "related": [],
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "TLS hostname verification disabled when using Boring TLS backend"
}

CVE-2026-46428 (GCVE-0-2026-46428)

Vulnerability from cvelistv5 – Published: 2026-07-20 15:37 – Updated: 2026-07-21 15:49

Title

lettre has TLS hostname verification disabled when using Boring TLS backend

Summary

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.

Severity

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

SSVC

Exploitation: poc Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-07-21 15:48 UTC

CWE

CWE-295 - Improper Certificate Validation

Assigner

GitHub_M mitre root

References

4 references

URL	Tags
https://github.com/lettre/lettre/security/advisor…	x_refsource_CONFIRM
https://github.com/lettre/lettre/commit/f5efffc88…	x_refsource_MISC
https://github.com/lettre/lettre/releases/tag/v0.11.22	x_refsource_MISC
https://rustsec.org/advisories/RUSTSEC-2026-0141.html	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
lettre	lettre	Affected: >= 0.10.1, < 0.11.22

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-46428",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-21T15:48:51.405919Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-21T15:49:36.495Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/lettre/lettre/security/advisories/GHSA-4pj9-g833-qx53"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "lettre",
          "vendor": "lettre",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 0.10.1, \u003c 0.11.22"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s `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."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-295",
              "description": "CWE-295: Improper Certificate Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-20T15:37:58.396Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/lettre/lettre/security/advisories/GHSA-4pj9-g833-qx53",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/lettre/lettre/security/advisories/GHSA-4pj9-g833-qx53"
        },
        {
          "name": "https://github.com/lettre/lettre/commit/f5efffc88360dbdbfcef80f465e42d5bce68ca35",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/lettre/lettre/commit/f5efffc88360dbdbfcef80f465e42d5bce68ca35"
        },
        {
          "name": "https://github.com/lettre/lettre/releases/tag/v0.11.22",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/lettre/lettre/releases/tag/v0.11.22"
        },
        {
          "name": "https://rustsec.org/advisories/RUSTSEC-2026-0141.html",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://rustsec.org/advisories/RUSTSEC-2026-0141.html"
        }
      ],
      "source": {
        "advisory": "GHSA-4pj9-g833-qx53",
        "discovery": "UNKNOWN"
      },
      "title": "lettre has TLS hostname verification disabled when using Boring TLS backend"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-46428",
    "datePublished": "2026-07-20T15:37:58.396Z",
    "dateReserved": "2026-05-13T22:18:22.830Z",
    "dateUpdated": "2026-07-21T15:49:36.495Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

GHSA-4PJ9-G833-QX53

Vulnerability from github – Published: 2026-07-28 14:29 – Updated: 2026-07-28 14:29

Summary

lettre has TLS hostname verification disabled when using Boring TLS backend

Details

Summary

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::::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 SAN does not match mail.example.com. Actual on boring-tls: handshake succeeds. lettre proceeds with the SMTP transaction, sending MAIL FROM, RCPT TO, message body, and any configured SMTP AUTH credentials to the attacker. Symmetric inverse PoC (proves the inversion, not just a missing check): configure .dangerous_accept_invalid_hostnames(true) and try to connect to a server whose cert SAN matches the connect domain. With the bug, the handshake fails because lettre passes true to verify_hostname and boring rejects... actually wait, it succeeds (SAN matches). Better inverse demonstration: connect to a server whose cert SAN matches the connect domain with accept_invalid_hostnames=true, then connect to a mismatched-SAN server with the same flag — the latter is rejected, proving the flag is inverted (the user opted into accepting any name, yet lettre enforces strict verification). A reproducer cargo project can be produced on request.

Impact

Who is impacted: any lettre user who 1. enables the boring-tls feature, AND 2. relies on default-strict hostname verification (i.e. does NOT call .dangerous_accept_invalid_hostnames(true)). This is the entire "I want strict TLS" population on boring-tls. They get the opposite of what they asked for: a TLS handshake that ignores hostname mismatch. Exploitation: an attacker on the network path between the lettre client and the target SMTP server, holding any chain-valid TLS certificate (e.g. a free Let's Encrypt cert for a domain the attacker owns), can present that certificate when the lettre client connects to the intended MX. boring accepts the handshake, lettre proceeds, and the attacker gains read/write access to: * SMTP envelope (MAIL FROM, RCPT TO) * Message bodies, attachments, headers * Any SMTP AUTH credentials (PLAIN, LOGIN, CRAM-MD5, etc.) * Any DKIM signatures and DMARC alignment downstream depends on can be inspected and selectively dropped Confidentiality and integrity impact: High. Availability impact: None direct (the attacker can choose to forward or drop, but the bug itself does not deny service). Cloudflare's email-fwdr independently identified and mitigated this downstream by promoting a previously-metric-only post-handshake SAN check to a hard error (fix landed 2026-05-12). Because we're mitigated downstream, we are not on a publication clock; we are reporting so the upstream fix can ship and other lettre+boring-tls deployments can stop relying on per-caller workarounds. Happy to coordinate on embargo timing. Affected versions: every released lettre version with boring-tls support, from v0.10.1 (PR #797, commit 985fa7e) through v0.11.21 (latest). No prior advisory or fix. Suggested fix: two-line negation of the flag at the boring call sites (see Details). Patch is ready locally and can be attached to a private collaboration fork.

Severity

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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "lettre"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.1"
            },
            {
              "fixed": "0.11.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46428"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T14:29:10Z",
    "nvd_published_at": "2026-07-20T16:17:01Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAn inverted-boolean bug in lettre\u0027s `boring-tls` integration silently\ndisables TLS hostname verification for callers using the default (strict)\nconfiguration. An on-path attacker presenting any chain-valid certificate\nfor any domain can intercept SMTP submission, including PLAIN/LOGIN\ncredentials and message contents, against any lettre user built with the\n`boring-tls` feature. Other TLS backends (`native-tls`, `rustls`) are\nunaffected.\n\n### Details\nboring\u0027s `SslConnectorBuilder::set_verify_hostname(bool)` /\n`verify_hostname(bool)` API takes a *verify* flag \u2014 `true` means enforce\nhostname verification, `false` means skip it. (Boring docs:\nhttps://docs.rs/boring/latest/boring/ssl/struct.ConnectConfiguration.html#method.set_verify_hostname)\nlettre\u0027s `TlsParametersBuilder` exposes the opposite-named flag\n`accept_invalid_hostnames: bool` \u2014 `true` means *accept invalid* (skip\nverification), `false` means verify. lettre passes this flag directly to\nboring at both TLS-upgrade sites, inverting the semantics:\nsrc/transport/smtp/client/net.rs:202 (sync)\n    .verify_hostname(*accept_invalid_hostnames)\nsrc/transport/smtp/client/async_net.rs:377 (async)\n    config.set_verify_hostname(accept_invalid_hostnames);\nConcrete behaviour under `boring-tls`:\n  * accept_invalid_hostnames = false  (the strict default)\n      \u2192 set_verify_hostname(false)  \u2192 hostname verification SKIPPED\n        (wrong; the caller asked for strict verification)\n  * accept_invalid_hostnames = true   (explicit opt-in to \"dangerous\")\n      \u2192 set_verify_hostname(true)   \u2192 hostname verification ENFORCED\n        (wrong; the caller opted into accepting any name)\nBoring\u0027s own warning on `set_verify_hostname`:\n    \"If hostname verification is not used, *any* valid certificate for\n    *any* site will be trusted for use from any other. This introduces\n    a significant vulnerability to man-in-the-middle attacks.\"\n`native-tls` (src/transport/smtp/client/tls.rs:355) uses\n`danger_accept_invalid_hostnames(self.accept_invalid_hostnames)`, whose\nflag name and semantics match lettre\u0027s \u2014 unaffected. `rustls` uses a\nseparate verifier path \u2014 unaffected.\nThe bug was introduced in PR #797 (\"Add support for boring TLS\"), commit\n985fa7e, first released in v0.10.1, and persists unchanged through v0.11.21\n(latest). Zero existing tests cover `accept_invalid_hostnames` end-to-end\nwith any backend, which is why the inversion has gone undetected.\nFix: negate the flag at both call sites. Two-line patch:\n    -    .verify_hostname(*accept_invalid_hostnames)\n    +    .verify_hostname(!*accept_invalid_hostnames)\n    -    config.set_verify_hostname(accept_invalid_hostnames);\n    +    config.set_verify_hostname(!accept_invalid_hostnames);\nI have the patch ready locally and can push to a private fork if a\ncollaborative fix branch is preferred.\n\n### PoC\nSetup (any lettre version \u003e= v0.10.1, built with the `boring-tls`\nfeature, default-strict configuration):\n1. Generate a TLS cert for any hostname the attacker controls, e.g.\n   `attacker.example`, signed by any CA in the client\u0027s trust store\n   (e.g. a Let\u0027s Encrypt cert is sufficient).\n2. Stand up an attacker SMTP server on the network path between the\n   lettre client and the intended MX. Have it present the\n   `attacker.example` cert on STARTTLS or implicit TLS.\n3. Use lettre with default-strict TLS to send to the real MX hostname,\n   e.g. `mail.example.com`:\n       use lettre::transport::smtp::client::{Tls, TlsParameters};\n       use lettre::{AsyncSmtpTransport, Tokio1Executor, Message};\n       let tls = TlsParameters::builder(\"mail.example.com\".to_owned())\n           .build_boring()\n           .unwrap();\n       let mailer = AsyncSmtpTransport::\u003cTokio1Executor\u003e::relay(\n               \"mail.example.com\",\n           )?\n           .tls(Tls::Required(tls))\n           .build();\n       mailer.send(message).await?;     // succeeds against attacker\nExpected with hostname verification: handshake fails because the\npresented leaf cert\u0027s SAN does not match `mail.example.com`.\nActual on `boring-tls`: handshake succeeds. lettre proceeds with the\nSMTP transaction, sending MAIL FROM, RCPT TO, message body, and any\nconfigured SMTP AUTH credentials to the attacker.\nSymmetric inverse PoC (proves the inversion, not just a missing check):\nconfigure `.dangerous_accept_invalid_hostnames(true)` and try to connect\nto a server whose cert SAN matches the connect domain. With the bug,\nthe handshake *fails* because lettre passes `true` to `verify_hostname`\nand boring rejects... actually wait, it succeeds (SAN matches). Better\ninverse demonstration: connect to a server whose cert SAN matches the\nconnect domain with `accept_invalid_hostnames=true`, then connect to a\nmismatched-SAN server with the same flag \u2014 the latter is rejected,\nproving the flag is inverted (the user opted into accepting any name,\nyet lettre enforces strict verification).\nA reproducer cargo project can be produced on request.\n\n### Impact\nWho is impacted: any lettre user who\n  1. enables the `boring-tls` feature, AND\n  2. relies on default-strict hostname verification\n     (i.e. does NOT call `.dangerous_accept_invalid_hostnames(true)`).\nThis is the entire \"I want strict TLS\" population on `boring-tls`. They\nget the opposite of what they asked for: a TLS handshake that ignores\nhostname mismatch.\nExploitation: an attacker on the network path between the lettre client\nand the target SMTP server, holding any chain-valid TLS certificate\n(e.g. a free Let\u0027s Encrypt cert for a domain the attacker owns), can\npresent that certificate when the lettre client connects to the intended\nMX. boring accepts the handshake, lettre proceeds, and the attacker\ngains read/write access to:\n  * SMTP envelope (MAIL FROM, RCPT TO)\n  * Message bodies, attachments, headers\n  * Any SMTP AUTH credentials (PLAIN, LOGIN, CRAM-MD5, etc.)\n  * Any DKIM signatures and DMARC alignment downstream depends on\n    can be inspected and selectively dropped\nConfidentiality and integrity impact: High. Availability impact: None\ndirect (the attacker can choose to forward or drop, but the bug itself\ndoes not deny service).\nCloudflare\u0027s email-fwdr independently identified and mitigated this\ndownstream by promoting a previously-metric-only post-handshake SAN\ncheck to a hard error (fix landed 2026-05-12). Because we\u0027re mitigated\ndownstream, we are not on a publication clock; we are reporting so the\nupstream fix can ship and other lettre+boring-tls deployments can stop\nrelying on per-caller workarounds. Happy to coordinate on embargo\ntiming.\nAffected versions: every released lettre version with `boring-tls`\nsupport, from v0.10.1 (PR #797, commit 985fa7e) through v0.11.21\n(latest). No prior advisory or fix.\nSuggested fix: two-line negation of the flag at the boring call sites\n(see Details). Patch is ready locally and can be attached to a private\ncollaboration fork.",
  "id": "GHSA-4pj9-g833-qx53",
  "modified": "2026-07-28T14:29:10Z",
  "published": "2026-07-28T14:29:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lettre/lettre/security/advisories/GHSA-4pj9-g833-qx53"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46428"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lettre/lettre/commit/f5efffc88360dbdbfcef80f465e42d5bce68ca35"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lettre/lettre"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lettre/lettre/releases/tag/v0.11.22"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0141.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "lettre has TLS hostname verification disabled when using Boring TLS backend"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

RUSTSEC-2026-0141 (CVE-2026-46428)

CVE-2026-46428 (GCVE-0-2026-46428)

GHSA-4PJ9-G833-QX53

Summary

Details

PoC

Impact

Tags

Sightings

Nomenclature

Related by attack behaviour