PHP2Shell为何拉响紧急警报——生成式AI揭示的危险与政府及企业的应对

关于本文
本文采用结合生成式AI的自动化流程生成。基于PHP开发方、PHP Foundation、OpenAI、安全研究企业以及国内外官方机构的发布内容，梳理了危害性、发现过程、风险提示与应对措施。主要原始资料及PHP官方的补充注意事项已于2026年10月25日重新核实。文中未登载特定网站或个人服务器的配置及运行日志。

验证状态：🧪 已确认主要原始资料、命令语法及测试数据的状态显示。实际Ubuntu环境下的更新操作与WordPress上的图表显示尚未经验证。

2026年10月21日，编程语言PHP的开发团队发布了针对两个重大漏洞的修复版本，该问题被称为“PHP2Shell”。其CVSS v4.0严重程度评分为9.2。在满足特定条件时，攻击者无需登录即可在Web服务器上执行恶意代码。由于该漏洞不仅波及其它诸如WordPress等独立的Web应用程序，更直接关乎作为其运行基础的PHP本身，因此影响范围极广。出处为PHP官方安全公告与PHP Foundation的说明。

此次新闻还有另一个重大特征。那就是利用生成式AI的安全研究，具体展示了以往已知问题可能导致的严重攻击后果。本文将按从发现到应对的发展脉络，探讨为何该漏洞的修复如此紧迫，并惊动了政府和企业。

什么是PHP——支撑全球网络三十余年的底层技术

PHP是一种在Web服务器端运行的开源编程语言。例如，在购物网站上挑选商品时，PHP可以从数据库中获取价格和库存、注册订单信息，并将结果返回给用户。会员登录、咨询表单以及博客文章的显示等也是其典型应用。它在浏览器显示画面的幕后，承担着提取信息和处理数据的职责。PHP官方的入门资料也对这种服务器端的应用场景进行了说明。

其起源是1994年。开发者勒斯穆斯·勒多夫（Rasmus Lerdorf）当时为了查看自己网页的访问记录而制作了一个小型工具。它被称为“Personal Home Page Tools”，并在1995年6月公开了源代码。其他开发者也参与了改进，经过大约30年的时间，它成长为一种全球使用的语言。这段历史记录在PHP官方手册中。

以PHP为基础的系统包括WordPress（用于博客和企业网站管理）、Drupal和Joomla（用于大型网站等的内容管理）、MediaWiki（用于维基类信息网站）等。即使在使用这些服务时，日常浏览者也很少会意识到PHP的存在。

它对世界的影响究竟有多大

负责调查Web技术采用情况的W3Techs根据参考页面显示的日期即2026年10月24日，在能够识别出服务器端编程语言的网站中，有69.3%使用了PHP。这是W3Techs使用统计中显示的数据。由于在世界范围内广泛使用的通用技术中发现了缺陷，这次新闻并不只限于日本的问题。

不过，69.3%并不意味着“涵盖全球所有网站”，也不意味着“那69.3%的网站仍然存在漏洞”。其分母是能够识别出语言的网站，并且各个网站的PHP版本、修复状态、使用方法以及攻击成立的条件各不相同。我们需要将普及率和危险网站的比例分开来看。

这会导致什么样的危害

PHP是用于在服务器上运行网页和API等的机制，并不是用于改变网站外观的组件。如果PHP内部的缺陷遭到滥用，即使没有修改网站程序也可能会产生危险。

研究团队通过满足特定条件的配置，对以下影响进行了验证和说明。

• 篡改网站：通过执行非法代码，页面内容或文件可能会被修改。

• 窃取机密信息：服务器内处理内存中包含的密码、令牌、API密钥等可能会被读取。

• 服务中断：PHP进程可能会异常终止，或者Web服务可能无法正常响应。

• 危害扩大：根据服务器的权限和网络上的连接关系，可能会对其他资产造成影响。

这并不意味着所有PHP网站都一定会遭受同样的攻击。攻击成立的条件以及之后可以执行的操作会因PHP的运行方式、设置、权限和应用程序而异。Wiz的研究结果虽然报告称在分别使用WordPress、Drupal和Joomla的验证环境中成功实施了攻击，但切勿将此事实与各个运营网站遭到入侵混为一谈。

