「PHPショック」で何が起きた？サイト停止とAIが見つけた欠陥の深層

「PHPショック」で何が起きた？

問題の中心はPHP本体で修正された「CVE-2026-109618」と「CVE-2026-109619」という2件の脆弱性だ。脆弱性とはソフトウェアの不具合のうち、攻撃に悪用されるおそれがあるもの。CVEは個々の問題を取り違えずに追うための共通の識別番号である。

PHPプロジェクトは10月21日、修正を含む4系列のバージョンを公開し、速やかな更新を呼びかけた。「PHPショック」は一連の混乱を指す呼び名で、海外の研究資料では「PHP2Shell」とも呼ばれている。[1]

最初に、似て見える三つの状態を分けておこう。

状態	何を意味するか
脆弱性がある	攻撃に使われ得る欠陥がある。侵入されたという意味ではない
サイトを停止した	外部からの接続を止めて更新・調査する予防措置の場合もある
侵入・情報漏えいを確認した	ログや痕跡などを調べ、具体的な被害を確認した状態

たとえば、さくらインターネットは修正版の公開に先立つ10月21日22時30分から、一部サービス・機能を予防的に停止したと説明した。同社は22日14時現在、調査で不正アクセスや情報漏えい等の被害は報告されていないとしている。これは同社のその時点の報告であり、すべてのPHP利用サイトの安全を示すものではない。[2]

停止のお知らせを見て、すぐに「この会社は攻撃された」と受け取ると、対応の意味を読み違える。危険な状態で営業を続けないために、運営者が自ら止めたケースも含まれる。

PHPはサイトの裏側で何をしている？

ネットショップで商品を選び、カートを開く。会員サイトでログインし、自分の予約を見る。こうした場面では画面に文字や写真を並べるだけでなく、サーバー側で情報を取り出し、計算し、利用者に合った結果を返す処理が必要になる。

PHPはその処理を書くためのプログラミング言語だ。サーバーとはサイトのデータや機能を利用者に提供するコンピューターのこと。PHPのプログラムは主にそこで動き、作成した画面などをブラウザーへ返す。PHPの公式マニュアルは画面の構造などを記述するHTMLに埋め込めることや、サーバー側で実行することを特徴として挙げている。[3]

役割を、ネットショップの例で並べるとわかりやすい。

部分	主な役割の例
ブラウザー	画面を表示し、クリックや入力を受け付ける
サーバー上のPHPプログラム	商品や会員情報を照会し、注文内容を処理する
データベース	商品、在庫、会員などのデータを保存する

実際のサイトでは複数の技術を組み合わせるため、この表は役割をつかむための簡略図だ。すべてのウェブサイトがPHPを使うわけでも、PHPがデータベースそのものであるわけでもない。

もう一つ、今回の理解に欠かせない区別がある。PHPには「プログラムを書く言語」という意味に加え、書かれたプログラムを読み取って動かす「処理系」というソフトウェアがある。今回修正されたのは、このPHP処理系の内部だ。店ごとに書いた注文処理だけを点検すれば済む問題ではなかった。

個人のホームページ用ツールが共通基盤になるまで

PHPの起点は、Rasmus Lerdorf氏が1994年に作った個人用のツールにさかのぼる。公式の歴史によると、当初は自分のオンライン履歴書への訪問を追うためのもので、「Personal Home Page Tools」と呼ばれた。1995年にソースコードを公開し、その後、データベースとの連携などへ用途を広げていった。現在のPHPという名称は「PHP: Hypertext Preprocessor」を意味する。[4]

名前に「ホームページ」の名残があるからといって、個人サイトだけの技術ではない。記事を管理するコンテンツ管理システム（CMS）、ネットショップ、社内システムなど、多くの用途の基盤になっている。

