一封邮件能偷走你的密码——作案工具是 CSS，不是 JavaScript

一封邮件能偷走你的密码——作案工具是 CSS，不是 JavaScript。

这听起来像标题党，但它是 2026 年 Black Hat USA 上真实披露的研究。PortSwigger 安全研究员 Gareth Heyes 证明了这件事：只需一封精心构造的 HTML 邮件，攻击者就能在用户读邮件的过程中实时捕获密码、窃取第三方账户令牌、甚至操控 AI 邮件助手。所有攻击在 6 大主流邮件客户端上均已验证有效，覆盖 Gmail、Outlook、Fastmail、Proton Mail、Yahoo Mail 和 AOL Mail。没有恶意脚本，没有附件，没有任何用户主动点击。

邮件的安全边界，从来就不在你以为的地方

大多数人对“邮件安全”的理解是：别点陌生链接，别打开可疑附件。浏览器沙箱、垃圾邮件过滤器、杀毒软件……这些防线加起来，好像够用了。但 Heyes 的研究打在了一个完全被忽视的面：邮件渲染引擎和受信界面之间的那道墙——CSS 渲染。

现代 Web 邮件客户端把用户收到的 HTML 邮件渲染在和文件夹列表、写信窗口、账户菜单同一个 DOM 里。你以为的安全边界是“邮件内容跑在隔离环境”，实际上安全边界只是一道 sanitizer（内容净化器）。这道防线验的是什么？HTML 字符串。而邮件最终怎么被渲染出来，是浏览器和邮件客户端的 JavaScript 共同决定的——这两件事之间存在裂缝。

攻击路径就是这两条裂缝：直接滥用 sanitizer 允许的功能，或者制造 parser 差异——喂给 sanitizer 一段它认为安全的代码，然后靠浏览器或应用自己的 JS 把这段代码改写成 sanitizer 从没审查过的东西。第二类更难防，因为一个对输入字符串做到完美净化的 sanitizer，只要应用后来把字符串改写成新 DOM 节点，就仍然会被突破。

Outlook 攻击链：把 select 伪装成密码框

Outlook 的攻击链最能说明问题。它由多个看似无害的小零件组成，最终拼出一套实时键盘记录器。

第一步，label 逃逸。邮件中允许的 <label> 元素可以绑定到邮件 body 范围之外的控件上，形成 label-jacking——邮件里的一个 label 元素，能触发受信 UI 区域里的按钮或输入框。第二步，属性变异。邮件客户端自己的 JavaScript 会把 sanitizer 清理过的自定义属性转换成新的 DOM 节点，这些新节点携带着 sanitizer 允许列表里根本不存在的 CSS。第三步，媒体查询解析绕过。把属性转换和媒体查询解析组合，攻击者拿到了在受信 UI 区域注入任意 CSS 的能力。

有了任意 CSS，攻击者把一个 <select> 元素伪装成密码输入框的样子。当用户在“密码框”里打字时，每个按键触发一条不同的 CSS 规则，每条规则向攻击者控制的服务器发一个背景图片请求——字符就这样被实时记录了。在 Firefox 上还有个关键细节：select 元素移出屏幕时大约一秒的选择计时器会被重置，这意味着攻击者可以连续捕获每个字符，而不是只能记录一次。

Yahoo Mail 和 AOL Mail：粘贴竞赛

Firefox 里粘贴 HTML 内容会短暂保留原始 CSS，才被 sanitizer 处理。攻击者先诱导用户复制一段 CSS（伪装成“复制这个样式到邮件草稿”），粘贴进 Yahoo 或 AOL 草稿后，浏览器会短暂执行这些 CSS。在一个针对 Medium 的演示中，粘贴产生的请求泄露了 12 字符登录令牌足够多的片段，攻击者服务器完整还原了令牌，登录成了受害者账户。

任何让用户“复制内容粘贴到邮件编辑器”的工作流，在这个研究面前都应该被视为不受信的输入路径。

AI 邮件助手把渲染漏洞变成直接凭证损失

最有杀伤力的是 AI 连接器这条链。Gmail 的 image-set() CSS 函数在 sanitizer 处理后仍能发外部请求。Heyes 和同事 Pete Hendy 把这个和 AI 邮件助手 prompt 注入组合：攻击者先触发一封合法的 Slack 令牌确认邮件，当受害者让 Claude Cowork（Anthropic 的 AI 邮件助手）处理收件箱时，注入的指令让它把那封包含 Slack 令牌的邮件内容写入一个 HTML 草稿，草稿一打开，令牌就泄露了。

在 Fastmail 上，攻击者用 CSS 伪元素和 opacity 让人类看到无害文本，AI 读到的却是隐藏指令。受害者让 OpenAI Atlas 翻译“无害文本”时，AI 按隐藏指令打开了标签页并把受害者名字编码进 URL 参数里。OpenAI 已在 2026 年 8 月停用了 Atlas，但这类攻击路径对任何接入邮件的 AI 助手都适用。

攻击不需要用户犯错，它靠的是信任

这类攻击最危险的地方在于，用户不需要做任何“错误的事”。没有可疑链接，没有附件提示，没有奇怪的弹窗——用户只是正常读了一封邮件。它绕过了所有针对 JavaScript 的安全工具：杀软不管，垃圾邮件过滤器不管，脚本拦截扩展也不管。攻击的 Payload 就是 CSS，就是字体颜色、布局和间距。

防御：把邮件内容真正隔离开

研究没有 CVE 编号，因为这不是一个能打补丁的漏洞，而是一类系统级缺陷。修复需要架构层面的改动。核心建议：

邮件提供商侧：把 HTML 邮件渲染在 sandboxed iframe 里，这是最根本的隔离手段。同时对 CSS 做严格的字符白名单校验，检查每个自定义属性的 CSS gadget 风险，禁止 select 菜单和 :has()、:checked 等危险选择器，并切断邮件内容对外部图片请求的通道——包括白名单域名。

企业侧：立即盘点哪些 AI 助手和连接器有邮箱读取权限，把所有邮件 body 视为 prompt 注入输入。对于任何出现在邮件客户端内的登录提示，要求用户到身份提供商那里重新认证，而不是在邮件窗口里输入。任何要求“复制这段内容粘贴到邮件草稿”的工作流，立即停用。

个人用户侧：开启多因素认证，即使密码泄露也有第二道防线。考虑用 passkey 或硬件安全密钥，它们能抵御令牌被盗用。警惕任何出现在邮件正文里的登录表单——正常服务不会这么做。

这件事给所有人的教训是：安全边界不在你以为的地方。邮件的信任对象，已经被 CSS 悄悄扩大了。

证据来源

• Black Hat USA 2026，Gareth Heyes（PortSwigger），“CSS in Email Is Now an Exploit Primitive”，2026年8月6日
• RedEye Threat Intelligence 分析报告，2026年8月9日
• The Hacker News，2026年8月
• Fastmail 已修复两个 CSS 突变漏洞；Proton Mail 代理绕过在复测时失效；Outlook label-jacking 和 Gmail image-set() 绕过在论文发表时（2026年8月6日）仍处于未修复状态