原因并非Web应用程序的故障，而是PHP的内部处理

这两个漏洞与PHP在处理错误或内存不足时的内部状态问题有关。

详情请参阅PHP Foundation和Ubuntu的安全公告通常，“远程代码执行（RCE）”是指攻击者从远程位置诱导目标计算机执行非预期的程序。但这并不意味着PHP漏洞就一定等同于操作系统命令注入这一攻击手法。

生成式AI真的参与漏洞发现了么

生成式AI确实被派上了用场。然而，“AI独立发现并完成了修复”这种说法并不准确。

根据 PHP Foundation 的说法，在 2024 年由 Quarkslab 在 OSTIF 的协调下实施的外部审计中指出的另一个问题在 PHP 开发者修复的过程中，发现了本次内存不足相关问题的迹象。这并不意味着 Quarkslab 在 2024 年时直接发现了这起事件中的两处问题。然而，当时并未弄清攻击成立的具体途径，且由于对兼容性和性能的影响，修复方针的决定陷入了困境。

在 2026 年，推进了多项利用生成式 AI 作为辅助工具的安全研究。

• 7月30日：安全公司 Calif 结合 OpenAI 的“Patch the Planet”项目，开始对 PHP 进行审计。

• 8月11日：Calif 的研究人员报告了一条导致此前问题的严重远程代码执行途径。

• 8月19日至24日：Wiz 通过利用 AI 的研究验证了漏洞及被攻击的可能性，并向 PHP 安全团队进行了报告。

• 10月21日：PHP 开发团队发布了修复版本。

PHP Foundation 解释称，OpenAI 也独立报告了相同的根本原因，并于 9 月 18 日报告了附加的攻击途径。该文档的正文中并未明确记载 OpenAI 首次独立报告的具体日期。

关于利用 AI 开展的调查以及各组织的报告历程，请参考Wiz 的技术报告以及PHP Foundation 的背景说明。

AI辅助验证了过去需要大量分析和反复试验才能完成的可攻击性验证，其具体指出的严重性成为了推进应对措施的重要契机。另一方面，修复的设计、兼容性的判断、代码审查以及分发则是由人类开发者和安全团队来承担的。PHP Foundation表示，在AI生成报告不断增加的今天，最终的判断和补丁编写工作仍由人类来完成。

这一事件表明，虽然AI加快了防御方的研究速度，但也可能使攻击者更容易分析漏洞。长期存在的缺陷有时会因为AI的出现，才首次作为实用的攻击途径显现出来。

新闻中出现的人物和组织都是谁？

这次的新闻并不是由某个研究员单独发现并独自修复的故事。发现问题的人、修复问题的人、广泛分发的人、传达注意事项的人各自承担了不同的角色。

PHP开发团队（The PHP Group）是负责开发和维护PHP语言本身的全球开发者群体。他们承担了实现漏洞修复并发布修复版本核心角色。在资金和人员方面支持这一活动的PHP Foundation是一个由企业和个人参与、旨在支持PHP长期发展的组织。此次他们也为确保修复工作的人才投入以及相关人员的协调提供了支持。参见PHP Foundation的目的与经过说明

Quarkslab（夸克实验室）是一家法国安全研究公司，于2024年对PHP源代码进行了审计。OSTIF是一个协调开源安全审计的非营利组织。审计资金由德国的主权技术基金（Sovereign Tech Agency）提供了资助。该审计报告了另一个问题，其修复过程促成了后续迹象的发现。PHP基金会的审计结果与OSTIF的审计报告中记录了来龙去脉。

Calif是一家总部位于美国的安全性研究公司，也是一个专注于验证软件是否存在攻击路径的专家团队。OpenAI是一家开发生成式人工智能的公司，通过“Patch the Planet”项目为研究人员提供了先进的AI和技术支持。Wiz是一家调查云和AI使用环境风险的安全公司，他们从另一个途径研究了该问题并向PHP团队进行了报告。也就是说，Calif和Wiz主要负责发现与验证，而OpenAI则扮演了支持AI以及协助调查和协调的角色。各组织的说明请参考Calif、、PHP基金会的背景说明、以及Wiz。