よく目にする「世界のサイトの約7割」という数字には、母数の説明が要る。W3Techsの10月22日の集計では、PHPの利用率は69.3％。これはサーバー側のプログラミング言語を同社が把握できたウェブサイトのうちの割合だ。インターネット全体の通信量、利用者数、今回侵入されたサイトの割合ではない。[5]

広く使われる技術では、一つの修正が多数のサービスに関係する。利用者からは別々の店やサービスに見えていても、裏側では同じPHP処理系を使っている。その共通性が今回の対応を同時多発的に見せた。

研究に参加したWizはWordPress、Drupal、Joomlaの環境で認証前のリモートコード実行を実証したと報告した。ただし、それらの製品名は実証に使った例であり、欠陥はPHP本体にある。CMSがその三つ以外なら対象外、とは判断できない。[6]

なぜログイン前でも危険なのか？

通常、会員ページにはパスワードの確認がある。しかし、サーバーが通信を受け取ってから、その確認用プログラムが動くまでにも処理がある。送られてきた入力を読み取り、内部のデータを準備する工程だ。

今回の問題ではその準備や後片づけも攻撃の対象になった。PHPの公式アドバイザリはウェブサーバーソフトApacheにPHPを組み込む「mod_php」で、サイト固有のプログラムが動く前に攻撃を起こせる実証があると説明している。ログイン画面があること自体は、この段階の保護を意味しない。[1]

「リモートコード実行」、略してRCEとは、離れた場所の攻撃者が相手のコンピューターで自分の意図したプログラムを動かすこと。単にサイトを見えなくする攻撃よりも、操作の範囲が広がり得る点で深刻だ。

ただし、RCEの成功を「サーバーの全権限を即座に奪った」と言い換えるのも正確ではない。公式の技術報告で確認された実行権限はウェブの処理を担当するアカウントのものだ。そこから触れられるデータや機能は、権限設定や他の防御策によって変わる。[7]

一方、そのアカウントが業務データや認証情報へアクセスできれば、影響は小さくない。Wizはコード実行とは別に、PHPプロセスのメモリから機密情報を読み出す実証も報告している。画面が正常に見えているだけでは、内部で何も起きていないとは確認できない。[6]

2件の欠陥に共通する「後片づけ」の問題

PHPは届いた要求を処理するためにメモリを使う。ここでいうメモリは処理中のデータを一時的に置く作業場所だ。要求の処理が終われば、使った領域を解放したり、次の処理に向けて状態を初期化したりする。

その順序が途中のエラーで崩れた。2件は関連するが、同じ不具合を別の名前で呼んでいるわけではない。

CVE-2026-109618：準備途中のデータを後片づけで使ってしまう

一つ目はメモリ不足に達したときの処理に関係する。OOMは「Out of Memory」の略で、必要なメモリを確保できない状態を指す。

公式報告によると、PHPではメモリ不足の際に現在の処理から抜け出す。そのタイミングによっては、内部データが準備途中のまま残り、後片づけの処理がそれを完成済みのデータとして扱ってしまう。攻撃者がこの状態を起こし、メモリの扱いを崩すことで、不正なコード実行へつなげられる。[7]

たとえるなら、書きかけの作業票を正式な指示書として回収係へ渡してしまうようなものだ。「メモリが足りずに処理が止まる」だけで終わらず、止まった後の処理も危険になる。

CVE-2026-109619：終わった要求の情報を次の要求で使ってしまう

二つ目は前の要求に属していた内部状態が残る問題だ。PHPでは一つの処理担当プロセスが、複数の要求を順に扱うことがある。この担当を「ワーカー」と呼ぶ。

前の要求で使ったメモリを解放したのに、ワーカー側にその場所を指す情報が残る。さらに次の要求が通常の初期化より前に古い情報を使うと、すでに使い終えた領域へ触れてしまう。専門的には「解放後使用」、英語ではuse-after-freeと呼ばれる。[8]

