核心层的漏洞波及一批国产建站系统，先确认自己用的是哪一类
漏洞位于 PHP 核心层时，排查顺序和插件漏洞不一样：影响面是按解释器版本区间划定的，上层程序不管是谁写的，只要跑在这段版本上就落在范围内。所以站点先要确认自己用的是哪一类——是预警点名的国产建站系统，还是自研的 PHP 应用，还是根本不依赖这个解释器的编译型程序，再决定升级、临时缓解还是调整部署形态。先看程序名单、后看运行环境，会漏掉自研站点。
核心层漏洞和插件漏洞差在哪
插件漏洞的影响面由组件决定：装了哪个插件、哪个版本、有多少站点装它，处置是升级或停用那个组件。核心层漏洞的影响面由解释器决定，一台机器上的解释器版本在范围内，这台机器上托管的所有 PHP 站点都算暴露面，不管是内容系统、论坛还是自研接口。
差别带来三个实际后果。修复动作落在运行环境而不是后台某个开关，需要逐台生效；同一套程序在不同机器上的结论可能不同，不能拿「我们站点没事」当整批机器的结论；验证要看版本，而不是看有没有升级过程序。
预警点名的都有哪些类别
公开预警把 WordPress、Drupal、Joomla、Laravel 这些基于 PHP 的程序列为受影响面，同时列出国内存量较大的建站系统：帝国CMS、织梦 DedeCMS、迅睿CMS、蝉知、PHPCMS、极致CMS、Discuz! 论坛、Z-BlogPHP、Typecho、齐博CMS，以及一批基于 ThinkPHP 生态的程序。公告给出的版本划线覆盖 8.1 及更早分支，对应处置是升级到安全版本。
这份清单的用法是「对照」而不是「检索自己」。清单里的名字偏程序，不在名单里不代表不在影响面内——自研系统、二开的模板站同样跑在同一个解释器上。
先查运行环境还是先查程序
三步走，顺序不要颠倒。
| 排查项 | 怎么确认 | 记下什么 |
|---|---|---|
| 解释器与版本 | 在服务器上查运行环境的版本标识 | 每台机器的实际版本，不要只看一套环境 |
| 程序类别 | 是否在预警点名清单内，是否二开或自研 | 程序名、来源、维护方 |
| 暴露面 | 后台入口、上传目录、可被外部触发的执行路径 | 哪些路径对外开放 |
| 可升级性 | 依赖扩展、程序对版本的要求 | 能否直接升，还是需先换程序 |
| 回退条件 | 有无备份、恢复点是什么 | 备份时间与恢复验证结果 |
自研或二开的站点最容易卡在第 4 步：程序依赖旧版本，解释器升不动。这时才轮到临时缓解。
升级不了时临时缓解怎么写
临时缓解的写法要满足一条：逐台可执行、可复查。常见的四项是按机器列出的——收敛后台入口的可达范围，限制上传目录的执行权限，关掉用不到的执行能力，把对外接口按需要的最小集合开放。每项写完要能回答「第几台已生效」。
改动前先做一次备份与恢复。数据与静态文件的备份决定的是：缓解措施把某个功能拦掉之后，业务能不能退回改动前的状态。备份完做一次恢复验证，别等到要用的时候才发现包是坏的。
部署形态的差别也要写进结论。以 Go 语言开发的内容管理系统把运行时编译成单个可执行文件，站点不依赖 PHP 解释器，这类核心层漏洞的划线落不到它的运行层上；这不等于没有漏洞，安全边界回到程序自身——内置 JWT 认证、内容敏感词过滤与防采集干扰码，以及针对 SQL 注入和 XSS 的防护是否启用。判断口径是「暴露面不同」，不是「免疫」。
常见问题
站点不在点名清单里就安全吗？ 不安全。清单列的是程序，核心层漏洞按解释器版本划线，自研与二开程序同样跑在这个版本上。
先升级程序还是先升级解释器？ 先确认版本区间是否落在受影响范围内，再看程序支持的版本。多数情况是解释器升级受程序兼容性约束，需要先做备份与恢复验证。
多台机器怎么确认全生效？ 按机器记录版本与处置项，逐台复查一次，不要抽样。抽样带来的问题是漏掉早期扩容时留下的旧环境。
改成编译型系统是不是就不用管这类漏洞了？ 是这类漏洞不用管，不是所有漏洞不用管。暴露面从解释器换成了程序自身，输入校验与后台权限仍要逐项确认。