Canonical（Canonical）是一家负责开发和提供Linux发行版Ubuntu的公司。它将PHP开发团队准备的修复程序整合进Ubuntu现有的PHP软件包中，以便Ubuntu用户进行更新。这属于独立于安全研究人员的负责分发与更新的立场。Ubuntu官方安全公告中给出了修复后的版本号。

在日本，IPA（信息处理推进机构）作为负责信息安全对策和IT人才培养的独立行政法人，呼吁各方做好更新准备。JPCERT/CC是一个收集网络攻击与事故信息、并与国内外组织进行联络协调以防止危害扩大的中立协调机构。JISA（信息服务产业协会）是面向IT服务企业等机构的行业组织，同时也承担着将行政部门的警示信息传达给会员企业的角色。有关各组织的宗旨，可以通过IPA、JPCERT/CC、JISA进行确认。

从漏洞发现到紧急更新的流程

发现者和修复负责人并非同一个人。2024年迹象的把握，发生在PHP开发人员修复Quarkslab在审计中报告的另一个问题期间。我们发现的是内存不足问题的迹象，并不意味着当时两个CVE都已被识别。PHP Foundation的说明与原始审计报告参见。

flowchart TB
    A["2024年：PHP開発者が<br/>メモリ不足問題の兆候を把握"]
    B["2026年：研究者が生成AIを活用し<br/>攻撃可能性を具体化"]
    C["Calif・OpenAI・Wizなどが<br/>PHP側へ報告・検証協力"]
    D["PHPのセキュリティチームが<br/>修正パッチを実装・テスト"]
    E["PHP開発元が修正版を公開"]
    F["OS配布元がパッケージを準備・配布"]
    G["IPA・JPCERT/CCなどが注意喚起"]
    H["各組織が更新・侵害兆候を確認"]
    A --> B --> C --> D --> E
    E --> F --> H
    E --> G --> H

图1中的人物与出处

• ※1 PHP开发团队／PHP Foundation：PHP的维护与修复／开发资金和人才的支持。组织与修复历程。

• ※2 Calif・OpenAI・Wiz：利用AI调查受攻击的可能性、向PHP报告并合作。PHP Foundation／Wiz。

• ※3 操作系统分发方：使各操作系统和产品能够更新PHP的修复。Ubuntu的分发示例。

• ※4 IPA・JPCERT/CC：面向日本国内的准备、安全提醒及入侵调查指南。IPA／JPCERT/CC。

漏洞发现、验证与修复是不同的流程。人工智能辅助验证了攻击路径，而PHP开发者则实现了修复。此外，这并不意味着相关各方在排队等待，修复、分发准备以及安全提醒等工作也是并行推进的。

为什么行政机关和行业协会也会发出安全警示

此次应对的不仅仅是一家企业的故障。正因为这是一个广泛使用的通用技术问题，沟通与对策才从PHP开发团队扩散到了操作系统分发商、云托管服务商、专业机构、行政部门以及行业协会。

• 10月20日（世界协调时）：PHP开发团队发布了重大安全更新预告。据PHP Foundation称，在发布前CVE编号等信息发生泄露，这也是计划提前的原因之一。

• 10月21日（日本时间）：IPA呼吁做好前期准备，要求排查使用PHP的系统并为快速更新做好准备。

• 10月21日23点左右（日本时间）：修复版本的提供与详细信息的公开逐步推进。

• 10月22日：JPCERT/CC呼吁迅速进行更新并调查是否存在被入侵的情况。国内的行业协会也传达了经济产业省的周知请求以及内阁官房国家网络统括室的安全提醒。

这并不意味着日本政府向所有企业发布了统一的法定更新命令。鉴于其严重的危害性和广泛的使用范围，其流程是将信息公之于众以便各个组织能够做出适当的判断和应对。依据是IPA的前期指南、JPCERT/CC的安全提醒、信息服务产业协会的指南中有所说明。

