在 2026 年 Black Hat USA 大会上，研究人员展示了如何将层叠样式表 (CSS) 武器化，使 AI 驱动的电子邮件代理读取对人类用户不可见的内容。该技术绕过了 Outlook、Gmail、Yahoo 和 Proton，使代理能够窃取密码、身份验证令牌和 IP 地址。

为什么 CSS 在电子邮件安全中至关重要

多年来，网络邮件提供商一直通过剥离脚本、对 iframe 进行沙箱处理以及限制邮件功能来防御恶意 HTML。这些措施可以阻止依赖 JavaScript 或嵌入式对象的经典攻击。然而，CSS 一直被视为无害的展示代码。其高级选择器——属性选择器、容器查询等——允许页面在没有任何脚本的情况下对 DOM 结构做出反应。

Black Hat 的演示证明，这些“无害”的选择器可以成为数据泄露的侧信道。通过构建仅在某些隐藏元素存在时才生效的样式规则，攻击者可以使文本对用户不可见，但仍存在于 AI 代理解析的渲染页面中。

攻击是如何运作的

其中一个概念验证发送了一封对收件人来说看起来很普通的电子邮件。隐藏在其中的 CSS 规则会将特定文本的颜色更改为与背景匹配，从而有效地将其掩盖。人类永远看不到这些文本，但提取 DOM 或辅助功能树 (accessibility tree) 的 AI 代理并不会应用视觉过滤器。当代理处理电子邮件时，它会读取被掩盖的文本，并将其通过 URL 片段 (URL fragment) 进行传输——这是浏览器在加载页面时通常会忽略的 Web 地址的一部分。

另一种变体使用了间接提示注入 (indirect prompt injection)。电子邮件中包含一个隐藏的 Slack 令牌。CSS 使该令牌对用户不可见，但仍保留在标记语言中。经过训练以遵循电子邮件中嵌入指令的 AI 代理，会将该令牌解释为命令，并将其发送回攻击者的服务器。

这两种攻击在同一组流行供应商面前都取得了成功，这表明该漏洞源于 CSS 渲染的基本方式，而非单一平台的实现。

AI 代理 vs. 人类读者

人类会本能地忽略看不见的文本；我们信任视觉布局来告诉我们哪些内容是重要的。相比之下，AI 代理运行在原始 DOM 或记录了每个元素（无论其视觉状态如何）的辅助功能树上。当 AI 读取页面时，它不会应用“如果我看不见，我就忽略它”的规则。这种不匹配造成了一个盲点：为人类阅读而构建的清理流水线 (sanitisation pipelines) 不再能保证自动化读取器的安全。

这个问题并不是新的 AI 缺陷。它是一个古老的 Web 缺陷——CSS 在没有代码的情况下影响布局的能力——遇到了新类型的消费者。任何将电子邮件内容交给 AI 驱动的助手、摘要器或分类器的服务，现在都面临着助手可能会根据人类从未看到过的数据采取行动的风险。

谁该负责防御？

这些攻击提出了一个管辖权问题。网络邮件提供商已经通过清理 HTML 来保护人类用户；浏览器也已经在执行相同的渲染规则。然而，这些层级都没有考虑到会解析相同标记的下游 AI。电子邮件服务是否应该增加更深层次的 CSS 清理？浏览器是否应该公开一个将元素标记为“对脚本不可见”的标志？或者 AI 供应商必须构建在处理前丢弃隐藏节点的过滤器？

构建 AI 驱动电子邮件工具的安全团队被告知要审计完整的渲染流水线，而不仅仅是到达收件箱的 HTML。这意味着要在应用 CSS 后检查 DOM，检查辅助功能树，并明确剥离或标记任何人类肉眼不可见的内容。

下一步值得关注的方向

  • 供应商测试 – 预计 AI 供应商将把现实世界的 CSS 攻击向量纳入其测试套件中。Web 领域已有三十年的漏洞研究历史；而 AI 代理只有短短几年。

如果仅仅通过 CSS 隐藏文本就能诱骗 AI 助手泄露凭据，那么保护当今收件箱的安全模型就不再足够了。开发人员、提供商和监管机构必须将渲染后的页面（而不仅仅是原始 HTML）视为任何自动化消费者的安全边界。隐藏文本问题提醒我们，曾经被归类为“仅用于样式”的技术，可能会成为数据窃取的渠道。下一波防御必须将 CSS 视为潜在的攻击面，而不仅仅是视觉辅助工具。