一位可靠消息人士透露，一场相关公告目前已经定于2026年10月22日18:00中欧夏令时（CEST）发布，内容涉及两个 PHP 远程代码执行（RCE）漏洞，这两个漏洞的通用漏洞评分系统（CVSS）评分均为10.0。除“来源：信我，兄弟”（source: trust me, bro）这一说法外，我没有其他证据。

有可靠消息来源称，关于两个 CVSS 评分为 10.0 的 PHP 远程代码执行（RCE）漏洞的公告，定于 2026 年 10 月 22 日 18:00 CEST 发布。 除了“消息来源：信我，兄弟”之外，我没有其他证据；但如果你在生产环境运行 PHP，请优先准备更新。 据报道，这些 CVE 涉及 PHP 5 及之后所有受影响版本中的远程代码执行。 据称即将公布的这两个保留 CVE 是：CVE-2026-109618 和 CVE-2026-109619。

lol768 表示，有时候把细节直接公开、走完全披露（Full Disclosure）对大家都更好，而他认为几小时前就已经到了这一步。看到 Twitter（以及那些泄露，虽然不知道可靠性如何）竟然成了比其他渠道更好的信息来源，他感到非常沮丧；至少对于自己托管服务的人来说，可以借此尝试研究在官方修复版本发布前能否采取一些防御措施。他怀疑漏洞现在已经在被实际利用了。他给出了一条推文：https://x.com/J4ck3LSyN/status/2112703096443097263，称对方还发布了概念验证（PoC）。

jwitthuhn 回复说，看来某些进行“负责任披露”的人并不怎么负责任，信息泄露了出去。既然信息已经公开，假设那条推文属实，他们真的应该直接发布修复。他补充说，受影响版本的缓解措施是在 php.ini 中把 session.upload_progress.enabled 设为 Off。

lol768 引用了上述缓解措施，认为这只是部分缓解：https://x.com/Dinosn/status/2112717168349712734。他还额外采纳了建议，在请求到达 PHP 之前就禁止 multipart 上传（幸好他的应用完全不用）。他说，我现在知道这是否能彻底解决问题。

Webfiletools_de 提醒今晚应用该措施的人注意一个坑：在很多 Debian/Ubuntu 式环境中，CLI 和 PHP-FPM 读取的是不同的 php.ini 文件（例如 /etc/php/8.x/cli/ 与 /etc/php/8.x/fpm/），所以在 shell 里执行 php -i 可能显示 Off，而 Web 侧仍是 On。应该通过 phpinfo() 页面或 FPM 二进制文件本身检查，并记得之后重载 php-fpm。在无法修改主 ini 的共享主机上，可以按目录在 .user.ini 中设置，但该文件默认会被缓存几分钟，因此测试前要等一会儿。正如其他人所说，在真正的补丁到来前，这只能算权宜之计。

potaytopotahto 说，漏洞利用的细节似乎已经在 Twitter 上泄露；如果信息正确，在有机会更新之前，可以通过把 session.upload_progress.enabled 设为 Off 来缓解。

phab 贴出了一则据称展示漏洞利用过程的推文（视频）：https://x.com/k_firsov/status/2112641845926989944，并说“吓人”。

coderdiaz 称，完整细节将在墨西哥城时间上午 8:00 公布。

lioeters 说，该漏洞已经被第三方借助 LLM 复现，而且对方还在 Twitter 上发布了细节——刚才也有人在这里贴了链接，所以秘密已经彻底泄露。这意味着大约 70% 的网站（WordPress、Laravel、Drupal、Joomla、Magento）目前都面临远程代码执行风险。其中约一半运行的是较旧的 PHP 5 和 PHP 7，而这些版本似乎不会收到紧急安全补丁。他引用称，这是 PHP 的 session.upload_progress 处理程序中两个堆释放后重用（use-after-free）原语。最后他半开玩笑地说，看来是时候用 Rust 重写 PHP 了，并喊话 Claude：“别出错，你能行！”

HotGarbage 贴出了 PHP 官方存档链接：https://www.php.net/archive/2026.php#2026-10-20-1。

ShowalkKama 提出疑问：那两个 CVE 指的是 WordPress 插件（而非 PHP）中的漏洞，而且并不是 RCE 漏洞。他问自己是不是漏掉了什么，并附上 NVD 页面：CVE-2026-9618 和 CVE-2026-9619。

dylanpyle 回复说，即将公布的应该是 CVE-2026-109618 / CVE-2026-109619，而不是 9618/9619。

ShowalkKama 回复说自己甚至复查过，是“我瞎了”。

unreal37 说，这件事本来应该在披露禁令（embargo）之下，所以那个“可靠来源”根本守不住秘密。