此外，“具有重大危险性”、“攻击已被证实”以及“已确认实际受害”是不同的概念。日本信息处理推进机构（IPA）在10月22日更新的事前准备指南中明确指出，该机构并未确认有将其作为自身机构进行利用的攻击。加拿大网络安全中心在10月23日更新的通知中表示，虽然掌握了概念验证（PoC）公开的报告，但该机构当时并未查明实际的漏洞利用。由于发布时间、各机构的观测范围以及报告内容各不相同，切勿将这些混为一谈，视为全球范围内确定的受害情况。

世界各地的推进防御与公告

由于PHP跨国界使用，因此应对措施也是国际化的。例如，提供保护网络通信服务的Cloudflare（知名云厂商）解释称，在漏洞信息公开之前，他们就已经准备并分发了网络应用防火墙（WAF）的应对规则。WAF是一种拦截可疑网络通信的机制，但它并不能代替PHP自身的更新。Cloudflare的应对报告参见此处。

另外，加拿大网络安全中心也在10月21日发出了警告。尽管必须将各国警戒信息与个别企业的影响调查区分开来，但从中可以看出此次问题涉及全球软件基础设施。

国内扩散的信息与应对——按时间顺序追踪

海外 PHP 开发团队发布的公开预告，并未通过单一的指挥监督系统以串行方式传达给日本的行政机关、专业机构、行业团体及运营商。接收到官方信息的各组织，根据自身的职责和权限，将前期准备、公开知会、暂停服务以及应用补丁等工作并行地推进。对于日本读者而言，比起“谁是谁的上司”，“哪个组织传达了什么信息、哪个现场在何时采取了行动”更为重要。

日本国内的网络安全体制究竟是怎样的？

国家网络安全统筹室（NCO，内阁官房）负责日本网络安全政策的规划与综合协调，以及向行政机关提供建议和信息等。另一方面，IPA（信息处理推进机构）发布对企业及广大系统用户同样有用的漏洞及对策信息，JPCERT/CC则负责收集技术信息、进行国内外协调以及支持应对安全事件。经济产业省负责与主管领域的相关组织进行联络，JISA（日本信息服务产业协会）等行业团体将信息传达给会员企业。这不是一份显示上下级关系的名单，而是承担不同职责的组织之间的分工。关于此次的知会请求，请参考JISA发布的资料。

JISA接受了经济产业省提出的向会员企业进行知会的请求明确指出，内阁官房国家网络统括室的提醒警示资料也进行了登载。然而，从这些资料中无法确认诸如“IPA向内阁官房上报”、“内阁官房向新闻媒体下达统一指示”、“向所有企业下达了法律层面的更新命令”等具体的联络与指示途径。新闻媒体除了政府之外，也会对PHP官方、研究企业以及各运营商的发布内容进行独立采访。

图2：从海外公开到国内知悉与现场应对（原则上为日本时间，仅预告为UTC）

flowchart TB
    subgraph T20["10月20日（世界協定時）｜海外の起点"]
      P["PHP開発チーム<br/>重大なセキュリティ更新を事前予告"]
    end
    subgraph T21["10月21日（日本時間）｜公開前の予防措置"]
      IPA["IPA：更新に備えた準備を呼びかけ"]
      SCI["東京科学大学：16時ごろ<br/>サーバーの暫定的な防護設定"]
      XS_STOP["エックスサーバー：16時から<br/>サービスサイト・管理画面等を一時停止"]
      RAK_STOP["ラッコ：19時ごろから<br/>一部サービスを予防的に停止"]
      PATCH["PHP開発チーム：23時ごろ<br/>修正版を公開"]
    end
    subgraph T2122["10月21日以降｜政府・業界の並行した周知"]
      NCO["内閣官房 NCO<br/>注意喚起文書を発出"]
      METI["経済産業省<br/>JISAへ会員企業向け周知を依頼"]
      JISA["JISA：注意喚起文書を掲載<br/>会員企業へ対策を案内"]
    end
    subgraph T22["10月22日（日本時間）｜パッチ適用と再開"]
      JC["JPCERT/CC：更新と<br/>侵害有無の調査を呼びかけ"]
      XS_FIX["エックスサーバー：6時45分<br/>PHP 8.2～8.5の修正適用完了"]
      RAK_FIX["ラッコ：8時43分<br/>全サービスを再開"]
      LOLI["ロリポップ！：13時ごろ<br/>サイト表示を再開"]
      MOF["財務省：一部コンテンツを<br/>安全確認後、順次再開"]
      PRESS["新聞・専門メディア<br/>対応状況を報道"]
    end
    subgraph T23["10月23日（日本時間）｜メンテナンス完了の公表"]
      SAKURA["さくらインターネット：17時30分追記<br/>緊急メンテナンス全件終了を公表"]
    end
    P --> IPA
    P --> PATCH
    XS_STOP -.-> XS_FIX
    RAK_STOP -.-> RAK_FIX
    METI -->|"周知依頼"| JISA
    NCO -.->|"注意喚起文書をJISAが掲載"| JISA
    PATCH --> JC
    PATCH --> XS_FIX
    PATCH --> RAK_FIX
    PATCH --> LOLI
    PATCH --> MOF
    PATCH --> SAKURA
    PATCH --> PRESS