机の上を片づけても、前の作業票に書いた引き出し番号だけが残り、次の担当がそれを有効な指示だと思ってしまう。問題は単なるゴミの残留ではなく、古い情報を有効なものとして扱うことにある。

この経路の一つに、ファイル送信の進み具合を追う「セッションアップロード進捗」というPHPの機能がある。公式マニュアルもアップロード中の状態を記録する機能として説明している。アプリ側で進捗表示を作った覚えがない、という理由だけで関係がないとは言えない。[9]

ここまでを整理すると、危険なのは「大きなファイル」そのものではない。入力の処理、エラーによる中断、後片づけ、次の要求の初期化という連続した工程のどこで、不整合が生じるかが問題になった。

PHP-FPMなら安全、という線引きもできない

PHPとウェブサーバーのつなぎ方によって、問題が表れる条件は変わる。広く使われる「PHP-FPM」はPHPの処理を専用のワーカー群へ任せる方式だ。

公式報告では、要求の開始に失敗した際、mod_phpは後片づけへ進む一方、FPMは担当の子プロセスを終了させる。この違いにより、ある攻撃経路はFPMでそのまま成立しない。しかし、通常の開始後にアプリケーション側の処理を経由するなど、別の条件で問題に到達する可能性は残る。[7][8]

Califの研究報告もFPMで開始時の失敗をそのまま使う経路と、開始後の処理を通る経路を分けて説明している。方式名だけを見て安全と判断するのではなく、PHPと配布元が示す修正を適用する必要がある。[10]

また、深刻度の「CVSS 9.2」は攻撃の条件や影響を共通の尺度で評価した数値だ。感染確率92％という意味でも、全環境で同じ攻撃が同じように成功するという意味でもない。公式評価には攻撃の複雑さや成立条件も含まれる。深刻な問題であることと、環境ごとに条件が異なることは両立する。[7]

AIは何を見つけた？人間は何をした？

OpenAIの説明では、Califが「Patch the Planet」という取り組みの中でGPT-5.6 Solを使って重大な欠陥を発見し、Wizも独立して両方の脆弱性を発見・報告した。修正とリリースを主導したのはPHPの保守担当者で、各社が調査や検証、対策の準備を支えたという。[11]

「AIが自動で全部見つけ、全部直した」という話にすると、この分担が消えてしまう。

Califは、研究者が過去のPHPの問題を踏まえて調査を進め、AIに関連する処理を調べさせた過程を公開している。初期の発見に、一般には利用できない特別なモデルが必要だったわけではないとも説明した。これは同社の研究についての報告であり、誰でも同じ指示を入れれば同じ結果が出るという実証ではない。[10]

一方、Wizは複数の不具合をつなぎ、対象ごとのメモリ配置に合わせて検証を繰り返す過程で、先端モデルが実用上の負担を下げたと述べている。欠陥が以前から存在することと、それを悪用できる形に組み立てやすいことは違う。AIはその間にある調査・試行の手間を変え得る。[6]

この違いは防御する側にも攻撃する側にも作用する。見つかりにくかった問題を早く直せる可能性がある一方、公開された修正から攻撃方法を推測する時間も短くなり得る。「AIが安全にした」「AIが危険にした」という一方向の評価では、更新を急ぐ理由を十分に説明できない。

2024年の兆候から緊急公開まで

PHP Foundationは、2024年の監査への対応中にOOM問題の兆候を把握したものの、当時は具体的な悪用経路を確認できず、修正案にも互換性やサービス停止攻撃のリスクなどの難しさがあったと説明する。意思決定と人員不足による遅れを、同財団は構造的な失敗と認めている。[12]

この経緯は「危険だとわかったのになぜすぐ直さないのか」という疑問を考える材料になる。広く使われる処理系では、一つの箇所を変更することが、多数の拡張機能や既存サイトの動作に関係する。修正に伴う別の問題も確かめる必要がある。ただし、その難しさが長期の停滞を当然にするわけではない。

