# php2shell PHP 漏洞：视频网站需要了解的事 **Source:** https://vodlix.com/zh/blog/php2shell-php-vulnerability-october-2026 **Summary:** 面向视频业务的 php2shell 解读：2026 年 10 月 21 日修复的两个 PHP 漏洞、应安装的版本，以及 Vodlix 如何为客户处理了这一问题。 **Published:** 2026-11-02 **Publisher:** Vodlix --- ## Key takeaways 2026 年 10 月 21 日，PHP 发布了 8.5.12、8.4.27、8.3.36 和 8.2.35 以修复 php2shell，这是两个可让未经认证的攻击者在 PHP 服务器上执行代码的严重漏洞。Vodlix 在漏洞公开前就已打上补丁，其客户无需采取任何操作。 - 如果你的视频业务中有任何部分在自己的服务器或托管环境上运行 PHP，请立即更新到修复版本，或请托管商代为更新。 - PHP 8.1 及更早版本已停止支持，这些网站需要的是升级，而不仅仅是补丁。 - 阅读托管商和供应商的通告：AWS 于 2026 年 10 月 21 日发布了公告 2026-143-AWS。 - 在托管平台上，此类更新由平台代你完成；在 Vodlix，只有中间件使用 PHP，并且已完成修复。 2026 年 10 月 21 日，PHP 项目发布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。这些版本修复了两个严重漏洞：CVE-2026-109618 和 CVE-2026-109619，即人们所说的 php2shell。在特定条件下，它们允许未经认证的攻击者在运行 PHP 的服务器上执行代码。[PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) 说得很直白：如果你在运行 PHP，请立即更新。 Vodlix 在漏洞公开之前就已为自己的系统打上补丁。Vodlix 客户无需采取任何操作。 补丁只有装到你的服务器上才能起作用。对视频业务来说，这就是 php2shell 的关键所在。 ## 什么是 php2shell？ {#什么是-php2shell} php2shell 是 PHP 中两个相关远程代码执行漏洞的统称，即 CVE-2026-109618 和 CVE-2026-109619。两者都位于内存管理和错误处理部分，而几乎每个请求都会经过这些 PHP 组件。PHP 项目的安全通告将它们评为严重级别，修复版本于 2026 年 10 月 21 日发布。 PHP Foundation 和 PHP 项目的通告都以 CVE 编号指代这些漏洞，因此在查找供应商和托管商的通告时，请使用这些编号。 ### CVE-2026-109618：PHP 内存耗尽时的内存损坏 {#cve-2026-109618-php-内存耗尽时的内存损坏} 如果某个请求恰好在最不合适的时刻触及 PHP 的 memory\_limit，PHP 可能会留下部分初始化的内部数据，并在随后将其视为有效数据。在使用 mod\_php 的 Apache 上，未经认证的请求可以在任何应用代码运行之前触发这一问题，PHP Foundation 表示，在默认设置下已演示了完整的远程代码执行。在 PHP-FPM 上，也通过应用代码路径确认了远程代码执行。 ### CVE-2026-109619：上一个请求遗留的过期状态 {#cve-2026-109619-上一个请求遗留的过期状态} 在错误的时机发生致命错误，可能会使内部状态指向属于上一个请求的内存。同一 worker 上的后续请求随后就可能使用这块已释放的内存。据 PHP Foundation 称，报告者在使用 mod\_php 的 Apache 上针对一个真实应用演示了远程代码执行。 ## 哪些 PHP 版本修复了 php2shell 漏洞？ {#哪些-php-版本修复了-php2shell-漏洞} 修复版本为 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，均于 2026 年 10 月 21 日发布。根据 [PHP 项目关于 CVE-2026-109618 的通告](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)，这四个分支中所有更早的版本均受影响。如果你运行的是 PHP 8.1 或更早版本，那么你的分支没有补丁。 | 你的 PHP 分支 | 受影响版本 | 更新至 | | --- | --- | --- | | 8.5 | 低于 8.5.12 | 8.5.12 | | 8.4 | 低于 8.4.27 | 8.4.27 | | 8.3 | 低于 8.3.36 | 8.3.36 | | 8.2 | 低于 8.2.35 | 8.2.35 | | 8.1 及更早 | 已停止支持 | 仍在支持中的分支，如 8.5.12 | [TechCrunch](https://techcrunch.com/2026/10/21/php-armageddon-openai-googles-wiz-find-ancient-holes-panicking-the-internet/) 报道称，这些漏洞自 2004 年发布的 PHP 5 以来存在于每个 PHP 版本中，且 PHP 8.1 及更早版本已停止支持。使用这些版本的网站要做的远不止一次小更新。 ## 谁发现了这些漏洞，什么时候发现的？ {#谁发现了这些漏洞-什么时候发现的} 安全公司 Calif 的研究员 Ryan A 于 2026 年 8 月 11 日向 PHP 报告了第一个远程代码执行漏洞，当时正在进行一项于 2026 年 7 月 30 日启动的审计。随后 Wiz 和 OpenAI 报告了更多攻击路径。根本原因可追溯到 PHP 团队在 2024 年首次发现的一个内存问题。 PHP Foundation 的官方说明列出了事件的先后顺序： 1. **2024 年：**在 PHP 多年来的首次外部安全审计中，一名核心开发者发现了内存耗尽问题的最初迹象。当时未找到具体的攻击路径，修复工作因此搬置。 2. **2026 年 7 月 30 日：**Calif 在 Patch the Planet 计划下启动了对 PHP 的审计。 3. **2026 年 8 月 11 日：**Calif 的 Ryan A 报告了一个根本原因相同的无条件远程代码执行漏洞。OpenAI 也独立报告了同一根本原因。 4. **2026 年 8 月 24 日：**Wiz 报告了更多攻击向量。 5. **2026 年 9 月 18 日：**OpenAI 报告了更多攻击向量。 6. **2026 年 10 月 21 日：**PHP 发布了修复版本。 Foundation 对这段空窗期直言不讳：它将 2024 年之后的拖延称为安全团队决策流程及其资源匮乏的“结构性失败”，并表示团队正在改变工作方式。 ## php2shell 有多严重，互联网如何反应？ {#php2shell-有多严重-互联网如何反应} 它之所以严重，是因为 PHP 无处不在，而最坏的情况是攻击者在你的服务器上执行代码。TechCrunch 报道称，PHP 驱动着约 70% 的网站，美国国家安全局建议，如果网站无法立即打补丁，应将其下线。 TechCrunch 还报道称，这些漏洞可能让攻击者访问服务器的文件系统或 Web 应用使用的数据库。在其 10 月 21 日报道发布时，OpenAI 表示这些漏洞是由研究人员先于攻击者发现的，尚无在野利用的报告。但公开披露改变了这一点，因为细节现已公开。 云服务商当天即作出响应。[AWS 发布了安全公告 2026-143-AWS](https://aws.amazon.com/security/security-bulletins/2026-143-aws/)（2026 年 10 月 21 日），标记为“Important (requires attention)”，针对受这两个 CVE 影响的 PHP Web 运行时。 ## php2shell 对流媒体平台或视频网站意味着什么？ {#php2shell-对流媒体平台或视频网站意味着什么} 这意味着要检查你的视频业务中每一个运行 PHP 的部分，而不仅仅是播放器。流媒体网站包含商店、登录、计费流程，通常还有营销网站或博客。如果其中任何一部分在你或你的托管商管理的服务器上运行 PHP，就需要升级到修复版本。 在这里，安全不仅是 IT 任务，也是业务问题。视频网站一旦为等待补丁而下线，停机期间就无法销售订阅和租赁。 WordPress 是一个典型案例。TechCrunch 报道称，WordPress 表示该漏洞并非 WordPress 独有，运行 WordPress 的网站必须为服务器打补丁，并与托管公司协作。 打补丁只是一层防护。我们关于[保护内容和观众的 OTT 安全要点](https://vodlix.com/zh/blog/ott-security-essentials-safeguarding-your-content-and-viewers)的指南涵盖了其他层面，而我们关于[流媒体平台登录安全](https://vodlix.com/zh/features/login-security)的页面则介绍观众账户的防护。 ## Vodlix 如何应对 php2shell？ {#vodlix-如何应对-php2shell} 在漏洞于 2026 年 10 月 21 日公开之前，Vodlix 就已针对 CVE-2026-109618 和 CVE-2026-109619 为自己的系统打上补丁。在 Vodlix，只有中间件使用 PHP，而这正是已修复的部分。Vodlix 客户无需采取任何操作。 在 Vodlix 这样的托管平台上，此类安全更新会由平台代你完成。如果你想报告与 Vodlix 相关的安全问题，请发送邮件至 security@vodlix.com。 ## 如果你自己运营 PHP 网站，应该怎么做？ {#如果你自己运营-php-网站-应该怎么做} 将你运行的每一个 PHP 安装更新到修复版本，或请托管商代为更新，并阅读各供应商的通告。如果无法立即更新，请按照 TechCrunch 报道的 NSA 建议，将网站下线，直到完成更新。 1. **列出所有运行 PHP 的地方。**包括你的主站、任何 WordPress 网站或博客、落地页和管理工具。 2. **检查每一个版本。**与上表进行对照。 3. **自行更新或请托管商更新。**升级到 8.5.12、8.4.27、8.3.36 或 8.2.35。如果使用托管服务，请对方确认更新日期。 4. **为旧分支制定升级计划。**PHP 8.1 及更早版本已停止支持，不会再有补丁。 5. **阅读供应商的通告。**从你的托管商和云服务商开始。AWS 已经发布了一份。 6. **确认新版本已在运行。**更新后在每一台服务器上再次检查。 ## 下一步 {#下一步} 如果你是 Vodlix 客户，则无需为 php2shell 采取任何操作。如有疑问，请访问 [Vodlix 帮助中心](https://vodlix.com/zh/help) 或[联系 Vodlix 团队](https://vodlix.com/zh/contact)。 如果你正在考虑选择一个托管平台，让此类更新由平台代为处理，请查看 [Vodlix 平台功能](https://vodlix.com/zh/features) 或[申请 Vodlix 演示](https://vodlix.com/zh/demo)。 ## 常见问题 **Q: 什么是 php2shell？** php2shell 是两个严重 PHP 漏洞的俗称，即 CVE-2026-109618 和 CVE-2026-109619。PHP Foundation 等官方通告使用 CVE 编号。两者都是 PHP 内存管理和错误处理中的漏洞，在特定条件下允许未经认证的攻击者在服务器上执行代码。PHP 于 2026 年 10 月 21 日修复了这些漏洞。 **Q: 哪些 PHP 版本修复了 CVE-2026-109618 和 CVE-2026-109619？** PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 修复了这两个漏洞，均于 2026 年 10 月 21 日发布。8.5、8.4、8.3 和 8.2 分支中所有更早的版本均受影响。PHP 8.1 及更早版本已停止支持，因此使用这些版本的网站需要迁移到仍在支持中的分支。 **Q: Vodlix 客户需要为 php2shell 做什么吗？** 不需要。在 Vodlix，只有中间件使用 PHP，Vodlix 在漏洞于 2026 年 10 月 21 日公开之前就已为其打上补丁。客户无需采取任何操作。如果你想报告与 Vodlix 相关的安全问题，可以发送邮件至 security@vodlix.com。 **Q: WordPress 是否受 2026 年 10 月 PHP 漏洞的影响？** WordPress 运行在 PHP 之上，因此 WordPress 网站会通过服务器的 PHP 版本暴露在风险中。TechCrunch 报道称，WordPress 表示该漏洞并非 WordPress 独有，运行 WordPress 的网站必须为服务器打补丁，并与托管公司协作。仅更新 WordPress 本身不能代替更新 PHP。 **Q: 在修复发布之前，php2shell 是否已被利用？** TechCrunch 于 2026 年 10 月 21 日报道称，据 OpenAI 表示，这些漏洞是由研究人员先于攻击者发现的，当时尚无在野利用的报告。现在细节已经公开，未打补丁的服务器面临更大风险，这也是 NSA 建议将无法打补丁的网站下线的原因。 **Q: 如果我无法立即更新 PHP，该怎么办？** TechCrunch 报道称，美国国家安全局建议，如果网站无法立即打补丁，应将其下线直到可以修复为止。请询问你的托管商何时会应用 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35，并阅读他们和你的云服务商的通告，例如 AWS 公告 2026-143-AWS。