图2的阅读方法与出处注释

• 时间轴：从上到下，按照发布、准备、修复应用推进的顺序排列。日期和时间除特别说明外均为日本时间。只有10月20日的预告采用世界协调时（UTC）标注。PHP的预告／IPA的事前指南。

• 国内的周知：NCO、经济产业省和JISA承担着不同的角色，没有资料可以证实信息是按单一线路传达的。经济产业省向JISA的周知请求与NCO文件的JISA登载可以从公开文件中得到确认。JISA的指南。

• 公开前的应对：东京科学大学公布了临时对策，Xserver和Lakko公布了对部分服务及管理界面等的预防性暂停。东京科学大学／Xserver／Rackt。

• 修正版公表後：IT服务运营商应用修补程序并恢复服务的报告与JPCERT/CC的预警进行了区分。JPCERT/CC／Lolipop!／樱花互联网／财务省。

• 箭头含义：概念性地表示公开信息与应对时间的关系。箭头并不代表各组织之间存在个别指示或联络的证据。虚线表示同一运营商从停止到恢复的过程，或资料的登载关系。INTERNET Watch的报道也请一并参考。

实际在何处执行了停止或更新——公布恢复的实际案例

预防措施与实际应用修复并恢复服务是两码事。此处将金融机构及一般企业的停止信息从列表中排除，仅聚焦于IT服务与托管运营商的官方应对完成及恢复报告，以及大学和行政机关自行公布的案例。以下内容为截至2026年10月25日的公布内容，并不意味着所列组织或用户的全系统存在漏洞或遭到入侵。

此处所谓的“恢复”与“处理完成”是指各官方公告所涵盖的服务和功能范围限。即使经营者处理了所有版本，也不意味着长期使用停止支持的 PHP 是安全的。此外，对于医疗机构等个别组织，不得揣测缺乏官方证实的受害情况或恢复情况。

从此次事件中可以看出：海外开发商的更新预告 -> 国内的预防措施 -> 应用修复补丁 -> 公布恢复使用这一过程在短时间内推进。各公司的判断是同步进行的，并非所有组织都在同一时间、以相同顺序做出应对。

企业和网站管理员应该确认什么？

首先，掌握网站、业务系统以及外部委托服务等是否使用了 PHP。PHP 不仅用于应用程序，有时也用于设备和产品内部，用户可能无法直接确认版本。

其次，确认所使用产品或操作系统的提供商所发布的更新。PHP 官方于 2026 年 10 月 21 日发布了8.2.35、8.3.36、8.4.27、8.5.12。不过，Linux 发行版和产品供应商可能会使用不同的软件包编号来提供修复。

第三，确认更新后的服务运行情况。不仅要检查页面显示，还要检查登录、表单、API、后台处理等主要功能。同时还要调查更新前后的日志以及可疑的通信和进程。应用补丁并不能证明过去未曾遭到入侵。 入侵调查的要点已在JPCERT/CC 的安全提示中进行了总结。

请同时确认 10 月 23 日的附加注意事项

PHP 官方于 10 月 23 日发布了关于会话上传进度功能的附加注意事项。当应用程序将设置中的 session.serialize_handler 设为 php_binary 或 php_serialize 并在执行中途切换为 php 后，session_start()，且同时启用了上传进度功能。