公開資料で追える主な節目を並べる。時刻がある行は日本時間へ換算した。

時期	公表資料に記された出来事
2024年	PHP側が、後に今回の問題につながるOOMの兆候を把握
2026年8月11日	Califが最初の問題をPHPへ報告。後日、動作する実証を共有
10月21日0時ごろ	PHP Foundationによると、CVE番号などがネット上で流通
10月21日4時30分	PHP側が事前告知を公開。修正版の公開を予定より1日前倒し
10月21日23時	修正版の公開時刻。更新とサービスごとの検証へ

Califの報告から修正公開までには、約2カ月の検証・調整期間があった。PHP Foundationによると、当初の公開予定は10月22日14時UTCで、番号等の流通を受けて21日14時UTCへ変更した。最初の流出には技術詳細は含まれなかったが、その後、実証動画も誤って公開されたという。[10][12]

脆弱性の「協調的な公開」は、修正を作る人、配布する人、使う人が準備する時間をそろえるための調整だ。少数の人だけが知る期間を設ければ漏えいのリスクがあり、一斉にすべて公開すれば準備前の利用者が取り残される。この調整自体が防御の一部になっている。

「公開前は攻撃されていなかった」とは言えない

公開までの経緯には、さらに確かめるべき点がある。

Amazon Threat Intelligenceは、攻撃の動きを観測するための仕組み「MadPot」で、10月17日にPHP2Shellの悪用試行があったと報告した。一般公開の4日前にあたる。同社は、公開当日にも複数の試行を確認し、公開後は広く悪用されていると説明している。ただし、観測した個々の試行が実システムで成功したか、攻撃者が事前に情報を得た経路は不明としている。[13]

攻撃の試行を観測したことと、特定企業の侵入被害を確認したことは違う。 同時に、公開日より前の安全を保証する材料にもならない。

OpenAIは、同社が把握する限り、攻撃者に先んじてAIが発見し、防御側に準備の時間があったと説明した。一方、AWSの報告は公開前の攻撃試行を示している。研究者が先に見つけたことと、その後の非公開期間に攻撃者が動いた可能性は両立する。どちらか一方だけを選び、「完全に先回りできた」「公開までは安全だった」とまとめるべきではない。[11][13]

運用上は、修正版へ更新する作業と、それ以前の痕跡を調べる作業を分けることになる。英国のNCSCも直ちに更新・停止できない場合には、侵害やバックドアの有無を確認するよう求めている。バックドアとは、侵入後も外部から入り直せるように残される不正な仕組みのことだ。[14]

更新は欠陥を塞ぐが、すでに残された不正ファイルや盗まれた認証情報まで、さかのぼって消してくれるわけではない。

修正版が出ても復旧時刻がそろわない理由

PHPプロジェクトが修正を公開してから、個々のサイトでその修正版が動き始めるまでには、いくつかの工程がある。

1. PHP側が修正を公開する。
2. 基本ソフト（OS）やサービスの配布元が、自分たちの提供形態に合わせた更新を用意する。
3. 運営者が更新を適用し、動いているワーカーを切り替える。
4. ログイン、注文、予約などの機能と、必要な侵害調査を確認して再開する。

この順序は一般的な整理で、サービスによって担当範囲は異なる。重要なのは、最初の「公開」だけで全工程が終わらないことだ。

オランダのNCSCが公開した対応情報も、外部製品に組み込まれたPHPや、アプリの実行環境をまとめたコンテナを別に確認するよう求めている。サーバーに入っているPHPを一つ更新しても、別のアプリに同梱されたPHPまで更新されるとは限らない。[15]

たとえば、本体のサイトを直しても、管理画面、検証用の旧サイト、別のコンテナが残っていれば、それぞれの確認が要る。トップページが表示できることだけでなく、外部から到達できるPHPの置き場を把握できているかが重要になる。

