PHPの重大な脆弱性「PHP2Shell」で何が起きたのかを時系列で整理してみた

Posted at 2026-10-22

はじめに

2026年10月21日、PHPで重大な脆弱性が2件公表され、修正版が公開されました。
同じ日の午後から夜にかけて、国内では大手のWebサービスやゲーム、官公庁のサイトが相次いで止まり、首相がXで対応を呼びかけました。

修正版が公開されたのは日本時間の23時です。
それなのに、多くのサービスは修正版が出る前から止まっていました。
なぜでしょうか。

この記事では、PHPの公式発表と報道をもとに、何が起きたのかを時系列で整理し、この問いに答えます。

エンジニアでない方にも読めるよう、専門用語には説明を付けています
推測を含む箇所は「推測です」と明記しています
時刻は日本時間(JST)で書き、元の情報が協定世界時(UTC)の場合は換算しています
情報は2026年10月22日時点のものです

PHPとは

PHPは、Webサイトの裏側で動くプログラムを書くための言語です。
ブラウザでページを開くと、サーバー(Webサイトを置いているコンピューター)の上でPHPのプログラムが動き、ページの中身を組み立てて返します。

身近な例では、ブログやサイト作成に広く使われているWordPressがPHPで作られています。
報道では「世界のWebサイトの約7割で使われている」という数字も出ました。
ただし、この数字の出典と計測方法は今回確認できていません。

見つかった2つの脆弱性

脆弱性とは、プログラムの欠陥のうち、悪用されると安全が損なわれるものを指します。
今回見つかったのは次の2件です。

番号	原因	深刻度
CVE-2026-109618	メモリが足りなくなったときの後始末の誤り	CVSS v4.0で9.2
CVE-2026-109619	前のリクエストの情報が残ってしまう誤り	CVSS v4.0で9.2

CVEは脆弱性に付く世界共通の番号で、CVSSは深刻度を10点満点で表す指標です。
2件はまとめて「PHP2Shell」と呼ばれています。

何ができてしまうのか

どちらも、ログインしていない外部の人が、細工した通信を送るだけでサーバー上の好きなプログラムを動かせるおそれがあります。
これをリモートコード実行(RCE)と呼びます。
サーバーを乗っ取られると、サイトの書き換えや、保存されている個人情報の持ち出しにつながります。

仕組みを噛み砕くと、次のようになります。

1件目: PHPはリクエスト(「このページを見たい」という1回の依頼)ごとにメモリ(作業用の机のようなもの)を使います。メモリの上限に達した瞬間に処理が打ち切られると、作りかけのデータが残り、あとで正しいデータとして扱われてしまうことがあります
2件目: 処理が致命的なエラーで止まると、片付け済みの場所を指す「メモ」が残ることがあります。同じワーカー(依頼を順番に処理するプロセス)が次の依頼を処理するとき、そのメモに従って片付け済みの場所を使ってしまいます

Wizは、これらの欠陥を組み合わせて、WordPress・Drupal・Joomlaでログインなしにサーバー上でプログラムを動かせることを実証したと書いています。

PHP公式は、WebサーバーのApacheにPHPを組み込むmod_phpという構成を最も危険としています。
この構成では、サイトのプログラムが動き出す前の段階で攻撃が成立するためです。

サイトの作りが丁寧でも、この欠陥は防げません。
欠陥はPHPそのものにあるため、PHPを更新しない限り直りません。
Cloudflareも、サイトのコードやプラグインを更新するだけでは直らず、PHP本体の更新が必要だと説明しています。

影響を受けるバージョンと修正版

修正版は 8.5.12、8.4.27、8.3.36、8.2.35
Wizによると、PHP 5.4以降のほぼすべての版が少なくとも1件の影響を受ける
PHP公式は、Webのリクエストを処理しているPHPはすべて危険だとしている(PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeed)

古い版には次の事情があります。

PHP 8.1以前は公式の更新が終わっており、修正版は出ない
ソースから自分でビルドする人向けに、7.4・8.0・8.1用の最小限の修正が公開されている
PHP 8.2は2026年12月31日にサポートが終わる

発見から修正版公開までの流れ

PHPの開発を支えるPHP Foundationが公開した時系列を中心に、ほかの出典で補っています。

