「未确认受害」也不能安心——由于PHP漏洞导致网站停运，现在发生了什么

一直使用的网站突然无法打开。然而，如果原因不是因为网络攻击的破坏，而是为了防止攻击而进行的暂时停运，你会如何看待呢？

支持网站和网络应用程序的编程语言PHP被发现存在严重漏洞，德国的行政机构等因此采取了预防性的网站停运措施。

根据BUSINESS-PANORAMA于10月22日刊登的AFP文章，德国联邦信息安全局（BSI）解释说，尚未确认有利用该漏洞的案例。然而，并未排除攻击成功的可能性。

阅读这则新闻时重要的是，“未确认受害”与“已确认安全”并不相同这一点。

BSI的声明不是“结束宣言”

根据原文，BSI于10月21日下午对PHP漏洞发出警告，并通知当天16时计划进行安全更新。

警惕的是，更新内容公开后可能会导致攻击扩散。如果通过修正明确了问题所在，攻击者可能会分析该信息并针对未修复的系统。文章还传达了对AI分析容易性的担忧。

次日22日，BSI解释说，大部分被预防性停运的联邦行政机构网站已恢复。关于没有报告系统被侵害的情况，BSI认为许多运营者可能已按照建议完成了更新。

不过，这只是基于已掌握的信息进行的评估，并未对所有网站进行调查并保证没有入侵。

网站的恢复对用户来说是个好消息，但仅以此为由判断问题已全部解决为时尚早。

问题在于网站的“基础”

此次，PHP方面修复的是被称为“PHP2Shell”的两个严重漏洞。识别编号为CVE-2026-109618和CVE-2026-109619。CVSS v4.0的严重度评分均为9.2，被归类为“Critical”。

PHP Foundation于10月21日宣布，修复了一个允许未经认证的攻击者在运行PHP的服务器上执行代码的问题。

对于普通用户来说，PHP通常是一个不被注意的存在。它不是屏幕设计或文章本身，而是在后台负责处理。

因此，在考虑此次应对措施时，仅关注网站的外观或管理界面是不够的。需要确认应用程序运行基础的修正情况。

PHP Foundation公布的修正版为PHP 8.2.35、8.3.36、8.4.27、8.5.12。运营者需要确认包括提供其环境的服务商在内的修正应用情况。

不要混淆“攻击尝试”和“入侵成功”

除了关于BSI的原文，还需要注意AWS的观测报告。

AWS宣布，通过用于观测攻击的机制“MadPot”，确认了早在10月17日就有利用PHP2Shell的尝试。这是在漏洞详细信息公开之前的时间点。

另一方面，AWS表示不清楚观测到的尝试是否在实际系统中成功。

也就是说，关于BSI的“未确认利用案例”的报道和AWS的“观测到攻击尝试”的报告，目标和确认内容不同。不能仅凭一方就得出“没有攻击”或“大规模入侵损害已确定”的结论。

无论是作为用户还是运营者，都需要分别阅读漏洞的存在、攻击的观测、入侵的成功、信息泄露的确认。

在社交媒体上，也有对迅速修正的评价

在社交媒体和在线社区中，不仅有危机感，还有对报道的看法。

在Reddit的PHP社区中发布的“Has PHP2Shell borne fruit?”中，可以看到对恐慌性文章和对PHP的批评的讨论，以及对修正和主要Linux发行版迅速应对的评价。

这是一种希望不仅看到漏洞的严重性，还看到开发者和分发者应对的看法。然而，发布者对受害情况的评价并不直接表明全球的安全性。

另一方面，在关于邮件别名服务addy.io的Reddit帖子中，分享了作为对PHP2Shell的应对而暂时停运网络系统的信息。帖子中解释说邮件配送将继续，并在之后发布了应用修正后的恢复通知。

不只是用一句“服务无法使用”来结束，而是传达哪里停止了，什么可以使用，何时恢复。这样的信息共享对于减少用户的不安是有帮助的。

需要注意的是，这里介绍的是确认到的个别帖子，并不代表社交媒体整体的多数意见或民意调查。

对于停止网站的决定，也需要说明

预防性停运会给用户带来不便。如果出现无法查询、手续无法进行、商品无法购买等影响，运营方也会面临负担。