海外のホスティング会社Shock Mediaも、公式パッチを適用中としたうえで、配布元の更新が各OS・PHPバージョンへ届くまで差があり得ると案内した。こうした提供経路の違いが復旧の時差を生む。[16]

WordPress更新やWAFだけで解決する？

WordPressを管理している人にとって、管理画面の「更新」は身近な操作だ。しかし、WordPress本体、テーマやプラグイン、PHP処理系は別の更新対象になる。今回の修正でまず確かめるのはサイトを実行しているPHPに対策が入っているかである。

PHPが10月21日に公開した修正版は、次のとおりだ。これは今回の修正が入った基準となるバージョンで、今後も新しいセキュリティ情報を確認する必要がある。[1]

利用している系列	今回の修正版
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

OSや長期保守の提供元が、修正だけを古い系列へ取り込む「バックポート」を配る場合もある。そのため、画面に表示される番号だけで判定せず、配布元のセキュリティ情報と配布物の修正状況を照合する。

PHP 8.1以前は、PHPプロジェクトによる通常のサポートが終わっている。今回、7.4、8.0、8.1向けに最小限のソース修正も提供されたが、これは通常サポートの再開ではない。長期保守の提供元への確認と、サポート対象へ移行する計画が必要になる。[15]

WAFはサイトへ届く通信を調べ、攻撃らしいものを遮る仕組みだ。Cloudflareは今回の問題への防御ルールを公開し、要求だけでなく応答も組み合わせて調べる対策を説明した。同社自身もWAFを追加の防御として残しつつ、PHPの更新を行うよう勧めている。[17]

ここから言えるのは、WAFの導入や一つの設定変更を「修正済み」と同じ意味にしないことだ。通信を遮る対策と、欠陥のある処理を直す対策は役割が違う。

ネット上で広がる「この設定を切れば終わり」という説明にも注意したい。アップロード進捗の無効化は確認された経路の一部を遮る措置である。また、PHPのメモリ上限を外す暫定策には、サーバー全体の資源管理も関わる。一般向けの一行設定として、条件を省いて勧められるものではない。PHP公式は設定だけでは完全な対策にならないと明示している。[1]

なお、PHP 8.2のセキュリティサポート終了日は2026年12月31日だ。今回の更新を済ませることと、年末以降も保守できる状態にすることを、別々に計画する必要がある。[18]

利用者・サイト運営者・経営者が確かめること

一般の利用者が自分のスマートフォンへ「PHP修正版」を入れるという話ではない。中心となる更新はサービスを提供するサーバー側の作業である。

利用者は停止しているサービスの公式告知で、予防措置なのか、侵害の調査中なのか、情報漏えいが確認されたのかを読み分けたい。パスワード変更や決済への対応が必要かは、運営者が示す対象と内容を確認する。「PHPを使っていた」という情報だけから、全サービスで同じ被害があったと判断することはできない。

サイトを持つ会社では制作会社やホスティング事業者へ少なくとも次の点を確認できるとよい。

• どこにPHPがあるか。 公開サイトだけでなく、管理画面、旧サイト、同梱製品やコンテナも対象に含めたか。
• 修正が実際に動いているか。 対策済みのソフトウェアの配布物・実行環境へ切り替え、必要なワーカーの再起動まで終えたか。
• 更新前の期間を調べたか。 不審なアクセス、ファイル変更、意図しないプログラムの実行などを確認し、未確認の範囲を把握しているか。
• 再開後の業務を確かめたか。 表示だけでなく、問い合わせ、ログイン、予約や決済など、その会社に必要な機能が動くか。

NCSCは外部公開されたシステムを優先してPHPの利用箇所を洗い出すこと、同梱ソフトの更新を追うこと、対応が困難なら停止も検討することを勧めている。調査に自信がない場合は、専門家の支援を得るとしている。[14]