PHP官方建议将此作为下一次常规Bug修复版本发布前的session.upload_progress.enabled=0。如果在10月21日的对策中已经禁用了该功能，请保持该设置不变。对于在执行过程中不改变序列化方式的应用程序，没有必要因为这个额外的注意事项而禁用该功能。修改设置时，请确认其对上传进度显示等功能的影响，并将其应用到Web端实际使用的PHP设置中。

这些附加信息预计将在下一次版本中作为 CVE-2026-115560 详细报告。切勿仅因为完成了10月21日的两项更新，就认为无需再确认相关的附加指南。依据：PHP官方：关于10月23日Session upload progress的说明。

在Ubuntu中检查已修复软件包的示例

更新方法因操作系统、PHP分发源和安装方式而异。以下以Linux系操作系统中广泛使用的发行版之一 Ubuntu 为例。这只是一个用于说明的通用示例，并不意味着某个特定网站正在运行Ubuntu。

Canonical针对Ubuntu 24.04 LTS提供的PHP 8.3修复后软件包版本为8.3.6-0ubuntu0.24.04.13。Ubuntu官方通知USN-8948-1中已明确记载。

图3：从PHP本体修复到Ubuntu更新的过程

Ubuntu的开发者无需从零开始重新发现漏洞。 Canonical基于PHP开发团队的修复方案进行调整，使其能够在Ubuntu的现有版本上运行并准备好软件包。这就是反向移植（Backport）的概念。

flowchart TB
    A["PHP開発チーム<br/>PHP本体の修正を作成・検証"]
    B["Ubuntuの提供元 Canonical<br/>修正を既存パッケージへ取り込む"]
    C["Ubuntu向けにビルド・検証<br/>修正版パッケージを配布"]
    D["システム管理者<br/>APTで修正版を取得・適用"]
    E["PHP-FPM等の稼働状態を確認<br/>必要なサービス再起動を確認"]
    F["パッケージ版数・サイト機能・<br/>エラーログを点検"]
    A --> B --> C --> D --> E --> F

图3中的相关人员与出处

• ※1 PHP开发团队：设计修复方案并将其反映到PHP官方的新版本中。PHP Foundation的修复说明。

• ※2 Canonical／Ubuntu：执行将修复内容引入 Ubuntu 现有版本的“向后移植（Backport）”，并分发经过验证的更新软件包。Ubuntu 官方通知。

• ※3 各网站或企业的管理员：应用适合自己环境的软件包，并检查其运行状态以及是否存在异常。JPCERT/CC 的应对指南。

例如，在 Ubuntu 24.04 LTS 的标准 PHP 8.3 中，即使原始 PHP 版本保持 8.3.6 不变，只要完整的软件包版本号为8.3.6-0ubuntu0.24.04.13，即包含此次修复。实际运行的是哪个 PHP 版本需另行确认。依据：Ubuntu USN-8948-1。

例如，在使用 PHP 8.3 的 CLI、FPM 以及通用软件包的典型 Ubuntu 环境中，可以通过以下方式确认已安装的版本。

php -v
dpkg-query -W -f='${db:Status-Status}\t${binary:Package}\t${Version}\n' \
  php8.3-cli php8.3-fpm php8.3-common
apt-cache policy php8.3-cli php8.3-fpm php8.3-common

此示例是用于查询版本号的检查命令，不会执行 PHP 的更新操作。dpkg-query 用于显示“状态・软件包名称・版本号”。请将状态为 installed 的行确认为已安装的软件包。config-files 即使诸如此类的行显示了版本号，也不代表该软件包当前已安装。dpkg-query 官方手册。

php -v 用于确认所调用的 CLI 的 PHP。它不一定与网站所使用的 PHP-FPM 或 Apache 模块具有相同的实体与版本。apt-cache policy 用于显示 APT 的本地信息，因此即使显示了更新候选，也不能证明已经应用；如果缓存较旧，候选信息也会是旧的。PHP CLI的官方说明以及apt-cache的官方手册，分别确认已安装的版本、更新候选以及Web使用的PHP。

此外，示例中的三个软件包并非安装在所有Ubuntu环境中。针对未安装软件包显示的出错信息，并不直接意味着更新失败。请先确认PHP的运行方式（FPM、Apache模块、CLI等）以及正在使用的软件包，然后再进行检查。

