OpenAI称模型协助发现PHP核心漏洞，Wiz披露可致RCE
OpenAI与Wiz联合披露两项PHP底层漏洞CVE-2026-109618和CVE-2026-109619，统称PHP2Shell，严重性评分为9.2，可导致未经登录的远程代码执行（RCE）及内存信息泄露。漏洞源于PHP致命错误处理中的内存管理缺陷，影响所有PHP安装，尤其mod_php部署方式风险最高。GPT-5.6 Sol与Gemini 4 Argon等模型在漏洞验证与利用路径探索中发挥关键作用。PHP官方已发布8.2.35等修复版本，但更新需落实至实际运行环境。
如果你曾经用 WordPress 搭过博客，或者把公司网站交给外包团队维护，这条 AI 新闻就可能与你有关：模型参与找到的漏洞，落在了支撑大量网站运行的 PHP 底层。
2026 年 10 月 21 日，OpenAI、云安全公司 Wiz 和 PHP 项目分别披露相关进展，两项漏洞被称为 PHP2Shell，可能让未经登录的攻击者在受影响服务器上执行代码，也可能造成敏感内存信息泄露。
这里的 RCE 指远程代码执行，通俗地说，就是外部攻击者有机会让服务器运行自己指定的指令，影响可能超出网页显示异常，延伸到数据、凭证和服务器控制权。
值得关注的有两件事：AI 在真实安全研究中承担了更具体的工作，而 PHP 已经发布修复，网站维护者需要确认补丁是否落实到实际运行环境。
漏洞出在网站共同依赖的底层
PHP 可以理解为网站服务器执行程序的一套语言和运行环境，WordPress、Drupal、Joomla 等内容管理系统都依赖它，所以同一处底层缺陷可能波及许多不同的网站。
两项漏洞的编号分别为 CVE-2026-109618 和 CVE-2026-109619，官方严重性评分均为 9.2 分，属于最高的「严重」等级，编号主要用于让维护者准确对应公告和补丁。
问题与 PHP 处理致命错误时的内存管理有关：请求在特定时刻中断后，内部可能留下尚未完成初始化的数据，或继续保留指向已经释放内存的状态，后续清理和请求处理再把这些状态当成有效信息使用。
可以把它理解为一项工作半途停止，桌上的材料已被收走，登记簿却仍写着它们可用，后续流程按照错误记录继续操作，精心构造的请求便可能把这种混乱变成攻击机会。
Wiz 披露，团队已在 WordPress、Drupal 和 Joomla 等目标上演示无需登录的远程代码执行，这些应用是验证对象，漏洞本身位于 PHP，不能仅凭自己没有使用其中某款建站软件就排除风险。
PHP 官方将所有处理网页请求的 PHP 安装列为风险范围，其中 Apache 通过 mod_php 运行 PHP 的方式风险最高，已演示的攻击可以在网站自己的业务代码开始执行之前触发。
这也解释了为什么「网站代码写得规范」仍不足以应对这次问题，业务程序之下的运行环境同样需要更新，至于某个站点的具体利用路径，则与部署方式和应用行为有关。
AI把研究推进到了可验证的利用
OpenAI 的表述是，安全研究公司 Calif 在其 Patch the Planet 计划中使用 GPT-5.6 Sol 发现了关键缺陷，Wiz 也独立发现并报告了这两项漏洞，PHP 维护者负责主导修复和版本发布。
Wiz 的研究使用了自家 Atlas 工具、Gemini 4 Argon 和 GPT-5.6 Sol，团队特别肯定了 Argon 的贡献，因此把这次成果归给单一模型，会漏掉公开记录中明确存在的其他参与者。
Calif 研究员 Ryan Austin 的复盘提供了更具体的工作过程：他依据自己熟悉的 PHP 漏洞历史提出研究方向，再让模型协助检查代码、追踪异常处理路径，并把发现的问题模式用于寻找相关变体。
Ryan 同时强调，初始发现没有依赖特殊的模型使用权限，研究者对目标的了解仍然重要，简单提示词也无法让模型找出所有漏洞，这为「AI 自动攻破互联网」一类说法划出了必要边界。
这次进展尤其值得看的一点，是从发现异常走到了证明异常可以造成什么后果，能让程序崩溃，与能稳定展示服务器被远程控制，给维护者带来的判断依据有明显区别。
PHP 基金会披露，2024 年就已经出现相关内存耗尽问题的线索，当时尚未找到具体利用路径，修复方案又牵涉兼容性、性能和扩展生态，工作曾多次停滞，基金会也承认其中存在流程与资源不足的问题。
因此，这段历史不能简单概括成所有人多年都没看见漏洞，更准确的变化是：后续研究证明了严重影响，推动修复成为最高优先级，也让长期存在的工程难题必须尽快作出取舍。
补丁发布后，还要确认谁来更新
对网站负责人来说，眼下最有用的动作是联系技术团队或托管服务商，确认网站是否使用 PHP、实际运行的是哪个版本，以及谁负责完成这次安全更新，外包交付的网站也需要有人回答这些问题。
PHP 官方本次发布的修复版本为 8.2.35、8.3.36、8.4.27 和 8.5.12，应按所在分支及供应商公告选择更新，部分系统发行商提供回移补丁，不能只看主版本数字下结论。
PHP 8.1 及更早版本已不再获得 PHP 项目的常规更新，使用这些版本的团队需要向发行商或长期支持供应商核实修复，或者迁移到受支持的版本，旧版本不能因网站仍能打开就继续忽略。
只更新 WordPress、主题或插件，不能代替更新 PHP 运行环境，Automattic 在公告中也明确提醒了这一点，服务器底层与建站程序属于不同的更新对象。
托管服务的处理状态同样需要具体核实，Automattic 表示其列出的 WordPress.com 等平台站点已获保护；Google Cloud 则区分了自动更新与需要用户重新部署的服务，自建容器还需要更新镜像并部署到线上。
网页防火墙可以提供额外防护，PHP 官方也给出了针对部分攻击路径的临时缓解措施，但明确指出只有更新才是完整解决方案，调整配置不能直接等同于漏洞已经修复。
对普通读者，这条消息不意味着自己的每个账号都已泄露；对维护者，尚未看到异常也无法证明服务器安全，漏洞是否存在、攻击是否成功和数据是否外泄，需要分别核查。
读完几方记录，我更在意的是发现之后的工作：修复要经过验证，供应商要分发更新，维护者要把更新真正部署下去，AI 加快了找问题的过程，互联网能否因此更安全，还要看这些环节能否跟上。
JOTO 企业落地观察
- 企业若采用开源组件构建关键业务系统，需将底层运行时（如 PHP、Node.js、JVM）纳入统一漏洞响应流程，不能仅聚焦于应用层组件。
- AI 辅助安全研究正从「异常识别」迈向「利用链验证」，这对企业红蓝对抗演练中自动化 PoC 生成工具的选型与集成提出新要求。
- 当漏洞影响跨多层技术栈（如 mod_php → Apache → Linux 内核），企业需明确各层责任归属与协同升级机制，避免因「非我开发」而延迟响应。
- 托管服务提供的「已防护」声明需结合具体部署方式验证，尤其是容器化、Serverless 等场景下，补丁是否注入运行时镜像或函数执行环境，须由运维团队实测确认。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们
