Hacker News 中文摘要

RSS订阅

Cloudflare 针对 php2shell 漏洞推出防护措施 -- Cloudflare deploys protections against php2shell vulnerability

2026 年 10 月 21 日,Cloudflare(Cloudflare)宣布已部署针对 php2shell 漏洞的防护措施。php2shell 是一个影响 PHP 的安全问题,Cloudflare 通过 Web 应用防火墙(WAF)加入相应规则,帮助使用该服务的站点识别并拦截针对这一漏洞的相关利用尝试,降低相关应用被攻击的风险。

正文

Cloudflare 关于 php2shell 漏洞防护的文章配图

今天,Calif.io、Wiz、OpenAI 和 Quarkslab 披露了 PHP 中的两个漏洞,编号分别为 CVE-2026-109618 和 CVE-2026-109619,被称为 php2shell。这些漏洞影响所有运行 PHP 5.4 或更高版本的 Web 服务器,当应用程序处理特制的 HTTP 流量时,攻击者可能借此造成拒绝服务、远程代码执行和数据泄露。

Cloudflare 参与了保护互联网的协同响应,与 PHP 基金会、OpenAI 和 Wiz 等机构共同部署缓解措施。Cloudflare 自 2026 年 10 月初就已开发并部署了 Web 应用防火墙(WAF)防护,比公开披露提前了大约 9 小时。从 UTC 时间 10 月 21 日 3:02 开始,使用 Cloudflare 免费或付费 WAF 的客户已默认受到保护,免受 php2shell 影响。

该漏洞在正式发布日前泄露,在此期间 Cloudflare 已为所有客户成功部署了多项缓解措施,并观察到针对客户的攻击流量。我们通过跟踪匹配量并与规则逻辑交叉比对,观察到攻击者如何不断变换攻击载荷,试图绕过我们的防护。

防御 php2shell 需要的不仅仅是标准的基于请求的规则。仅靠请求数据并不总能提供足够证据来区分漏洞利用和合法流量。源站响应能补充上下文,帮助判断利用是否成功,同时降低误报风险。

为了提供这种防护,我们开发了全事务检测(full transaction detection)——这是 Cloudflare WAF 的一项新功能,可以结合同一 HTTP 事务中请求和响应的信号。响应规则可以在匹配的源站响应到达请求者之前将其拦截。php2shell 防护是我们利用该功能发布的第一批托管检测规则。有关其工作原理,请参阅我们的全事务检测博客文章。

我们的安全分析师会持续监控攻击活动,并在未来几小时或几天内出现新技术和变体时更新规则。你可以在更新日志中跟踪新规则。

关于漏洞我们已知的信息

近 70% 的网站使用 PHP。php2shell 漏洞影响 PHP 运行时本身,可能允许攻击者在存在漏洞的服务器上执行恶意代码、暴露客户数据或中断服务。由于 PHP 支撑着 WordPress 和 Magento 等广泛使用的平台,这些缺陷可能影响互联网上大量应用程序。

这两个漏洞涉及 PHP 在处理 HTTP 请求时出错后的内存处理方式。通常,PHP 会分配内存来存储处理请求所需的数据,并在处理完成后释放。如果处理意外中断,例如内存耗尽,PHP 就无法安全清理内存。当 PHP 处理错误并随后尝试使用尚未完全初始化的数据,或已经被释放的内存时,这些漏洞就会出现。

攻击者可以发送特制的 HTTP 请求来触发这些情况。大型请求是给内存施压的一种方式,但问题不止于消耗服务器资源。通过操纵 PHP 在这块无效内存中遇到的数据,攻击者可能使 PHP 进程崩溃、暴露敏感信息,或执行攻击者提供的代码。

这两个漏洞的区别在于不安全内存访问发生的时机:

| 漏洞 | 问题所在 | | --- | --- | | CVE-2026-109618 | PHP 耗尽内存并在部分内部数据被正确初始化之前中断工作。在清理该请求时,PHP 可能会把这些未完成的数据当作有效数据使用。 | | CVE-2026-109619 | 致命错误中断请求,导致 PHP 持有一些内存引用,而这些内存在请求结束时就已被释放。当同一 PHP 进程处理后续请求时,可能会追随这些过时的引用,访问已不再有效的内存并暴露敏感数据。 |

这些缺陷位于 PHP 运行时中,因此仅更新网站代码或插件无法修复漏洞。管理员需要更新运行其应用程序的 PHP 软件。如果 PHP 由托管服务提供商管理,应要求提供商应用安全更新。

管理员可以关注 PHP 公告,了解受影响版本和修复说明。在修补期间应保持 Cloudflare WAF 防护开启。限制不必要的上传并限制上传大小也能减少暴露面,但这些措施不能替代 PHP 修复。

新规则

对于免费版客户,新规则已在 Cloudflare Managed Free Ruleset(规则集 ID 77454fe2d30c4220b5701f6fdfb893ba)下发布。免费客户无需执行任何操作即可启用防护。若要覆盖规则集行为,请参阅我们的文档。