経営者が担当者へ聞くべき問いも「もう直った？」だけでは足りない。「修正の適用」「侵害の調査」「業務機能の復旧」のどこまで終わったかを分ければ、再開の判断に必要な情報が見えやすくなる。

PHPをやめれば問題はなくなる？

今回の欠陥は重大だ。しかし、その事実だけから、すべてのサイトを別の言語へ急いで作り直すという結論にはならない。

PHPを別の技術へ置き換える場合も、新しい処理系、ライブラリー、OS、クラウドサービスなどへの依存は残る。どの技術を使うかに加え、何に依存しているかを把握し、修正を受け取り、適用できるかが運用上の判断になる。

PHPの監査そのものが今回初めて始まったわけでもない。PHP Foundationが2025年に公表した監査結果は、2024年に行った外部監査と、見つかった問題への対応を説明している。今回の経緯を「誰も点検していなかった」で説明すると、監査で得た兆候をどう扱うかという課題を見落とす。[19]

さらに同財団の10月14日の説明によると、セキュリティチームは7月以降、15件のCVEを公表する一方、無効・重複・再現不能の報告も100件以上扱った。報告が増えるほど、確認して優先順位を付ける仕事も増える。[20]

PHPショックから読み取れる課題は、発見の速さと修正を届ける力の差だ。AIで調査が速くなっても、影響を見極め、互換性を確かめ、配布物を用意し、各社の業務を復旧させる工程が自動的に短くなるわけではない。

共有するソフトウェアが多くの事業を支えているなら、その保守に必要な人員や資金も事業継続の一部として考えられる。障害が起きた日にだけ更新を急ぐのか、日頃から依存先と責任範囲を把握しておくのか。今回の混乱は、その差が利用者の目にも見える出来事になった。

まとめ

• サイト停止は被害の証明ではない。 PHP本体の重大な欠陥を受け、攻撃を防ぐために止めたサービスもある。停止・攻撃試行・侵入成功を分けて読む必要がある。
• 今回の問題は共通基盤の内部にあった。 ログイン処理やCMSだけでは守れない経路があり、PHPの修正適用に加え、動作中の環境と更新前の痕跡の確認が要る。
• AIによる発見の先には人と組織の仕事が残る。 修正の判断、配布、再開までを支える体制があって初めて、見つかった欠陥を利用者の安全へつなげられる。

出典・参考

1. PHP「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）
2. さくらインターネット「【重要】PHPの脆弱性に関する当社の対応状況について」（2026年10月22日）
3. PHP Manual「Introduction」
4. PHP Manual「History of PHP」
5. W3Techs「Usage statistics of PHP for websites」（2026年10月22日の集計を確認）
6. Wiz Research「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」（2026年10月21日）
7. PHP公式セキュリティ報告「RCE via OOM corruption / GHSA-w8hw-w9fx-j79w」（2026年10月21日）
8. PHP公式セキュリティ報告「RCE via stale global state / GHSA-6wmf-4rv5-p3rp」（2026年10月21日）
9. PHP Manual「Session Upload Progress」
10. Calif Research「A tale of two PHP remote vulnerabilities」（2026年10月の公開資料）
11. OpenAI「Patch the Planet: global response coordination as agents uncover critical vulnerabilities」（2026年10月21日）
12. The PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」（2026年10月21日）
13. AWS Security Blog「Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot」（2026年10月21日）
14. 英国NCSC「Critical security issue affecting PHP」（2026年10月21日）
15. オランダNCSC「php2shell vulnerabilities」（2026年10月21日更新）
16. Shock Media「php2shell investigation」（2026年10月22日確認）
17. Cloudflare「Cloudflare deploys protections against php2shell vulnerability」（2026年10月21日）
18. PHP「Supported Versions」（2026年10月22日確認）
19. The PHP Foundation「PHP Core Security Audit Results」（2025年4月10日）
20. The PHP Foundation「How the PHP Security Team Handles Your Reports」（2026年10月14日）