🔴 【深度分析】严重安全漏洞：CVE-2026-46428

CVSS 评分: 严重（9.1）🔴　　状态: Deferred　　发布时间: 2026-07-20

🔍 技术细节速览

字段 值
CVE ID CVE-2026-46428
CVSS 评分 9.1 🔴
严重程度 严重
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/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
CWE 分类 CWE-295
发布时间 2026-07-20
最后更新 2026-07-23
状态 Deferred
数据来源 security-advisories@github.com

CVSS 4.0 评分：9.1（严重）
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
CWE： CWE-295（证书验证不当）
影响组件： lettre（Rust 邮件库）boring-tls 功能分支

漏洞概述

lettre 是一个用 Rust 编写的邮件发送库，广泛用于需要 SMTP 支持的应用程序。该漏洞（CVE-2026-46428）存在于 lettre 与 boring-tls（基于 BoringSSL 的 TLS 前端）的集成中。由于一个反向布尔逻辑错误，默认的严格 TLS 配置下，主机名验证被静默禁用。这意味着攻击者只要拥有任意域名的合法证书（链验证通过），就可以执行中间人攻击，拦截 SMTP 传输中的 PLAIN/LOGIN 凭据以及邮件内容。

该漏洞影响 lettre 版本 0.10.1 至 0.11.21（含）。其他 TLS 后端（native-tls、rustls）不受影响。补丁版本 0.11.22 已修复此问题。

受影响组件与版本

组件 受影响版本范围
lettre crate（Rust 包） >= 0.10.1, < 0.11.22
启用 boring-tls 特性 所有使用该特性的构建均受影响
其他 TLS 后端 native-tls 和 rustls 不受影响

注意： 即使开发者在代码中显式使用了严格模式（要求证书链与主机名均校验），由于反向布尔错误，主机名校验实际上被跳过。

漏洞原理分析

1. 技术背景

lettre 支持多种 TLS 后端，其中 boring-tls 基于 Google 的 BoringSSL 库。在 TLS 连接建立时，通常需要执行两个证书验证步骤：

  • 证书链验证：确保证书由受信任的 CA 签发且未过期。
  • 主机名验证：确保证书中的 CN/SAN 与目标服务器的主机名匹配。

lettre 的默认配置（TlsParameters::new() 或 TlsParameters::builder().build()）会同时启用链验证和主机名验证，属于“严格模式”。

2. 漏洞成因

根据 NVD 描述，漏洞源于 boring-tls 集成中的一个反向布尔错误（inverted-boolean bug）。具体来说，在设置 TLS 验证选项时，代码可能错误地将“启用主机名验证”的条件取反，导致本应生效的主机名验证被静默关闭。例如：

// 伪代码示意（非实际代码）
if should_verify_hostname {
    // 正确：设置主机名验证
    ssl_ctx.set_verify_hostname(true);
} else {
    // 错误分支
}

若逻辑误写为 if !should_verify_hostname，则当 should_verify_hostname 为 true（严格模式）时，实际执行的是 else 分支，即 不设置主机名验证，且不会产生任何警告或错误。

由于攻击者仅需提供任意一个由受信任 CA 签发的证书（例如为其控制下的域名申请的合法证书），即可通过链验证，但主机名验证被绕过，因此攻击者可以用自己的证书冒充任何 SMTP 服务器。

3. 攻击向量

  • 攻击前提（AT:P）： 攻击者需要处于客户端与 SMTP 服务器之间的网络路径上（例如同一 Wi-Fi 网络、上游 ISP 或路由节点）。
  • 利用复杂度（AC:L）： 攻击者只需持有任意合法证书（可通过 Let's Encrypt 等免费 CA 轻易获取），并拦截 SMTP 连接（标准端口 587/465）。
  • 无需权限（PR:N）且无需用户交互（UI:N）： 客户端自动发起 SMTP 连接，攻击者可透明地执行 TLS 降级或证书替换。

影响评估

攻击难度

指标 分析
网络访问（AV:N） 攻击者可从远程网络发起，不要求本地访问
攻击前提（AT:P） 需要处于中间人位置（如同一子网或控制路由）
攻击复杂度（AC:L） 利用方式简单，证书可自行签发
权限要求（PR:N） 无需在目标系统上拥有任何权限
用户交互（UI:N） 无需用户点击或确认

潜在后果

  • 机密性丧失（VC:H）： 攻击者可截获 SMTP 登录凭据（PLAIN/LOGIN 明文）以及邮件正文。
  • 完整性丧失（VI:H）： 攻击者可篡改或伪造邮件内容，甚至重放身份认证。
  • 可用性无影响（VA:N）： 攻击不直接导致服务不可用。
  • 后续影响（SC:L/SI:L）： 若凭据被窃取，可能导致邮件服务器被滥用（低影响）。

受影响场景

  • 使用 boring-tls 特性的 Rust 应用程序（如邮件发送后端、监控告警系统、自动化通知服务）。
  • 在不可信网络中运行（如公共 Wi-Fi、云服务提供商内部网络）。
  • 依赖于 PLAIN/LOGIN 认证的 SMTP 配置（虽然建议使用 OAUTH2，但许多遗留系统仍使用明文认证）。

修复建议

1. 立即升级

将 lettre 升级至 0.11.22 或更高版本。Cargo.toml 中：

[dependencies]
lettre = "0.11.22"

如果锁定版本，请运行 cargo update -p lettre。

2. 临时缓解措施（若无法升级）

  • 更换 TLS 后端： 将 features 中的 boring-tls 替换为 native-tls 或 rustls。例如：
    # Cargo.toml
[dependencies.lettre]
version = "0.11.21"  # 临时保留
default-features = false
features = ["rustls-tls"]  # 或 "native-tls"
  • 网络层加固： 使用 VPN、TLS 隧道或 IP 白名单限制 SMTP 服务器连接至可信网络。
  • 强制证书固定（Certificate Pinning）： 在应用层额外验证服务器证书的指纹（但需注意与默认 TLS 机制的兼容性）。

3. 验证修复

升级后，可使用 Wireshark 或 tcpdump 抓包确认是否仍存在主机名验证被绕过的行为（例如尝试连接到一个 SNI 与实际域名不匹配的服务器，应被拒绝）。

参考资料

免责声明： 本分析基于公开 NVD 数据及常见补丁模式进行合理推断，具体代码细节请参考 lettre 官方补丁提交。若需进一步取证，建议审查 lettre 与 boring-tls 集成的 Cargo.toml 及 src/transport/smtp/tls.rs 相关变更。