PHP2Shell 事件后，互联网又安全吗？用户和网站所有者需要了解的事

目录

• 你可能想知道
• PHP2Shell 意味着什么？网络是否安全？
• 重点摘要表
• 后续……

你可能想知道

• PHP 发布安全更新，是否意味着所有存在漏洞的网站现在都受到保护？
• 普通用户是否应该更改密码，或因为 PHP2Shell 而避免使用加密货币网站？

PHP2Shell 意味着什么？网络是否安全？

PHP 安全危机已从紧急披露阶段，转入艰难的更新安装和入侵检查工作。两个漏洞合称 PHP2Shell，攻击者可以利用它们在不登录的情况下控制存在漏洞的服务器。PHP 已发布安全更新，各组织也开始修补系统，或暂时让部分网站下线。然而，修复程序一经发布，并不意味着所有服务器就会自动受到保护：负责这些系统的人员和组织必须安装相应版本，并重新启动 PHP，修复程序才会生效。

对于普通互联网用户来说，这并不意味着互联网本身停止运行，也不意味着个人手机和笔记本电脑会自动受到影响。主要风险在于服务器尚未完成安全防护的网站和在线服务。这一区别很重要：存在漏洞的服务器可能托管人们访问的网站，但访客自己的设备不一定会受到漏洞影响。这令人稍感安心，但不代表这起事件无关紧要。遭入侵的网站可能误导访客、泄露信息，或提供有害内容。

PHP 是网站在幕后使用的编程语言和运行环境。来源指出，在已知服务器端语言的网站中，约有 70% 使用 PHP。由于 PHP 应用广泛，其弱点可能影响各类组织，从私人网站到政府服务皆然。PHP2Shell 指的是两个不同的漏洞，编号为 CVE-2026-109618 和 CVE-2026-109619。据报道，这些漏洞造成的影响尤其严重，因为攻击者可能不必先通过身份验证，就能控制受影响的服务器。

来源所述，PHP 于 October 21 发布的版本仍是唯一完整的修复方案。根据其版本说明，该项目于 Wednesday 发布了 8.5.12、8.4.27、8.3.36 和 8.2.35 版本。该项目的指导十分明确：“没有完整的缓解措施，更新是唯一安全的选择。”截至 Thursday，PHP 尚未发布后续补丁。安装更新并重新启动 PHP 是必要步骤；仅仅知道修复程序存在，并不会改变服务器上的软件。

在本文所述的情况下，更新不会自动应用。托管公司、企业 IT 团队、公共部门技术部门，以及个人网站所有者，都必须更新自己管理的系统。有些组织可能管理多台服务器，或必须先完成测试流程才能部署变更，这可能拖慢更新进度。因此，即使修复程序已经公布，网站仍可能存在漏洞。PHP 8.1 和更早版本已不再获得官方发布，这给旧系统带来了额外挑战。PHP 安全团队确实为自行编译软件的用户发布了 7.4、8.0 和 8.1 的基础补丁，但这些补丁不等同于当前版本所享有的正常官方发布支持。

攻击活动的规模令人震惊，但攻击尝试不等于成功入侵。Cloudflare 首席执行官 Matthew Prince 表示，在公开公告前的 10 hours，该公司的网络上出现了数千次漏洞利用尝试。公告后的 45 minutes 内，活动攀升至数万次；两小时内达到数十万次，之后累计达到数百万次。这些数字显示攻击者迅速开始测试这一弱点，但仅凭这些数字，无法确定有多少服务器成功遭到控制。

Amazon 报告称，活动迹象出现得更早。该公司表示，其诱饵服务器于 October 17 记录到一次尝试，比漏洞公开早了四天。Amazon 首席信息安全官 CJ Moses 表示，目前仍不清楚攻击者如何在漏洞披露前获得漏洞利用信息，并形容 PHP2Shell“目前正在野外遭到广泛利用”。这一时间点意味着，防御者不应假设公开公告就是所有漏洞利用活动的起点。在披露前运行过存在漏洞版本的服务器，除了更新之外，也可能需要检查是否有更早遭到访问的迹象。

德国和日本政府的说法提供了较令人安心、但范围谨慎的情况。德国联邦信息安全局 BSI 副局长 Thomas Caspers 表示，该机构观察到了攻击，但尚未发现成功利用漏洞的案例。他补充说，利用漏洞似乎“比预期稍微复杂一些”。日本内阁官房长官 Minoru Kihara 也表示，尚未确认有攻击利用这些漏洞。这些说法并不能证明全球没有任何组织遭到入侵，只能说明在这些官员发表意见时，相关机构尚未确认成功攻击。

一个理解两者区别的简单方法，是想象有人在转动门把。漏洞利用尝试就像摇晃门把；入侵则意味着真的进了屋。即使发生数百万次尝试，也可能没有任何一起经确认的闯入，因此上述数字不一定互相矛盾。同时，入侵也不一定会立即被发现。某个时间点尚无已确认事件，固然令人鼓舞，但不能取代对受影响系统的检查和长期监控。

PHP 基金会的说明也让人开始关注漏洞的处理过程。基金会在 Wednesday 发布的博客文章中表示，2024 年的安全工作发现了 CVE-2026-109618 背后内存耗尽问题的初步迹象。团队考虑了“几种相互竞争的解决方案”，但难以从中做出选择，也担心选错修复方案所带来的后果。基金会表示，其资金使多位人员能够全职处理这一问题，同时承认整体响应仍花了太长时间。

