补丁发布前六小时就有人在打，PHP 那轮远程执行该怎么防

补丁发布前六小时就有人在打，是 PHP 这轮远程执行漏洞里最该被记住的事实：修复落在 2026 年 10 月 21 日，而攻击尝试比补丁早六小时出现。漏洞的严重性在于无需登录就能让攻击者在 Web 服务器上运行自己的代码，而 WordPress 承载了全球 39.6% 的网站，等待窗口越长，暴露面越大。真正的防线不是补丁发布那一刻，而是能否在几个小时内走完「确认命中—临时压制—升级核查」三步。

为什么补丁前的六小时反而更危险

漏洞利用代码往往在补丁发布前后就已流通：厂商给出修复说明，等于把触发条件公开。攻击者把补丁里的差异点反向拼成请求，就能在还没升级的站点上试手。这六小时里有三个特点：

• 防御方还没有可下发的版本，只能靠配置和规则顶住；
• 日志里出现的是未知来源请求，容易被当成爬虫噪声忽略；
• 共享主机、代维站点的应用发布窗口固定在夜间，六小时正好落在窗口之外。

因此判断标准不是「补丁有没有发布」，而是「利用条件是否已经公开」。公开即视为在野风险。

运行 PHP 的站点先确认哪三件事

第一件是运行版本。把 Web 服务器的 PHP 版本、程序自身版本、以及承载它的扩展模块逐一列出来，版本对不上就没有讨论修复的基础。第二件是入口面。远程执行多数走的是无需鉴权的入口：表单处理、文件上传、模板渲染、对外接口。把匿名可访问的路径列成清单，比逐个页面点一遍更有效。第三件是历史痕迹。补丁前的访问日志按可疑参数形态筛一遍，重点看异常长度的查询串、编码后的表达式以及对上传目录的执行记录。

临时缓解和彻底修复的差别在哪

临时缓解的价值是买时间，不是解决问题。规则拦截要留出回滚开关，否则误拦业务时无人能收。

升级之后要核查哪些地方

升级完成后至少核查四类：登录凭证与 JWT 会话是否需要强制重新签发；列表查询与排序参数还能不能拼出 SQL 注入；跨站脚本 XSS 的输出过滤是否覆盖新增字段；以及敏感词过滤与内容审核规则在版本变动后有没有失效。日志里出现过的来源 IP、异常计划任务、被改过的模板文件，都要逐条对齐。若无法确认清白，重置管理员口令并轮换各站点的签名密钥，比反复检查更快收口。

AnQiCMS 里同类高危问题是怎么修的

v3.6.6（2026-10-08）修的两项都是同一类思路：不给「构造空间」。列表排序参数此前允许有限度的 SQL 函数表达式，校验只看首尾字符是否为引号，可被拼成时间盲注；现在改为严格标识符白名单，只接受列名、表名.列名 与升降序关键字，其余一律丢弃并回落到默认排序。多站点跳转登录原先把密码哈希当作签名材料，随机串可反复自造且票据不过期；现在换成服务端签发的一次性票据，有效期 120 秒、用一次即失效，并补上账号状态检查与 IP 错误锁定。升级提示里同时要求轮换站点签名密钥并修改管理员口令——这与「补丁后必须核查会话」是同一条经验。日常层面，内置的 JWT 认证、敏感词过滤、内容审核与防采集干扰码把可被匿名触发的面收窄，备份（含静态文件）则决定出问题后能不能回退。

常见问题

没有官方补丁时该不该先停服务？ 先看入口是否匿名可达。若是上传、模板渲染或对外接口这类入口，短时关闭比硬撑更安全；若只有登录后的次要功能命中，可以先收紧访问范围，等修复版本。

只升级是不是就够了？ 不够。升级消除的是触发条件，已建立的会话、被写入的计划任务、被改过的模板文件都要单独核查，确认不清白就重置凭证。

怎么判断自己是否已被打过？ 比对补丁前时间窗的访问日志与文件修改时间，重点看对上传目录的执行记录、异常长度的查询参数，以及数据库里多出权限的账号。