这两天技术圈被两条消息刷屏：一边是 PHP 两个严重漏洞（CVE-2026-109618、CVE-2026-109619）被提前泄露，官方宣布 10 月 21 日紧急发补丁；另一边是 curl 维护者公开调整低危漏洞披露策略，直面 AI 批量"刷 CVE"的洪流。作为站长，你可能第一反应是："我的 WordPress / emlog 会不会中招？要不要立刻关站？"先说结论：不用恐慌性关站，但今天必须做一次排查。这篇文章帮你理清三件事——漏洞到底是什么、你到底受不受影响、具体怎么查。
一、漏洞到底是怎么回事
一句话概括：PHP 官方确认存在两个严重漏洞，CVSS v4.0 评分均为 9.2，被独立安全研究者判断为"远程代码执行（RCE）"。所谓 RCE，就是远程攻击者可能直接在你的服务器上执行代码——这正是它让人紧张的原因。
攻击面线索指向 PHP 的 session.upload_progress 功能（会话上传进度，自 PHP 5.4 引入且默认开启）。泄露的研究材料描述，其中一个被成功复现的路径涉及"释放后使用（use-after-free）"这类内存错误，另一个路径被描述为"会话文件注入 + 应用层本地文件包含"的组合利用。研究者 Kirill Firsov 把它们统称为 "php2shell"。
但有几个关键事实，必须和标题党拉开距离：
注意：
- CVE 编号来自 watchTowr 等研究者与泄露材料，PHP 官方公告本身并未点名这两个 CVE。
- 所谓"影响 PHP 5 到 8"是泄露信息，官方公告尚未确认具体受影响版本。
- 截至目前，没有野外利用（in-the-wild exploitation）的确认报告。watchTowr 明确说没看到实际利用。
为什么这件事值得站长认真对待？把 PHP 运行时想象成房子的地基——这次是地基本身可能有裂缝，而不是你装的某个主题或插件。泄露材料指出，上传进度的处理发生在你的应用代码执行之前，所以"我的站点没有上传功能 / 没有登录入口"并不能直接判定安全。
洞察： 判断风险的核心不是"我有没有上传按钮"，而是"我的服务器跑的是哪个 PHP 版本、怎么配置的、有没有暴露在公网"。
二、明确受影响与修复版本（先说清时效）
这里有一个必须诚实说明的时效前提：截至本文写作（10 月 21 日晚），官方补丁包尚未发布，计划于北京时间 22:00 发布，准确的受影响版本与修复版本届时才会随 php.net 公告公布。因此下面的数字，需要以 php.net 公告为最终准绳。
根据泄露材料与研究者信息，目前能拼出的大致情况是：
| 维度 | 官方已确认 | 泄露 / 研究者信息（待确认） |
|---|---|---|
| 漏洞性质 | 两个严重漏洞，CVSS 9.2，疑似 RCE | — |
| 疑似攻击面 | — | session.upload_progress（默认开启） |
| 受影响版本 | 官方未公布 | 疑似 PHP 5.4.0 起 |
| 修复版本 | 官方将于 22:00 公布 | 疑似 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 |
| 野外利用 | 未确认 | 研究者称暂未发现 |
关于 PHP 的官方支持状态，这一点很关键：当前仅 8.2、8.3、8.4、8.5 四个分支受官方安全支持（8.2 的安全支持到 2026 年 12 月 31 日）；8.1 及更早版本已停止维护，大概率不会收到官方补丁。 这意味着用老版本 PHP 的站长，临时缓解措施更重要，同时得规划迁移。
三、3 步风险自查方案
按这三步来：
- 摸清家底——列出所有运行 PHP 的主机与容器，记录版本与来源；
- 临时缓解——补丁到来前，关闭上传进度并拦截 multipart 请求降风险；
- 等补丁立升级——22:00 起盯官方公告，升级到修复版本并建立台账。
第 1 步：摸清家底。
把"所有跑 PHP 的地方"列一遍：Web 服务器、容器（尤其是 PHP-FPM / Docker 镜像）、虚拟主机面板、被遗忘的子域名后台、测试环境。怎么查版本？命令行 php -v，或在主机面板里看；Debian / Ubuntu 上 ls /etc/php 能直接看到装了哪些分支。
注意：WordPress、emlog、Typecho 只是"壳"，底层 PHP 版本才是关键。还要查 mod_php / PHP-FPM 用的是哪个版本，别只看 CLI 版本——很多服务器 Web 用的 PHP 和命令行不是同一个。
第 2 步：临时缓解（仅在等补丁的几个小时里用）。
必须先说清楚：这不是 PHP 官方缓解方案，只能降低风险。PHP 核心开发者 Gina Peter Banyard 的原话是："我能说的唯一缓解措施，就是打补丁 / 升级 PHP。可惜我知道的太多了。" 临时措施只在"补丁还没来"的窗口期有意义。
- 关闭上传进度：在 Web 用的 php.ini 里加
session.upload_progress.enabled = Off；用 PHP-FPM 的，还要加php_admin_flag[session.upload_progress.enabled] = off把它锁死（防止被.user.ini覆盖），然后重启 PHP-FPM。副作用只是基于该功能的进度条失效——WordPress 默认不用这功能，关掉风险很低。 - Web 服务器层拦截 multipart：在 nginx / Apache / Caddy 上，于请求到达 PHP 之前拒绝 Content-Type 含
multipart的请求（返回 403）。注意 PHP 8.4 的request_parse_body()也能解析其它方法的 multipart，所以别只拦 POST。
注意： 这两步不覆盖所有攻击链，不能替代升级。它们只是帮你撑到补丁落地，补丁装好后记得把配置改回去。
第 3 步：等补丁、立升级、做台账。
北京时间 22:00 起盯 php.net 公告，按官方确认的修复版本升级，并重启 PHP-FPM 让新二进制生效，用 php -v 确认。用发行版 / 容器 / 托管商提供 PHP 的，等供应商标注"已修复相关 CVE"的安全更新，更新后同样重启服务进程。
EOL 版本（8.1 及更早）无官方补丁：要么升级 PHP 大版本，要么隔离——限制公网访问、上 WAF、最小权限运行。最后建立一份 PHP 版本台账，别漏掉容器里那个还在跑旧版本的实例。
四、底层组件总在"出事"，站长如何构筑长效防线
把视野拉远一点。和 PHP 这条新闻几乎同时，curl 维护者 Daniel Stenberg 在 10 月 20 日宣布：从 10 月 26 日起，curl 的低危 / 中危漏洞报告将转到公开的 GitHub Issues，只有高危和严重继续走私有 HackerOne。
| 数据 | 含义 |
|---|---|
| 90%+ | curl 过往提交中被快速判定低于"高危"的比例 |
| 7 人 | curl 安全团队的维护者规模 |
| <5% | 2025 年确认漏洞占提交的比例（年初还高于 15%） |
为什么？Stenberg 说的是"报告雪崩"——AI 工具把新发布的 CVE 修复"喂"回自动化脚本去翻类似问题，还批量生成"现实中几乎不可能出现的奇怪选项组合"，把微小差异当成漏洞提交。curl 团队只有 7 个人，2025 年每周收 3–4 份报告，真实漏洞占比却从 15% 以上跌到 5% 以下。他们早在今年 1 月就关掉了 HackerOne 漏洞赏金计划。
这对站长的启示很直接：底层组件（PHP、curl、OpenSSL、Linux 发行版）的漏洞通报会越来越多——不全是因为更危险，也因为披露更透明、自动化报告更泛滥。 恐慌没用，系统化才有用。
建议： 构筑长效防线，从这四件事开始：
- 订阅官方渠道：php.net 安全公告、你的发行版 / 托管商安全邮件、CERT 通报，让"有补丁"第一时间知道。
- 固定补丁节奏：能用 unattended-upgrades / 供应商自动更新的就开；自建服务器的，定一个"补丁日"。
- 缩小暴露面：非必要不把管理后台、测试环境暴露公网；上 WAF；最小权限运行 PHP 进程，限制可写 / 可执行目录。
- 依赖台账 + 生命周期管理：记清每个站点用的 PHP / 组件版本与来源；对 EOL 版本提前规划迁移，别等出事。
关站解决不了地基问题，但一次认真的排查，加上一套长效机制，能让你在下一波漏洞来袭时，从"恐慌刷新闻"变成"按清单操作"。
你的服务器现在跑的是哪个 PHP 版本？欢迎在评论区告诉我，我帮你判断今晚要不要立刻升级。也建议把这份清单收藏起来，补丁发布后照着做一遍。
资料来源
- PHP.net 安全公告（即将于 10 月 21 日 14:00 UTC 发布）：php.net
- BleepingComputer：PHP warns admins of two critical flaws, emergency patches coming tomorrow
- watchTowr / CERT-EU 相关通报（CVE-2026-109618、CVE-2026-109619）
- Daniel Stenberg（curl）官方博客与 The Register 报道：curl 低危漏洞披露策略调整
- 慢雾、安全内参等中文安全媒体编译通报
提示：官方补丁计划北京时间 22:00 发布，文中"疑似修复版本"届时以 php.net 公告为准；临时缓解措施仅为等补丁窗口期的权宜之计，不可替代升级。