日時(JST)	出来事	出典
2024年	外部監査の対応中に、PHPのコア開発者がメモリ不足の問題の兆候に気づく	PHP Foundation
2026年8月11日	セキュリティ企業のCalifとOpenAIが、それぞれ独立にRCEとして報告	PHP Foundation
8月24日	Wizが追加の発見を報告	PHP Foundation
9月18日	OpenAIがほかの攻撃経路を報告	PHP Foundation
10月17日	Amazonのおとりサーバーで攻撃の試みを観測(後日の発表で判明)	Amazonの発表を伝える報道
10月21日 0:00ごろ	CVE番号、誤った公開時刻、誤った深刻度10.0がネット上に流出	PHP Foundation
10月21日 4:30	PHPが事前告知を早め、修正版の公開を24時間前倒し(22日23:00から21日23:00へ)	PHP Foundation
10月21日 5:00ごろ	Califが攻撃の実証動画を誤って公開	PHP Foundation
10月21日 8:00ごろ	重要インフラ事業者向けの緩和策の助言が漏れた可能性	PHP Foundation
10月21日 12:02	Cloudflareが自社のWAF(不正な通信を遮る仕組み)で既定の防御を開始	Cloudflare
10月21日 16:41	Chainguardが修正入りのソフトウェアを先行公開	PHP Foundation
10月21日午後〜夜	国内の多くのサービスが停止・緊急メンテナンス	Impress Watch
10月21日 21:55	高市首相がXで対応を呼びかけ	報道
10月21日 23:00	修正版を公開	php.net

8月に報告を受けてから、PHP側は2か月以上かけて修正を準備していました。
情報の管理が崩れたのは、最後の1日です。

修正版の前に4か所で情報が漏れた

脆弱性は通常、見つけた人と開発元が非公開のまま修正を準備し、修正版と同時に公表します。この進め方を協調開示と呼び、公表までは外に出さない約束をエンバーゴ(情報解禁の制限)と呼びます。
修正版が出る前に欠陥が知られると、守る側が何もできないまま攻撃を受けるからです。

今回は、このエンバーゴが次の4か所で崩れました。

CVE番号と誤った情報の流出

21日0時ごろ、CVE番号がネット上のフォーラムやSNSに出回りました。
一緒に出回った公開時刻と深刻度10.0は、どちらも誤りでした。
技術的な詳細は漏れていません。

これを受けてPHPは、事前告知を早めに出し、修正版の公開を予定より24時間早めました。

攻撃の実証動画の誤公開

21日5時ごろ、セキュリティ企業のCalifが、攻撃が実際に成立する様子を映した動画を誤って公開しました。
このような実演や実証用のコードをPoC(概念実証)と呼びます。

動画は削除されましたが、コピーがSNSで広まりました。
PHP Foundationは、このコピーがほかの人によるPoC作りを早めたと伝えられている、と書いています。

緩和策の助言の流出の可能性

PHP Foundationは、一部の重要インフラ事業者に、修正版の前にできる対策を助言していました。
21日8時ごろ、この助言が漏れた可能性があるとしています。

Chainguardによる修正版の先行公開

Chainguardは、ソフトウェアを動かす環境一式をまとめた「コンテナイメージ」を提供している企業です。
21日16時41分、正式公開より6時間以上早く、修正入りのイメージを誰でも入手できる形で公開しました。

修正版を入手すると、変更点を調べることで欠陥の場所を突き止められます。
PHP Foundationは、Chainguardが一方的にエンバーゴを破り、攻撃者が修正内容を調べられる状態にしたと批判しています。

一方、ChainguardのCEOであるDan Lorenc氏は、英The Registerの取材にこう答えています。

公開の時系列は否定しないが、情報を漏らしてはいない
研究者の一人から何かが来ると聞き、その後チーム自身で同じ欠陥を見つけた
公表前からすでに被害を受けている人がいたので、修正版を出すと判断した
方針は協調開示だが、実際の悪用の証拠があれば例外とする

双方の主張は食い違っています。どちらが正しいかを判断できる材料は、今回確認できていません。

攻撃は実際に起きていたのか

ここは出典によって書き方が違うため、分けて並べます。

公表より前の観測は次のとおりです。

Amazonは、10月17日におとりサーバー(攻撃を観測するために置くサーバー)で攻撃の試みを観測したと発表した。送信元は匿名化サービスのIPアドレスで、攻撃者がどこで情報を得たかは分からないとしている
CloudflareのCTOは、修正版の公開前から初期の攻撃を観測していると述べた(Patchstackの記事より)

公表前後の評価は次のとおりです。

Patchstackは、22時57分の時点で自社のデータには探りを入れるアクセスしかなく、侵入の確証はないとした
PHPのセキュリティチームは、公表の時点で実際に動く攻撃コードは見つかっていないとした
Amazonは、公表のあとに大規模な悪用が始まっているとしている(Techzineの報道より)

「攻撃の試み」と「侵入に成功した攻撃」は別物です。公表より前から試みはあった一方、公表の時点で侵入の確証は示されていない、というのが今回確認できた範囲です。

修正版の前にサービスを止めた理由

冒頭の問いに戻ります。修正版は23時に出る予定だったのに、なぜ多くのサービスはその前から止まったのでしょうか。

Impress Watchは、修正版の公開後に攻撃が始まるのに備えて、予防的に止めたとみられると伝えています。

報道と公式発表から読み取れる事情は次の3つです。

修正版が出ると、変更点から欠陥の場所が分かり、攻撃方法を作りやすくなる
動画のコピーや先行公開された修正版で、すでに手がかりが出回っていた
首相と国家サイバー統括室が、更新がすぐにできない場合はサイトの一時停止も有効な対策だと呼びかけた

