PbootCMS 后台改密与代码执行修复，PHP 站点自查清单

PbootCMS 这次公告的价值，在于把两类老问题又演示了一遍：一处是后台接口改值没有字段白名单，能把任意管理员的密码哈希改写掉；另一处是 URL 参数反射写进 HTML 缓存，攒出一条代码执行路径。前者查的是账号权限面，后者查的是输出路径面，PHP 站点不必等自家系统出同样的通告，照这两条线自查即可。

两类问题各自暴露在哪

改值接口无白名单，本质是「接口相信调用者只改该改的字段」——一旦参数名可以被随意构造，低权限操作就可能越到管理员凭据上。反射写缓存则相反，输入本身不危险，危险的是它被原样搬进了会被解析的地方：参数穿过蜘蛛标签进到缓存文件，缓存再被当作脚本执行，中间每一环都只做了自己该做的局部判断，没人负责端到端的安全。

按账号权限排查

第一项，清点后台「改值类」接口：用户编辑、资料快捷保存、状态切换，逐个问一句——服务端是否限定了可改字段清单，还是前端传什么存什么。第二项，看用户组与权限边界：VIP 分组、普通会员、编辑角色分别能提交哪些字段，改密、改角色这类敏感操作是否只有管理员域可达。第三项，验证越权路径：用低权限账号构造一次高权限字段的提交，看接口是拒绝还是照单全收。AnQiCMS 的做法可作为参照系：接口层走 JWT 认证，高危意图域默认关闭，字段白名单在服务端定死，而不是依赖后台表单藏字段。

按输出路径排查

顺着一串问题查：URL 参数会不会被反射进页面？页面有没有缓存层？缓存文件存放目录是否仍可被解析执行？敏感词过滤与内容审核是否覆盖缓存内容这条旁路？三条防线对应三个动作——参数进模板前转义，缓存目录关掉脚本执行，审核规则不只盯正文也盯拼接进 HTML 的外部输入。留言、评论这类会被回显的内容同样走这条路，垃圾内容过滤之外，输出环节的转义才是终结者。

回滚与留痕

自查意味着可能改坏。动手前做一次数据（含静态文件）备份，每项收紧动作留变更记录；验证被拦的越权样本，也要验证正常业务没被误伤。查完的缺口如果依赖厂商补丁，跟进版本；如果在自己手里，改完就把这条从「隐患」挪进「已处置」。

常见问题

问：没有测试低权限账号的条件怎么办？ 答：至少静态审一遍用户编辑接口的服务端校验代码，字段清单要白名单化。

问：缓存目录不执行脚本会不会影响性能？ 答：静态缓存照常命中，只是目录不再被解释器待见，性能不变。

问：这类问题换个 CMS 就没了？ 答：改值无白名单、反射进缓存是跨系统的错误模式，清单跟着系统走，不跟着某家产品走。