更新日志写参数被反射写进缓存页导致代码执行，这条链路是怎么成立的

更新日志写参数被反射写进缓存页导致代码执行，这条链路成立需要三步：请求里的参数被原样回显到页面、回显内容被写进了静态缓存文件、缓存文件再次被读取时按可执行语法解析。PbootCMS 官方更新日志里 V3.2.14（2026-06-15）修复的正是这一类问题——page 参数经蜘蛛标签反射写入 HTML 缓存导致 PHP 代码执行。单看「反射」只是跨站脚本，加上「缓存落盘」和「服务端再解析」两步，危害就从访客侧移到了站点侧。

一条更新日志描述里有几个动作

这句描述里藏着四个可核对的技术事实。参数来自 URL 查询串，属于外部输入；「蜘蛛标签」说明这条分支专为搜索引擎抓取服务，本来就不该被普通访客触发，却因为没有区分调用方而暴露在公开入口；「反射写入 HTML 缓存」意味着输入离开了动态渲染路径，变成磁盘上的文件；「导致 PHP 代码执行」表示缓存文件被当作脚本解析，而不是纯静态资源。

同类问题的通用修复思路在上一版里也能看到：V3.2.13（2026-06-06）做了 ORM 参数化绑定的加固。两个版本合起来是一条常见链路的上下游——上游控制输入是否被拼进语句，下游控制输出是否被当作代码。

反射为什么能落到缓存里

缓存系统的设计前提是「同一 URL 的响应可以复用」。当页面为爬虫生成专门版本、又把 URL 参数拼进输出内容时，参数就成了缓存键的一部分：只要构造一个新的参数值，就能生成一份新的缓存文件，而这份文件的内容里带着提交者控制的字符串。缓存目录通常可写、文件名可预测，这两点叠加后，写入这一步几乎不需要额外条件。

自查时抓三个特征：是否存在「按参数生成并落盘」的缓存逻辑、缓存文件是否放在可被 Web 直接访问的目录、服务端是否会解析该目录里的脚本后缀。三项都为「是」，就是需要立刻收紧的组合。

缓存页再次被读时发生了什么

后续访客或爬虫请求命中同一份缓存，服务端按脚本解析文件内容，控制型字符串就在页面上下文里执行。这一步的关键是解析方式而不是内容长度：哪怕文件里只有一段短标记，只要被当成代码走，就有了执行入口。

防御面因此分三段。输入段做校验与白名单，比如分页参数只允许数字；输出段做编码，让回显内容始终留在文本上下文里；解析段限制可执行位置，缓存目录不放脚本权限、访问路径不接受可解析后缀。三段只做其中一段，链路仍有可能走通。

过滤、审核与编码分别拦哪一环

内容侧的过滤与审核解决的是「这段文字能不能出现在站点上」。AnQiCMS 的内容安全设置提供敏感词过滤、关键词替换与内容审核，作用点在数据入库与上线之前，挡的是违规文本与营销词，不承担语法层面的转义职责。注入与跨站则走另一条路：AnQiCMS 内置 JWT 认证、内容敏感词过滤与防采集干扰码，在框架层防御 SQL 注入和 XSS 攻击，伪静态规则由后台统一管理，URL 参数进入渲染前经过校验。两条线合起来才是完整覆盖，把敏感词过滤当成加固注入的手段属于错配。

缓存与备份的关系

缓存文件同样是需要纳入备份范围的内容。它不在数据库里，但决定用户看到的页面形态：升级前如果没有缓存的备份或清理方案，一旦新版本渲染异常，就缺少可回退的状态。AnQiCMS 的备份与恢复覆盖数据以及静态文件，处置这类问题时的顺序是先取备份、再清缓存、后升级，任何一步出问题都能退回上一步。

常见问题

清掉缓存文件算不算修复？ 不算。清缓存移除的是已落盘的产物，参数仍可再次写入新的缓存，版本或代码层的修复才是终止条件。

只给爬虫的渲染分支为什么也危险？ 攻击者不需要真的来自搜索引擎，构造带参数的请求就能触发这条分支生成缓存文件。

怎么判断自己的缓存有没有被执行风险？ 看缓存目录是否可通过 Web 直接访问、是否允许脚本后缀被解析，两项任一为否，链路就被切断一段。