DOMPurify 3.3.2以下全中招

一个用了7年的前端净化库，在2026年3月27日被曝出一个6.5分的漏洞。攻击者能让恶意代码像变形金刚一样——进去时无害，落地后突然活过来。

这不是什么边缘案例。DOMPurify周下载量超过3000万次，GitHub标星数1.7万，从Notion到无数SaaS都在用。它本该是前端安全的最后一道闸门，现在这道闸门有了裂缝。

漏洞原理：浏览器的"双重人格"

问题出在这类元素上。DOMPurify的净化逻辑和浏览器实际解析逻辑，对同一段代码的理解不一致——就像两个人用同一本词典，但查到的释义不同。

攻击者构造的Payload在净化阶段被视为安全文本，因为DOMPurify认为它处于"无脚本上下文"。但当这段代码被插入DOM后，浏览器重新解析时上下文变了，原本无害的字符串突然变成可执行的JavaScript。

安全研究员把这种攻击称为Mutation-XSS（变异型跨站脚本攻击）。传统XSS是"骗过过滤器"，mXSS是"骗过两次"——先让过滤器放行，再利用浏览器自己的解析差异完成变形。

CVSS 6.5的评分意味着：攻击复杂度低，需要用户交互，但能对机密性和完整性造成中等影响。换句话说，一个精心构造的富文本输入框就能成为入口。

为什么偏偏是3.3.2以下

DOMPurify的维护者在3.3.2版本中修复了这个问题。但修复不是简单的黑名单补丁，而是重构了对raw-text和RCDATA元素的处理逻辑。

RCDATA是HTML规范里的特殊分类：</code>、</code>这类标签的内容会被当作文本处理，但其中的字符实体（如<）会被解析。这种"半文本半代码"的特性，让上下文切换时的行为变得难以预测。

3.3.2之前的版本在处理时，没有充分考虑到一种边界情况：当页面处于"有脚本"环境时，的内容本不该被解析为HTML，但某些插入路径会让浏览器重新评估这段内容。

攻击链条大致是这样：

1. 向富文本编辑器提交包含特殊构造的标签

2. DOMPurify净化后认为安全，存入数据库

3. 其他用户浏览时，这段内容被动态插入页面

4. 浏览器重新解析，内的Payload逃逸为可执行代码

影响面：比你想象的更宽

很多人以为"我们用了DOMPurify就安全了"，这个漏洞打的就是这种心态。

真正危险的是那些"二次渲染"场景：服务端先净化一次，前端框架（React/Vue）挂载时再处理一次，或者用户保存草稿后再次编辑。每一次DOM操作都是一次重新解析的机会，也是mXSS变形的机会。

Notion这类产品之所以被特别提及，是因为它们的协作特性天然适合攻击传播——一个恶意文档被多人查看、编辑、嵌入，每次交互都可能触发不同的解析路径。

更隐蔽的是SSR（服务端渲染）场景。服务端用DOMPurify净化后的"安全"HTML，到了客户端被hydration（注水）时，浏览器解析逻辑和服务端Node环境完全不同，这种环境差异正是mXSS的温床。

检查你的package.json，如果DOMPurify版本低于3.3.2，这个漏洞就躺在你的依赖树里。

修复与防御：不只是升级

升级到3.3.2是最直接的方案。但DOMPurify的维护者在安全公告里加了一句值得玩味的话："建议同时审查所有涉及innerHTML和outerHTML的代码路径。"

这句话的潜台词是：净化库只能保证"它输出的内容是安全的"，但不能保证"你使用这些内容的方式是安全的"。

如果你把DOMPurify净化后的字符串又塞进另一个模板引擎，或者用字符串拼接的方式组装HTML，上下文切换的风险依然存在。这就像把过滤后的水倒进脏杯子。

对于暂时无法升级的系统，可以考虑在DOMPurify之后增加一层输出编码，或者强制使用textContent代替innerHTML进行最终插入。这些方案都有性能或功能代价，但能阻断mXSS的变形链条。

一个值得注意的细节：3.3.2的修复改变了对的默认处理方式，现在它会强制移除这个标签而不是尝试净化其内容。如果你的业务逻辑依赖保留，升级后需要额外配置。

这个漏洞最讽刺的地方在于，它攻击的正是"安全工具本身的安全假设"。DOMPurify的设计哲学是"白名单优先、上下文感知"，但浏览器的解析上下文太复杂了，复杂到连专门研究它的人也会踩坑。

当你的用户下次在富文本编辑器里粘贴一段"看起来无害"的内容时，你确定它不会在某个iframe、某个移动端WebView、某个未来版本的浏览器里突然变形吗？