基金会将这段延误称为“结构性失败”，并归因于安全团队的决策流程以及资源不足。过去安全团队必须达成共识；基金会表示，今后将改为多数决。这一点很重要，因为 PHP 支持了网络上相当大的一部分，而安全工作依赖少数由基金会资助的开发人员和部分志愿者协助。这起事件说明，广泛使用的基础设施安全，不仅取决于修复程序的技术质量，也可能受限于开发能力和治理流程。

有些网站下线，是因为当组织无法立即修补时，暂时让存在漏洞的服务不再对公众开放，可以作为保护措施。英国国家网络安全中心建议组织考虑“让系统下线，直到漏洞能够得到全面缓解”。据报道，Wednesday 无法访问的网站包括 Wikimedia 服务、Orange 在数十个国家的网站和应用程序、32 个英国政府服务、荷兰医院，以及德国联邦 IT 服务提供商 ITZBund。英国预算责任办公室和爱丁堡市议会网站已于 Thursday 恢复。根据 DutchNews 报道，荷兰匿名犯罪举报网站 Meld Misdaad Anoniem 在 Thursday morning 仍未恢复。这些例子表明，服务中断可能是有意采取的风险应对措施，并不代表每个下线的服务都已成功遭到攻击。

对于普通公众而言，目前的信息不足以支持仅因 PHP2Shell 就更改所有密码。根据本文所述，截至当时尚无已确认的数据泄露事件与这些漏洞有关。如果服务的服务器仍未修补，更改密码无法保护账户，也无法确认攻击者是否曾访问信息。更实用的基本做法仍然重要：每个账户使用不同的密码、启用双重身份验证，并留意公司的通知。如果服务报告数据泄露，请更改该账户的密码，以及任何重复使用相同密码的其他账户。

网站运营者还有额外责任。应用补丁可以关闭已知弱点，但无法证明攻击者是否曾在更新前入侵。安全公司 Tag1 建议检查是否存在组织未上传的 PHP 文件、新创建的计划任务，以及不熟悉的账户。对于曾运行存在漏洞版本、且可从互联网访问的服务器，该公司还建议轮换数据库密码和 API 密钥。这些检查是为了确认是否存在持续访问或凭据被盗的情况，而不是把软件更新当作系统已干净的证明。

加密货币用户面临的相关风险，来自访问的网站，而不一定是底层区块链网络。Binance 创始人 Changpeng Zhao 在 X 上提醒用户，接下来几天访问网站时要格外小心，因为部分管理员可能无法及时应用安全补丁。遭入侵的 Web 服务器可能显示仿真的合法网站。在加密货币场景中，假网页可能要求用户连接钱包并批准一笔会转走资金的交易。区块链本身可能仍正常运行，但用于与区块链交互的网站可能已经遭到入侵。

接下来几天，用户可以通过书签进入熟悉的网站，而不要点击意外链接；仔细核对网站地址；并在签署前检查每笔交易或钱包授权，以降低可避免的风险。对于已经拥有硬件钱包的用户，它或许能提供额外保护，但不能因此就安全地批准陌生或可疑的交易。来源报道称，截至当时，尚无加密货币交易所公开报告与 PHP2Shell 有关的数据泄露事件。这只是公开报告的情况，并不保证所有相关服务都未受影响。

整体风险仍集中在尚未修补的服务器。安全公司 Mallory 统计，约有 884,000 个可从互联网访问的主机，仍在运行没有官方修复程序的 PHP 版本。这一数字凸显旧系统仍持续存在，以及全面完成修补有多困难。Amazon 提醒防御者，不要假设公开披露日就是漏洞利用活动最早开始的日期。实际上，至少从 October 17 起运行过存在漏洞版本的组织，应调查这些系统，而不只是安装更新后就不再过问。

总体而言，本文并未指出浏览网络绝对不安全，也不意味着所有网站或个人设备都已遭到入侵。更恰当的理解是，这是一场仍在进行中的安全响应：受支持的版本已有修复程序，攻击者已大规模尝试利用漏洞，而部分组织尚未完成补救。个人用户应保持警惕，但不要做出缺乏依据的推测；服务器运营者则应优先处理更新、调查，以及在适当情况下轮换凭据。

重点摘要表

后续……

接下来的进展取决于各组织更新暴露在网络上的系统有多快，以及调查是否发现修补前遭到访问的证据。网站运营者应将修复程序的发布视为补救工作的起点，而不是终点：安装适当更新、重新启动 PHP、检查可能受影响的服务器，并在发现可疑迹象时遵循事件响应流程。用户仍可保持日常谨慎继续浏览，尤其是在访问处理敏感信息或加密货币交易的服务时。

这起事件也带出了一个更长远的问题：如何维护关键的开源软件。PHP 基金会的说明凸显，充足的安全资金、明确的决策方式，以及开发人员发现警示迹象时能够及时升级处理，都十分重要。由于旧版 PHP 不再获得官方发布，许多可从互联网访问的主机仍在使用这些版本，各组织需要制定升级旧系统的计划，而不是无限期依赖临时措施。修复程序的存在，并不意味着互联网就“再次安全”；只有随着修复程序逐步安装、系统完成检查，并让维护关键软件的人员获得足够资源和有效流程，风险才会逐渐降低。