即便如此，在修正完成之前限制外部访问，意味着减少暴露于攻击的风险。CERT-EU也建议，如果无法立即修正，应考虑将公开的应用程序与公共网络隔离。

因此，仅凭是否停止来判断运营的好坏是困难的。

更需要问的是，是否说明了停止的理由，是否明确了受影响的功能，下一步的通知在哪里可以确认。

没有任何说明就消失的网站，与传达了为保护用户而采取的措施的网站，即使同样停止，接受的方式也会不同。

对于日本的运营者来说，这并不是“国外的新闻”

PHP的问题并不仅仅与德语网站有关。如果使用相同的技术环境，日本的企业也需要进行确认。

在此情况下，首要任务可能不是专业的设置更改，而是明确谁在管理自己的网站。

是制作公司负责，还是租用服务器公司更新基础设施，或者是自己公司的负责人必须应对。

需要确认的要点可以整理如下。

• 在网站的运行环境中，是否使用了PHP。
• 是否已应用此次漏洞的修正。
• 是否已确定更新的负责人和确认完成的方法。
• 如果无法立即修正，谁来决定限制公开。

“委托方应该已经应对了”和“确认了已应对的联系”之间有很大的差别。

此外，CERT-EU指出，对于PHP 8.1及以前已结束支持的系列，PHP项目不再提供更新。如果继续使用旧环境，需要确认该环境的提供者是否有修正以及是否需要迁移。

即使有防御措施，也不一定能代替更新

有时会想当然地认为，因为引入了防御机制就没问题。

然而，AWS明确表示，对于此次问题，WAF的对策只是减少暴露于风险的辅助措施，并不能代替PHP的更新。

重要的是，使用某种防御产品这一事实，而不是该对策在多大程度上覆盖了此次问题。

原文还介绍了BSI呼吁普通用户不要将路由器设置为可从外部访问，并注意下载和提供机密信息。

这并不意味着所有用户的终端或路由器都会直接受到此次漏洞的影响。运营方的应对和用户日常的注意需要分别对待。

“什么都没发生”背后有工作在支撑

在大警告之后，如果没有传出明显的受害情况，可能会有人觉得“是不是小题大做了”。

然而，未见受害的原因可能是由于早期更新或预防性停运发挥了作用，也可能是尚未掌握。仅凭现有信息无法断定是哪种情况。

此次PHP漏洞显示，持续公开网站并不是运营的唯一责任。在必要时停止、修正、确认状态并向用户说明。这一系列应对也是支持服务的工作。

“未确认受害”的消息并不是停止应对的理由。只有在确认了自己的环境状况后，阅读新闻才能真正转化为实际的准备。

出处

1. BUSINESS-PANORAMA／AFP（2026年10月22日）
   BSI未确认利用案例、未排除入侵可能性、行政网站的恢复情况、对普通用户的注意呼吁的依据。
   https://business-panorama.de/news.php?newsid=6715602

2. PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」
   10月21日修正版发布及漏洞带来的危险的官方说明。
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/thephp.foundation

3. CERT-EU「Critical Vulnerabilities in PHP」
   CVE编号、严重度、影响环境、支持结束系列、修正和隔离的官方建议。
   https://www.cert.europa.eu/publications/security-advisories/2026-018Critical Vulnerabilities in PHP

4. AWS Security Blog：MadPotによるPHP2Shell観測報告
   公开前的攻击尝试和不明实际环境成功与否的说明。区分“攻击观测”和“受害确认”的依据。
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/aws.amazon.com

5. AWS Security Blog：PHP2Shellに対するWAFの緩和策
   WAF的定位和需要PHP更新的官方资料说明。
   https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/aws.amazon.com

6. Reddit・r/PHP「Has PHP2Shell borne fruit?」
   对报道的疑问和对迅速修正的个别反应。帖子中的受害评价未作为确认事实采纳。
   https://www.reddit.com/r/PHP/comments/1xchgrv/has_php2shell_borne_fruit/reddit.com

7. Reddit・r/addy_io「Service Update 🚨PHP2Shell vulnerability」
   关于网络系统的预防停运、邮件配送的持续、修正后的恢复的信息共享例子。
   https://www.reddit.com/r/addy_io/comments/1xbkaeb/service_update_php2shell_vulnerability/