ここからは推測です。
修正版が出てから更新が終わるまでの間、外からの通信を受け付けない状態にしておけば、その間に攻撃を受けることはありません。
各社の停止は、この空白の時間をなくすためだったと考えられます。

ただし、各社が停止理由をPHPへの対応と明言したかどうかは、報道によって扱いが分かれています。

国内への影響

報道で確認できた主な停止は次のとおりです。
いずれも予防的な停止として報じられており、被害が出たという報道は今回確認できていません。

Webサービスとゲームでは次のとおりです。

BASE、コドモン(21日午後から)
pixiv、niconico、DMM.com
さくらインターネットの一部機能
グランブルーファンタジー、ウマ娘プリティーダービー

公的機関や企業のサイトでは次のとおりです。

財務省のサイトの一部
首相の公式サイト(ギズモード・ジャパンの報道)
ANA・JALのグループ企業情報サイトや一部のページ(運航・予約・発券のシステムには影響なしとしている)

観光・レジャー分野では、トラベルボイスが次の例を伝えています。

SCRAP(リアル脱出ゲーム)のチケット販売・申し込みのページ
京都バスのホームページ
長野県の小谷村観光連盟の公式サイト

政府の対応としては、IPA(情報処理推進機構)と国家サイバー統括室が注意喚起を出しました。高市首相は21日21時55分にXで、修正版をすぐに適用できない場合はサイトの一時停止もリスクを下げる有効な手段の一つだと述べています。

2024年に兆候がありながら修正が遅れた理由

時系列の表のとおり、1件目の兆候は2024年にPHPの開発者が気づいていました。
それでも修正は2026年10月までかかりました。

PHP Foundationはこの遅れを、セキュリティチームの意思決定の仕組みと人手不足による「構造的な失敗」だったと認めています。
The Next Webによると、経緯は次のとおりです。

修正案は複数あったが、それぞれに代償があった(過去との互換性が壊れる、サービス停止攻撃の危険が増える、数千の拡張機能に変更が必要になる)
小さなチームが全員一致で決める方式をとっていたため、誤った選択を恐れて作業が止まり、数か月にわたって再開と中断を繰り返した
2024年の時点では具体的な攻撃方法が見つからず、より明白な問題が優先された

PHP Foundationは今後の対策として次を挙げています。

セキュリティの判断を全員一致から多数決に変える
2026年5月にエコシステムのセキュリティチームを作り、担当のエンジニアを増やした
AIを使った検査を取り入れる(Claude Mythosによるコードの検査、OpenAIのDaybreak Redによる報告の検証など)
PHPに頼る企業・ホスティング事業者・政府に、資金面での支援を求める

サイトを運営している人がすること

サイトを見るだけの人がすることはありません。対応が必要なのは、サイトの運営者やサーバー会社です。

PHP公式の案内では、確実な対策は更新だけです。

8.5.12、8.4.27、8.3.36、8.2.35、または利用中のLinuxディストリビューションの修正済みパッケージに更新する
本番だけでなく、検証用の環境、コンテナ、PHPを内蔵した機器やソフトウェアも洗い出す
Remiのリポジトリ(有志が提供するPHPの配布元)は公開当日は未対応だったため、ディストリビューションのパッケージに切り替えるか、ソースからビルドする

すぐに更新できない場合、PHP公式は次の暫定策を示しています。これらは攻撃の経路を減らすだけで、安全にはならないと明記されています。

; CVE-2026-109618 向け(アプリから上書きできない場所で設定する)
memory_limit=-1
post_max_size=8M    ; ファイルのアップロードがある場合は32M

; CVE-2026-109619 向け(設定後にすべてのワーカーを再起動する)
session.upload_progress.enabled=0
fatal_error_backtraces=0    ; PHP 8.5のみ

更新後の対応として、Patchstackは次のことを勧めています。

影響を受けたサーバーは侵入された可能性があるものとして扱う
サーバーが持っていたパスワード、トークン、APIキーを変更する(ワーカーのメモリの中身が漏れるおそれがあるため)

確認できていないこと

最後に、今回の調査で確認できなかった点を挙げます。

Amazonが観測した10月17日の攻撃の試みについて、攻撃者がどこで情報を得たか(Amazon自身も分からないとしている)
Chainguardが「すでに被害を受けている人がいた」と判断した具体的な根拠
「世界のWebサイトの約7割」という数字の出典
国内で実際の被害が出たかどうか

1点目について補足します。
ここからは推測です。
10月17日は、CVE番号が流出した21日0時ごろより前です。
そのため、エンバーゴに参加していた関係者の周辺から情報が漏れた可能性と、攻撃者が独自に同じ欠陥を見つけた可能性の両方が考えられます。
今回の公開情報からは、どちらとも判断できません。

最後まで読んでいただきありがとうございました。

参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up