最初的php -v即使显示为“8.3.6”，也不能单凭这一点判断未修复。因为在Ubuntu等系统中，会进行反向移植（Backport），在保持原有版本的同时引入安全修复。因此需要确认的是发行版的完整软件包版本，以及该厂商的官方通知。

从实际查询结果中可以读出的内容

以下是从Ubuntu 24.04 LTS的确认结果中提取并整理出文章判断所需部分的示例。不发布主机名、用户名、CPU架构、APT分发源、构建日期等可识别具体环境的信息。这并非软件包更新或配置更改后的结果，而是只读命令的输出。

php -v: PHP 8.3.6 (cli)

状態         パッケージ        インストール済み版数
installed    php8.3-cli       8.3.6-0ubuntu0.24.04.13
installed    php8.3-common    8.3.6-0ubuntu0.24.04.13
installed    php8.3-fpm       8.3.6-0ubuntu0.24.04.13

APTの候補版数（上記3パッケージ）:
8.3.6-0ubuntu0.24.04.13

在该示例中，CLI、FPM和通用软件包这3项已安装，且与Ubuntu官方通知USN-8948-1中的PHP 8.3修复版一致。显示中的 PHP 8.3.6仅凭这一点就断定“未修复”是错误的。另一方面，APT的“候选”是基于已获取的软件源信息，并不总是能保证达到未来的最新状态。Canonical的已修复版本列表进行核对。

这里确认的是截至2026年10月21日发布的对应CVE-2026-109618／CVE-2026-109619的软件包版本为止。仅凭这三个命令，无法判断Web服务器是否实际在使用该软件包的PHP-FPM、更新后的进程是否已重启，或是是否需要处理10月23日的附加注意事项。运行状态和对服务的影响需另行确认。

如果进行更新，请务必提前确认备份、依赖关系以及服务重启的影响。由于容器、自定义构建、PPA、托管服务等的更新步骤各不相同，请勿一概而论地执行相同的命令。同时，请区分PHP本身的修复与Web应用或CMS的更新。

用于重复进行相同确认的只读示例将依次检查指定的软件包，并区分未安装、查询失败以及缺少候选信息的情况。该示例不显示APT软件源URL或原始诊断文本，也不会执行软件包更新或服务操作。退出代码0仅表示已成功获取信息，并不代表漏洞修复已完成。

简易版的PHP软件包状态检查示例会将执行结果直接显示在终端中。不会自动创建日志文件。代码被封装在简短的函数中，且不使用顶层的 exit，因此即使将全文粘贴到终端中也不会退出登录Shell。

使用方法很简单，只需在示例的保存路径下执行 bash check-php-package-status.sh 即可。屏幕上将显示软件包的状态、完整版本号以及APT候选版本号。执行后立即输入 echo $? 还可以检查退出代码。退出代码 0 仅表示成功获取信息，并不保证安全性。 仅在必要时，由用户复制并保存终端结果。不执行软件包更新、服务操作或外部传输。

此示例确认了 Bash 语法、模拟软件包数据、直接粘贴到终端以及错误处理。用户提供的执行结果显示，在实际的 Ubuntu 环境中，3 个软件包的版本号正常显示，且终端未关闭。但这并不能自动验证 PHP 的更新或网页端 PHP 的运行状态。

总结：尽管 AI 加快了漏洞发现的速度，但最终责任仍在人类与运维

PHP2Shell 所展示的是：广泛使用的软件基础中潜藏的缺陷，可能导致来自外部的恶意代码执行或信息泄露，而生成式 AI 则加速了对这种危险性的阐明。

在此次研究中，人类开发者于 2024 年察觉到的问题迹象，在 2026 年的 AI 辅助研究中被具体化为更深层次的攻击可能性。修复与公开由 PHP 开发团队主导，公共机构与企业也纷纷采取行动发布预警并准备更新。

随着 AI 发现能力的大幅提升，防守方更需要做到以下几点：掌握所使用的系统、应用可靠的修复方案，并在事后持续监控异常情况。这是最基本的运维要求。

参考与引用资料

以下是写作时确认的出处，并附带说明了各资料所证实的内容。

