公式渲染模块被判跨站脚本，富文本过滤为什么要连渲染路径一起查
Drupal 社区公告 SA-CONTRIB-2026-195 把 MathJax 模块判为 Critical 级跨站脚本，漏洞不在 HTML 标签而在公式渲染路径：该模块对格式化的 TeX 内容里的 JavaScript 未做转义，4.1.2 之前的版本受影响。这类公告给出的提醒是明确的——富文本过滤必须连渲染路径一起查。标签白名单只约束走 HTML 解析的出口，公式、Markdown、图表这些各自解释文本的引擎在它的管辖之外。
公告里的版本区间和评级怎么读
读三条：受影响区间是 4.1.2 之前，修复方式是升级到 4.1.2；评级 15 / 25，攻击条件标注为基本（AC:Basic），意思是触发不需要特殊配置或高权限前提；机密性与完整性影响都非零，说明利用成功后能改写页面行为。对运维来说优先动作的顺序也由这三条决定：先确认装没装该模块，再确认版本是否落在区间内，最后才是评估临时缓解。不要只看「严重」二字就恐慌，也不要因为需要特定组件就轻视——只要站点确实在用这个渲染路径，未转义就是实打实的执行入口。
为什么白名单管不到渲染路径
网站里常见的非 HTML 解析器有三类：公式引擎按 TeX 语法解释花括号与命令，Markdown 解析器把标记文本编译成 HTML，图表配置把结构化文本渲染成可交互组件。它们的共同点是自己定义「什么算指令」。输入侧的过滤往往只拦尖括号这类 HTML 特征，而公式引擎识别的语法根本不依赖尖括号——同一段内容，HTML 解析器看到的是文字，公式引擎看到的是指令。标签白名单再完整，也管不了第二个解释器眼里的世界。这就是「过滤做了、渲染路径没查」的典型缺口。
输出上下文转义分几种
原则是：由消费者决定转义方式，而不是由数据来源决定。同一段用户文本，输出进 HTML 正文要处理尖括号与引号；输出进属性值要多防一层分隔符；输出进脚本字符串要按 JavaScript 的语法转义；拼进 URL 查询参数则要做百分号编码。四种上下文的不安全字符集合各不相同，只做一个全局「敏感字符清洗」必然两头不讨好：拦多了显示异常，拦少了留下逃逸路径。自查清单按出口枚举：把富文本能到达的每个模板位与渲染组件列出来，逐一问「这个位置的解释器是什么，它收到过转义吗」。
站内富文本该在哪几处收口
收口分三层：输入层做标签白名单与敏感词过滤、关键词替换，AnQiCMS 的内容安全设置管的正是这一段；防御层针对 XSS 与 SQL 注入的攻击特征做拦截，AnQiCMS 在认证与输入防护上有对应设计；渲染层则是上面说的按输出上下文转义，这层通常要配合模板与组件逐一核对，任何带独立解析引擎的富文本扩展都应当纳入审计。三层各司其职，公告里那种「输入过滤完好、渲染路径裸奔」的事故，查的正是第三层有没有人负责。
常见问题
只用官方富文本编辑器还会出这类问题吗？ 会。官方编辑器负责输入与显示，第三方渲染组件（公式、代码高亮、图表）常常自带解析器，审计范围要覆盖它们而不是只盯编辑器本身。
升级修复不了的时候有什么临时办法？ 缩小暴露面：对不可信来源的内容关闭公式与非 HTML 渲染，或把这些内容降级为纯文本展示，等官方修复版本就绪再恢复。
怎么确认自己的站有没有这条渲染路径？ 把前台页面加载的脚本与渲染组件清单拉出来，逐个确认它是否会解释用户可编辑内容。只要答案含「会」，它就在必查范围里。