| 规则描述 | 规则 ID | | --- | --- | | 通用规则 - 异常执行 - 1 | 4e315666e8e344cdb64119a3b5ccf32f | | 通用规则 - 异常执行 - 2 | 00c10e6cc4da4bd08722adeebcd95984 | | 通用规则 - 异常执行 - 3 | 48ddf592361e4fdb97a8a85982dab691 | | 通用规则 - 异常执行 - 4 | 3556683d512a47f2937899c524b1a4c6 | | 通用规则 - 异常执行 - 5 | da07c85852e34625bb478496302ede46 | | 通用规则 - 异常执行 - 6 | 19373a83abb840e18ab3ce5a7975ce1b | | 通用规则 - 异常执行 - 7 | 07f0b6ddaabf40b1b2042dade8d613fa |

付费套餐的防护已作为 Cloudflare Managed Ruleset(规则集 ID efb7b8c949ac4650a09736fc376e9aee)的一部分发布。如果您使用的是 Professional、Business 或 Enterprise 套餐,请检查您的 Managed Ruleset 部署,确认其已部署为阻止模式。

Image 1: Daniele Molteni

Image 2: Dan Jones

Image 3: Kuber Nandwani

Image 5

| 规则描述 | 规则 ID | | --- | --- | | 通用规则 - 异常执行 - 1 | c1d409ad838f47f59446f21cc438d5dd | | 通用规则 - 异常执行 - 2 | f9a45927414245e3a64bb12d0a0c2f64 | | 通用规则 - 异常执行 - 3 | 771c654ae1154d4daa72f4e1545d163c | | 通用规则 - 异常执行 - 4 | 217005865f0145f392300bac212afcc9 | | 通用规则 - 异常执行 - 5 | 38efdb17ea594501bb55a1d71867b12e | | 通用规则 - 异常执行 - 6 | 4148ae686fdb4d01be673fab9d9c073d | | 通用规则 - 异常执行 - 7 | 1389aa259617437392ce149c48143645 |

以下规则已部署到新的 Cloudflare Managed Response Firewall Default,供所有套餐(包括免费版)客户使用:

| 规则描述 | 规则 ID | | --- | --- | | 针对高置信度签名的默认阻止 | afffe22785674c80a31875c848d2242a |

注意:规则描述即将更新。

Image 6: Cloudflare

查看事件并定制防护

Image 8: Elie Roudninski

Image 9: Nick Downie

Image 10: Jenny Lea

Image 11: Max Brosnahan

Image 12: Matthew Conroy

Image 13: Christopher Patton

Image 14: Bas Westerbaan

Image 15: Trishna

Image 16: Jeremy Hartman

要分析被拦截的请求,请访问 Security(安全)> Security Analytics(安全分析)> Events(事件)。按上文表中的规则 ID 筛选,并检查匹配的请求、操作和路径。事件会标明操作来自托管规则还是自定义规则。需要定制防护的客户可以调整 Managed Ruleset 的作用域,将其应用到应用程序中相关的部分。

Image 17: Cloudflare

更新 PHP 并保持防护开启

使用 Cloudflare Managed Ruleset 的客户默认已受到保护。我们建议遵循公告中的建议,尽快将供应商更新应用到您的 PHP 仓库,同时保持 WAF 防护开启,作为额外的保护。我们的 WAF 分析师会继续在新攻击技术出现时更新防护。

Image 18

Image 19

Image 20

Image 21

评论

较多人感谢 Cloudflare 的快速缓解措施,认为它能让大量网站免于被攻破;但讨论的分歧主轴在一则高赞担忧:能端到端渗透的开源权重大模型,叠加大公司主导的防护,会让本就强势的基础设施巨头进一步成为“开放互联网”的守门人,另有少数人认为根本出路是增加安全专家与网络安全投入。

感谢并肯定 Cloudflare 的快速防护措施

  • Cloudflare 的动作被认为非常迅速,有评论连声惊叹其速度;同时其单一缓解措施被认为能挡下大量自动化渗透,让无数网站免遭攻破,评论者对此表示感谢。(较多人)
  • > “谢谢 Cloudflare,仅此一举就能让数百万网站免于被攻破。”(@CrimsonRain)

担忧开源权重大模型渗透能力与大公司防护叠加,会催生开放互联网的守门人

  • 即便是低门槛使用者,也可能只靠投入算力并给出“帮我赚钱”这类简单提示,就驱动开源权重模型完成端到端网络攻击;而当前依赖 Cloudflare 这类基础设施巨头的缓解方案,会让本就掌握大量数据与权力的实体进一步扩张,最终成为“开放互联网”的守门人。评论者对此高度担忧,并希望找到更安全、权力更平等的调整方式。(高赞)
  • > “能够端到端渗透的开源权重模型,叠加大公司主导的缓解措施,会让权力进一步集中,使它们成为开放互联网的守门人,这非常令人担忧。”(@mentalgear)

认为应增加安全专家与网络安全投入

  • 在接连出现安全事件后,现在和未来显然需要更多安全专家,或在网络安全上投入更多时间,这被视作应对威胁的基础方向。(少数人)
  • > “经历了这么多安全问题,现在和未来显然需要更多安全专家,或在网络安全上投入更多时间。”(@lexoj)