reddalo 贴出了 PHP 发布的官方声明：https://www.php.net/archive/2026.php#2026-10-20-1，以及 CERT-EU 的声明：https://cert.europa.eu/publications/security-advisories/2026-018/。他引用 CERT-EU 的建议：“在无法立即修补的情况下，组织应考虑在修复可用之前，将面向互联网的应用程序与公共网络隔离。” 他表示情况看起来很严重，并吐槽说，把全部 PHP 应用从公共互联网隔离，祝你好运。

archon810 贴出所谓的演示视频，名为 php2shell，链接同为：https://x.com/k_firsov/status/2112641845926989944，称其“可怕至极”。

kevinday 更正前面的说法：PHP 表示补丁/公告将在 2026 年 10 月 21 日（星期三）14:00 UTC 发布，并附上链接：https://www.php.net/archive/2026.php#2026-10-20-1。

gnabgib 确认，现在改成了星期三，但原本定的是星期四；正是因为这个 HN 帖子，时间被提前到了明天。

SchizoDuckie 说，太好了谢谢，他现在就需要细节：问题出在核心？扩展？还是什么配置？他猜和某个请求过滤功能有关。

reddalo 回复说，是的，问题在核心；从 PHP 5 开始的所有版本都受影响，只有 PHP 8 会收到补丁。

joshuat 说，那么几百万个 WordPress 站点一夜之间就会变成攻击目标；不过他觉得这也没怎么改变现状。

Yiin 回复说，肯定不会只修 PHP 8，那样太荒唐了。

rpeden 指出，8.2 之前的版本都已停止维护（EOL）。

dwm 说，细节定于 UTC 时间明天 14:00 披露，但该时间仍可能变化。

讨论气氛焦虑且急切，多数人认为 PHP 漏洞细节已提前泄露、可被远程代码执行且影响极广，应尽快披露或临时缓解；少数人则质疑被点名的 CVE 其实针对 WordPress 插件、并非 PHP 本身的远程代码执行，社区也对保密期失效和官方信息发布过慢普遍不满。

认为漏洞已被复现且细节全面外泄，现实威胁迫在眉睫

• 第三方复现、演示视频和概念验证相继出现，细节在 Twitter 上全面泄露；若信息正确，约七成使用 WordPress、Laravel 等 PHP 生态的网站面临远程代码执行，其中约半数仍运行不会获得紧急补丁的旧版 PHP 5 和 PHP 7，且很可能已在被积极利用；在官方修复版发布前只能先尝试临时防御。（较多人） > 第三方已借助大模型复现漏洞，细节发到 Twitter 后等于彻底公开，约七成相关网站面临远程代码执行（@lioeters）

认为应立刻全面公开细节，而不是继续等官方节奏

• 既然 Twitter 上的泄露比官方渠道更快、更实用，继续保密只让自建服务者无从防御；不如走向完全披露，先靠社区自行寻找缓解措施，而且漏洞可能正被积极利用。（较多人） > 早就到了该完全披露的时候，Twitter 泄露反而比官方信息更有用，自建服务的人只能先自己寻找防御措施（@lol768）

质疑被点名的 CVE 其实是 WordPress 插件漏洞，并非 PHP 本身的远程代码执行

• 有人核对漏洞数据库后认为，相关 CVE 针对的是 WordPress 插件，而不是 PHP，也不构成远程代码执行，怀疑讨论把问题搞错了。（少数人） > 被提到的 CVE 其实针对 WordPress 插件而非 PHP，而且并非远程代码执行，怀疑有人把问题搞混了（@ShowalkKama）

认为官方已发布声明，无法立即修补时应先隔离面向互联网的应用

• PHP 官方与 CERT-EU 都已发出公告；CERT-EU 建议无法及时修补的组织先把面向互联网的应用从公网隔离，直到修复可用，但实际要把所有 PHP 应用都隔离并不现实。（少数人） > 若无法立即修补，组织应考虑先把面向互联网的应用从公网隔离，直到修复可用（@reddalo）

认为本应保密的详情已被提前泄露，官方完整细节还要等到既定时间

• 有人指出信息本应处于保密期却已被泄露，所谓可靠来源守不住秘密；另有评论称完整细节将在墨西哥城时间上午八点才公布，目前只能先依靠泄露和临时缓解措施。（少数人） > 这本应处于保密期，结果所谓可靠来源根本守不住秘密（@unreal37）

有价值的补充

• 临时缓解：若泄露细节正确，在有机会升级前，可先将 PHP 的 session.upload_progress.enabled 设为 Off（@potaytopotahto）。
• 技术根源：漏洞来自 PHP 的 session.upload_progress 处理程序中的两个堆释放后重用原语，属于内存安全问题（@lioeters）。
• 已出现名为 php2shell 的演示视频/利用，观看者形容其可怕（@archon810）。
• 面对内存安全问题，社区出现“用 Rust 重写 PHP”的玩笑，并调侃让 Claude 接手且不要写错，反映出对 PHP 长期内存安全问题的无奈（@lioeters）。