1. PHP 官方：2026 年 10 月 21 日关于重大漏洞的公告 — 涉及 CVE、严重程度及修复版本。

2. PHP Foundation：从发现到修复的历程（2026 年 10 月 21 日） — 2024 年的迹象、2026 年的报告以及人工修复过程。

3. Wiz：PHP2Shell 研究报告（2026 年 10 月 21 日） — AI 的应用、攻击可能性的验证及技术影响。

4. IPA：为 PHP 安全版本发布做好的前期准备（2026 年 10 月 21 日） — 日本国内的准备要求与是否确认遭到滥用的区分。

5. JPCERT/CC：关于 PHP 漏洞的安全性警示（2026 年 10 月 22 日） — 面向国内的防范对策及入侵调查要点。

6. 信息服务产业协会：经济产业省等发出的 PHP2Shell 警示 — 行政机构向行业团体的通知。

7. Ubuntu：USN-8948-1（2026年10月21日） — 发行版中已修复的软件包编号。

8. PHP 官方手册：入门 — PHP 的作用及服务器端机制。

9. PHP 官方手册：PHP 的历史 — 1994 年诞生，1995 年发布。

10. W3Techs：PHP 全球使用统计 — 参考页面上显示的 2026 年 10 月 24 日 69.3% 的普及率及其分母。

11. PHP 基金会：活动目的 — 旨在支持 PHP 开发者的组织的作用。

12. Calif：公司简介 — 安全研究公司的角色。

13. Wiz：公司简介 — 云安全研究公司的角色。

14. IPA：机构概述 — IPA 在国内的作用。

15. JPCERT/CC：组织概述 — 协调国内外事件响应。

16. JISA：协会概况 — 行业团体的宗旨。

17. Cloudflare：针对 PHP2Shell 的 WAF 防御措施 — 国际缓解措施的实际案例。

18. 加拿大政府：关于 PHP 严重漏洞的警告 — 10月21日首发通告与10月23日更新、漏洞利用确认情况、对其他漏洞的注意。

19. PHP Foundation：PHP 核心安全审计结果（2025年4月10日） — 与2024年开展审计的 Quarkslab 合作的 OSTIF、审计资金。

20. OSTIF：PHP 审计完成！（2025年4月10日） — 审计实施的背景、验证范围、Quarkslab 的工作。

21. 东京科学大学：WWW服务器代理服务临时应对措施（10月21日） — 10月21日的临时对策，以及22日应用修复并部分恢复的补充说明。

22. SAKURA internet：PHP 漏洞应对情况（10月22日、23日补充） — 目标 PHP 的修复、相关维护结束、公布范围。

23. Xserver：管理后台暂停、PHP 补丁应用及恢复情况 — 各 PHP 版本的应用时间和尚未完成的旧版本。

24. Lolipop!：PHP 漏洞应对与恢复完成报告（10月22日） — 网站显示与管理后台的恢复以及旧版本的修复。

25. Rakko：PHP2Shell 应对及全服务恢复报告（10月22日） — 停止开始、恢复时间、对 PHP 的补丁应用。

26. 财务省：恢复部分内容的公开（10月22日） — 在确认安全后恢复。

27. INTERNET Watch：针对 PHP 漏洞的国内应对措施（10月22日） — 媒体对国内情况的整理。

28. IPA：关于 PHP2Shell 漏洞应对措施的后续报道（10月22日） — 目标版本、修复版本、难以应对时的判断指南。

29. PHP 官方：关于 Session upload progress 的附加注意事项（10月23日） — 有限配置下的附加应对措施及下次发布前的说明。

30. Ubuntu 官方手册：dpkg-query — 获取并显示状态、软件包名称及版本号。

31. PHP 官方手册：CLI 选项 — php -v 显示的信息。

32. Ubuntu 官方手册：apt-cache — 基于本地缓存的确认及更新候选的处理方式。

GitHub 示例

• Daily-Code-Samples — PHP 软件包状态及版本确认

• 使用方法、前提条件、输入输出、注意事项

• 完整代码：check-php-package-status.sh

链接已固定至待验证的提交。在实际环境中应用之前，请确认内容以及分发机构的最新通知。