自社の設定を無料で確認する→
流出マップ原因調査レポートNo.001
情報漏えい原因調査レポート　No.001

PHP2Shellは、なぜ世界中のサイトを止めたのか

Webサイトの約7割を支える言語の中に、ログインなしでサーバーを乗っ取れる穴が10年以上眠っていた。AIがそれを掘り起こし、修正版より先に情報が漏れ、各国でサイトが自ら止まった。発見から攻撃までを、公開された一次情報と観測データで追う。

2026年10月22日 公開KEYRING編集部2026年10月22日時点の公開情報にもとづく読了の目安 約25分

数字で見るPHP2Shell

出典は各数字の下に記載
深刻度（CVSS v4.0）
9.2

2件ともCritical（緊急）。PHPの開発チームの評価

PHPを使うWebサイト
69.3%

サーバー側の言語が分かるサイトのうち（W3Techs、10月22日）

公式の修正版が配られない版で動くPHPサイト
48.4%

8.1以前で動くサイトの割合。W3Techsの版別の内訳から編集部が算出

穴が残っていた期間
14年

2012年のPHP 5.4.0から、最新の8.5まで

公開初日に観測された攻撃
743件

33か所の送信元から。ELLIOのおとりのサーバーで、10月21日23時（協定世界時）まで

探りから不正なファイルの設置まで
81分

ある送信元が、最初の探りから乗っ取り用のファイルを置くまで（ELLIO）

エグゼクティブ
サマリー

  1. アプリのコードが正しくても防げない穴だった。PHPがリクエストを読み込む段階、つまりWordPressなどのアプリが動き出す前に、ログインなしで任意のコードを実行できた。「Hello World」を返すだけのアプリでも対象になる。
  2. 修正版より先に、情報と修正済みの部品が外に出た。公開の前日にCVE番号が漏れ、研究者の動画が誤って公開された。さらに公開の6時間以上前に、ある配布事業者が修正済みのイメージを先に出した。最初の攻撃はその約1時間後に観測されている。
  3. PHPのサイトの約半数は、公式の修正版が配られない古い版で動いている。W3Techsの集計から算出すると48.4%にのぼる。国内では、更新できずにサービスを終えた例も出た。
  4. AIが「難しすぎて攻撃できない」という前提を崩した。穴の兆しは2024年の監査で見つかっていたが、修正が止まっていた。2026年8月、AIを使った研究者が攻撃できる経路を示し、1週間で作業が進んだ。PHPの開発体制は、報告の急増に追われている。
  5. 早く止められたのは、事前の備えがあった組織だった。自社のどこでPHPが動いているか、誰が止める判断をするかを決めていた組織は、修正版の公開前に手を打てた。

1はじめに

PHPは、Webサイトの裏側で動くプログラムを書くための言語です。ブログや企業サイトで広く使われるWordPress、Wikipediaを動かすMediaWiki、ネット通販のMagentoなどがPHPで書かれています。調査会社W3Techsによると、サーバー側の言語が分かるWebサイトのうち69.3%がPHPを使っています。

2026年10月20日、PHPの開発チームは、深刻度が最も高い「Critical」の脆弱性2件を翌日に修正すると予告しました。CVE-2026-109618とCVE-2026-109619です。攻撃用のツールの名前から、研究者のあいだでは「PHP2Shell」と呼ばれています。個別のアプリではなくPHPそのものの穴なので、PHPで動くほぼすべてのWebサイトが対象になりました。

修正版が出る前から攻撃が観測され、欧州では政府機関のサイトが、日本ではネット通販やゲームのサービスが、更新までのあいだ自らサイトを止めました。日本では首相がXで、修正版の速やかな適用を呼びかけました。

このレポートは、公開された一次情報（PHPの開発チームと財団、発見した研究者、各国の公的機関）と、攻撃の観測データ、報道をもとに、次の問いに答えます。

  • 何が、いつ、どの順番で起きたのか
  • なぜ、アプリの側では防げなかったのか
  • どれだけのサイトが、どれだけ危なかったのか
  • 攻撃者は、公開から何時間で何をしたのか
  • なぜ、ここまで影響が広がったのか
  • 企業は、いま何を確かめ、次に何を備えればよいのか
調査の方法と範囲

2026年10月20日から22日までに公開された情報を対象にしました。数値は出典の値をそのまま使い、編集部が計算した値はその旨を記しています。攻撃の件数は、特定の観測網（ELLIOのおとりのサーバー）で記録されたもので、インターネット全体の件数ではありません。被害の有無は、当事者が公表したものだけを書いています。

2発見から攻撃までの全経緯

穴の兆しは2年前に見つかっていました。修正が止まったまま時間が過ぎ、2026年夏にAIを使った研究者が攻撃できる経路を示したことで、修正が最優先になりました。公表を予定日に合わせて準備していたところ、その2日前から情報が漏れ始めます。

図表1発見から公開翌朝までの経緯（日本時間。括弧内は協定世界時）
  1. 2024年
    外部監査で兆しが見つかる

    PHP財団が資金を集めて実施した外部の監査の過程で、財団の開発者がメモリー不足のときの処理の問題に気づいた。攻撃に使える具体的な経路は見つからず、修正の方針も1つにまとまらないまま、作業は止まっては再開することを繰り返した。

    出典：PHP財団
  2. 2026年8月11日
    CalifとOpenAIが報告

    OpenAIの取り組み「Patch the Planet」で7月30日からPHPを監査していたセキュリティ企業Califが、無条件でコードを実行できる経路を報告。OpenAIも同じ日に、同じ原因を別に報告した。この日から、修正が財団の最優先になった。

    出典：PHP財団
  3. 8月19日〜24日
    Wizが別に発見し、報告

    Wiz Researchが8月19日に最初の脆弱性を見つけ、20日にDrupal、21日にWordPressで、ログインなしのコード実行を確認。24日にPHPへ報告した。

    出典：Wiz
  4. 10月21日 0:00（20日 15:00）
    CVE番号が漏れ始める

    2件のCVE番号が、誤った公開時刻と誤った深刻度（10.0）とともに、掲示板やSNSに出回り始めた。技術的な詳細は漏れていなかった。

    出典：PHP財団
  5. 10月21日 4:30（20日 19:30）
    PHPが公開を1日早めると予告

    開発チームが事前告知を前倒しで公開。修正版の公開を22日から21日に早めた。配布事業者がまだ準備中だったため、即日ではなく1日後とした。

    出典：PHP財団、php.net
  6. 10月21日 5:00ごろ（20日 20:00ごろ）
    研究者の動画が誤って公開される

    Califが、攻撃が成功する様子を写した動画を誤って公開。すぐに削除されたが、写しがSNSで広まり、攻撃用コードの開発を早めた。

    出典：PHP財団
  7. 10月21日 16:41（07:41）
    修正済みのイメージが先に出る

    事前に修正を受け取っていた配布事業者Chainguardが、取り決めより6時間以上早く、修正を含むイメージを公開。修正箇所から穴を推測できる状態になった。

    出典：PHP財団
  8. 10月21日 17:36（08:36）
    最初の攻撃を観測

    ELLIOのおとりのサーバーに、最初のPHP2Shellの攻撃が届く。9分間で51件。Cloudflareも、公開前の攻撃を報告した。

    出典：ELLIO、Cloudflare
  9. 10月21日 22:00前
    首相がXで対応を要請

    高市首相が自身のXで、修正版を速やかに適用できるよう準備することを求め、すぐに適用できない場合はサイトの一時停止も有効な策の1つだとした。

    出典：ITmedia NEWS
  10. 10月21日 22:30〜23:00（13:30〜14:00）
    修正版を公開

    PHP 8.5.12、8.4.27、8.3.36、8.2.35を公開。CalifとWizが技術的な詳細を公表した。

    出典：php.net、CERT-EU
  11. 10月22日 1:05（21日 16:05）
    本格的な攻撃ツールが現れる

    開発チームの告知に書かれた手口に沿った攻撃が届き始める。修正版の公開から約2時間後。

    出典：ELLIO
  12. 10月22日 8:16（21日 23:16）
    乗っ取り用のファイルが置かれる

    ある送信元が、最初の探りから81分で、サーバーの公開フォルダーに不正なPHPファイルを書き込む一連の操作を実行した。

    出典：ELLIO

開発チームと財団は、公開の2日前までは調整がうまく進んでいたとしています。崩れたのは、情報が漏れ、修正済みの部品が先に出た最後の48時間でした。財団は、修正済みのイメージを先に出したChainguardについて「何週間にもわたる多くの関係者の調整を無視した」と書いています。

32つの脆弱性の仕組み

2件とも、PHPがメモリーを解放したあとも、その場所をまだ使えるデータとして扱ってしまう種類の不具合です。きっかけは、メモリー不足などの致命的なエラーで、リクエストの処理が途中で打ち切られることです。後片付けが済まないまま、壊れた状態が次のリクエストに引き継がれます。

図表22件の脆弱性と、その中に含まれる4つの不具合
識別番号不具合攻撃者ができること研究者が示したこと
CVE-2026-109618メモリー不足のときの破損アップロードの進み具合を記録する処理で、解放済みのメモリーを使うメモリーを壊してコードを実行するWordPress、Drupal、Joomlaで、ログインなしのコード実行
別のリクエストのメモリーの中身を、応答のCookieに入れて返してしまうログインなしで、サーバーのメモリーの中身を読むアプリを問わず、メモリーの中身が漏れる
CVE-2026-109619古い状態が残る致命的なエラーの記録が、解放済みのメモリーを指したまま残るメモリーを壊してコードを実行するDrupalで、ログインなしのコード実行
高速化の仕組み（OPcache）の共有データが、別の種類のデータとして読まれる共有の状態を壊してコードを実行するWordPressで、ログインなしのコード実行

出典：Wiz「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」、PHP「Security advisory」（いずれも2026年10月21日）

図表3なぜアプリの側では防げなかったのか
攻撃者の リクエスト Webサーバー Apache・nginx PHPの読み込み フォームやアップロードを 解析する段階　ここに穴 アプリ WordPress・Magento など アプリのコードが動く前に、攻撃が成り立つ

各組織の公表内容をもとにKEYRING編集部が作成

PHPは、ファイルのアップロードなどで使われる形式（multipart/form-data）のリクエストを、アプリの処理が始まる前に解析します。穴はこの段階にありました。アプリがセッションを使っていなくても、ログイン画面を持っていなくても、関係ありません。Wizは「Hello World」を返すだけのアプリでも対象になると書いています。

メモリーの中身が漏れる不具合は、2014年に問題になった「Heartbleed」に似ています。漏れる中身には、ほかの利用者のリクエストに含まれるパスワード、ログイン状態を保つ鍵、APIキー、TLSの秘密鍵が含まれえます。コードを実行されなくても、情報が抜かれる可能性がありました。

影響を受ける動かし方

Apache＋mod_php

開発チームが最も危ないとした構成。初期設定のまま、ログインなしの1回のリクエストで攻撃が成り立つ

PHP-FPM

nginxなどと組み合わせる一般的な構成。アプリの処理を経由した攻撃で、コード実行が確かめられた

php-cgi・FrankenPHP・LiteSpeed

Webのリクエストを処理するすべての構成が対象

4影響の規模

公式の修正版が出たのは、サポート中の8.2、8.3、8.4、8.5の4系統だけです。8.1以前の版には修正版のプログラムが配られず、7.4、8.0、8.1向けには、自分で組み立て直すための最小限の修正だけが公開されました。

では、世界のPHPサイトはどの版で動いているのか。W3Techsの版別の集計から算出すると、PHPのサイトのうち48.4%が、公式の修正版が配られない8.1以前の版で動いていました。

図表4PHPを使うWebサイトの版の内訳（PHPのサイト全体を100%とする）
8.322.7%
8.218.1%
8.47.9%
8.52.9%
8.19.9%
8.03.8%
7系26.9%
5系7.7%
4系0.1%

出典：W3Techs「Usage statistics of PHP」（2026年10月22日）、「PHP Version 8」「PHP Version 7」（10月21日）をもとにKEYRING編集部が算出。8系の内訳（8.3が34.8%など）にPHP全体に占める8系の割合（65.3%）を掛けて求めた。版が外から分かるサイトだけが集計の対象で、集計日が1日ずれている

古い版を使うサイトのすべてが、すぐに危なかったとは限りません。Linuxの配布元やサポート事業者が、古い版にも修正を移している場合があります。ただ、自社でそれを確かめられない組織にとっては、更新の手段がない状態でした。

PHPは、見えない場所でも動いている

PHPは、自社のWebサイトだけでなく、次のような場所にも組み込まれています。自社でPHPを使っている自覚がない組織も、対象に入りえました。

ホスティングの管理画面

cPanel、Pleskなど、レンタルサーバーの操作画面

業務アプリ・OSS

Nextcloud、Roundcube、phpMyAdmin、WHMCSなど。研究者はこれらでもコード実行を示した

ベンダーの機器・ソフト

PHPを同梱した機器や、一部のWindowsソフト。オランダの国家サイバーセキュリティセンターが、PHPを組み込んだ製品の一覧を公開している

出典：Huntress、Sansec、CERT-EU

5観測された攻撃

攻撃がどこまで起きたかは、発表した組織によって見方が分かれました。CloudflareとwatchTowrは公開前後の攻撃を確認したとし、米国の政府機関CISAは10月21日時点で悪用を確認していないとしました。ここでは、攻撃を細かく記録して公表した観測網ELLIOのデータを見ます。

図表5ELLIOのおとりのサーバーが記録した、公開日の攻撃の流れ（日本時間）
16時18時20時22時0時2時4時6時8時
16:41修正済みイメージが先に出る 17:36最初の攻撃　9分で51件 23:00修正版を公開 1:05本格的な攻撃ツール 5:40既存のボットが攻撃に加わる 8:16不正なファイルを設置
51
187
180
188

棒は、公表された時間帯ごとの件数（1時間あたり）。ほかの時間帯の件数は公表されていない

出典：ELLIO Threat Research Lab「PHP2Shell: attacks before the patch, and automation by nightfall」（2026年10月21〜22日更新）、PHP財団

743件

公開日の23時（協定世界時）までに届いた、アップロードの進み具合を記録する欄を含む攻撃

33か所

攻撃の送信元。通信の特徴から、いくつかのツールの系統に分かれる

48分

ある送信元が、受け付けを確かめる探りから、動く攻撃に至るまで

攻撃者は、公開された材料をそのまま使った

ELLIOによると、修正版の公開前に届いた攻撃は、漏れた材料から作られたものでした。ツールの名前ではCVE-2026-109618を名乗りながら、実際にはもう1件の脆弱性の経路を使っていました。開発チームの告知に書かれた手口に沿った攻撃は、公開の約2時間後に現れます。「修正の中身を解析しなくても、告知に書かれた緩和策の一覧が手口の一覧になった」とELLIOは書いています。

夜までに、攻撃は自動化されていきました。他の脆弱性を探して回っていた既存のボットが、PHP2Shellを手口に加えました。送り込まれようとしたプログラムは、他者のサーバーに大量の通信を送りつける攻撃に使われる「Mirai」の亜種で、乗っ取ったサーバーを遠隔で操作する機能も持っていました。

81分で、乗っ取り用のファイルが置かれた

ある送信元は、最初の探りから81分で、サーバーの公開フォルダーに不正なPHPファイル（Webシェル）を書き込む操作まで進みました。最後の8件は8分あまりのあいだに送られています。

  1. どの方法でセッションの番号を受け取るかを確かめる探り（2件）
  2. サーバーと公開フォルダーについて、1つずつ問い合わせる（4件）
  3. 公開フォルダーに小さなPHPファイルを書き込む（1件）
  4. 書き込めたかを、3つの場所で確かめる（1件）

出典：ELLIO。「Webシェル」は、外から命令を送ってサーバーを操作するために置かれる不正なファイル

読むときの注意

ELLIOの件数は、同社のおとりのサーバーが受けた攻撃で、インターネット全体の件数ではありません。また、同じ入力欄を使う以前からある別の手口も含まれ、1件ずつでは見分けられない場合があるとしています。公開時点で、実際の被害（侵入が成功した組織）を確認したという公表はありません。

6国内外の対応

各国の公的機関は、修正版を待つあいだサイトを止めることも選択肢に入れるよう呼びかけました。脆弱性への対応で、政府がサイトの停止まで勧めるのは異例です。

図表6国内外で報じられた主な対応
地域主体対応
日本首相21日午後10時前、Xで修正版を速やかに適用できるよう準備することを要請。適用が難しい場合、サイトの一時停止も有効な策の1つとした
日本国家サイバー統括室可及的速やかな対応を求め、Xで同様の内容を呼びかけた
日本民間サービス「BASE」「ウマ娘 プリティーダービー」「Shadowverse: Worlds Beyond」「コドモン」「さくらのレンタルサーバ」などが緊急メンテナンスに入った、または予告した
日本ワールドクエスト古い仕組みのため十分な対策がとれないとして、21日でサービスを終えた
日本GMO Flatt Security公開前に取れる備えを公表。当初挙げた設定変更が単体では不十分と分かり、訂正した
欧州CERT-EU、英国NCSC修正版の即時適用を勧め、できない場合はインターネットから切り離すよう勧告
欧州各国政府などオランダの政府ポータル、フィンランド政府の公開サービス、フランス内務省のサイト、デンマークの学校連絡網などが、更新までのあいだサイトを止めた
米国NSAすぐに更新できない場合は、サイトを止めるよう勧めた
米国CISA10月21日時点で、悪用を確認していないとした

出典：ITmedia NEWS（2026年10月21日、22日）、CERT-EU、Wikipedia「PHP2Shell」が引くReuters・BBC・NSA・NBC Newsの報道

国内で注目されたのは、首相が個別のソフトの脆弱性について、直接対応を呼びかけたことです。ITmedia NEWSによると、技術者からは「経営層にもリスクが伝わる」という評価が出ました。システムを止めると業務に響くため、修正の適用は先送りされがちです。止めることもリスクを下げる策だと首相が示したことは、経営層が停止を決める後押しになりえます。

一方、ワールドクエストの例は、サポートの切れた古い仕組みの上で動くサービスが、緊急の修正に追いつけないことを示しました。更新できない仕組みを抱えていると、選べる手段は、止めるか、終えるかに限られます。

7影響が広がった5つの理由

1言語そのものに穴があった

個別のアプリの不具合なら、そのアプリを使う組織だけが対象になります。今回はPHPの中の不具合で、アプリの出来にかかわらず、PHPで動くあらゆるサイトが対象になりました。アプリの前に置く防御の仕組みでも、完全には止められません。

2修正版より先に、情報と部品が出た

CVE番号の漏えい、動画の誤公開、修正済みイメージの先出しが重なり、修正版の公開前に攻撃が始まりました。事前に修正を受け取る関係者が多いほど、1社の判断で調整全体が崩れることが示されました。

3約半数が、修正版のない版で動いていた

PHPのサイトの48.4%が、公式の修正版が配られない8.1以前の版で動いていました。古い版を使い続けていたことが、緊急時の選択肢を狭めました。

4見つかっていた問題が、2年間直らなかった

PHP財団は、2024年に兆しを見つけながら修正が止まっていたことを「構造的な失敗」と認めています。直し方ごとに互換性や性能の問題があり、合意で決める仕組みと、エンジンを深く理解する開発者の少なさが、判断を遅らせました。

5AIが「攻撃は難しい」という前提を崩した

攻撃には、複数の不具合をつなぎ、サーバーごとのメモリーの配置に合わせる作業が要ります。人の手では難しく、実際に攻撃できるとは考えられていませんでした。AIがこの壁を下げました（次の章）。

PHP財団の声明より

「私たちは、ごまかすつもりはありません。この遅れは構造的な失敗でした。セキュリティチームの意思決定の進め方と、人手の不足の両方が原因です」

The PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」（2026年10月21日）を編集部が翻訳

8AIが変えた脆弱性の経済

今回の脆弱性は、AIを使った監査で見つかりました。OpenAIによると、2件のうち1件はCalifが同社のモデルを使って発見し、Wizも複数のAIを使って別に見つけています。

AIが変えたのは、穴を見つけることだけではありません。穴があっても、攻撃に使える形にするのが難しければ、実際の危険は小さいと見なされてきました。今回の穴も、10年以上そう扱われてきました。

Wizの報告より

「最先端のAIと適切な道具を使えば、1人の研究者が1週間で、以前なら世界水準のチームが何か月もかけていた作業を終えられた」

Wiz「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」を編集部が翻訳

同じ力は、攻撃する側も使えます。Wizは、攻撃をサーバーごとに合わせる手間をAIが減らすことで、「以前は攻撃できないと思われていた穴が、現実の標的になる」と書いています。「何が危ないか」の基準そのものが変わりつつあります。

図表7報告の急増に追われる開発体制（PHPのセキュリティチーム、2026年7月1日以降）
15件

7月1日から公表したCVE

100件超

無効、重複、再現できなかった報告

出典：PHP財団。AIで報告の検証や分類を助けているが、判断と修正はすべて人が行っているとしている

PHP財団は、道具が欠陥を見つける速さは上がっても、長年の設計の判断を直し、互換性を見極め、修正を確かめるのは、PHPを深く理解する技術者にしかできないとしています。そして、PHPに依存する企業、ホスティング事業者、政府に、継続的な資金の支援を求めました。

OpenAIが示した5つの段階

OpenAIは、AIが見つけた脆弱性に対応する枠組みとして、次の5段階を示し、セキュリティの専門家に意見を求めています。

  1. 上流の脆弱性を検証して修正する
  2. 影響を受ける組織に、対応する時間を与える
  3. 重要なシステムを守るため、政府と連携する
  4. 影響を受ける製品全体で、更新を準備する
  5. 修正版の公開後に指針を出し、展開を支える

出典：ITmedia NEWS「PHPの『重大』脆弱性はAIが見つけた」（2026年10月22日）が伝えるOpenAIの発表

9過去の事例との比較

Wizは、今回の脆弱性を、インターネットの共有基盤のもろさを示したHeartbleedや、ソフトの奥深くに組み込まれた部品の危うさを示したLog4Shellと並ぶ転換点になりうると位置づけています。PHPについては、2024年にも国内で悪用された脆弱性がありました。

図表8広く使われる基盤ソフトで起きた主な脆弱性
名前年対象何が起きたか今回と共通する点
Heartbleed2014OpenSSL通信を暗号化する部品から、サーバーのメモリーの中身が読めたメモリーの中身が漏れる。秘密鍵やパスワードが含まれうる
Log4Shell2021Log4j記録を残す部品を通じて、外から任意のコードを実行できた多くの製品の奥に組み込まれ、使っているかどうかの把握が難しい
CVE-2024-45772024PHP（Windows上）外から命令を実行できた。IPAが、国内の複数の組織でWebシェルが置かれたと注意を呼びかけた同じPHPで、公開後に国内で実際に悪用された
PHP2Shell2026PHP（すべての環境）ログインなしで任意のコードを実行でき、メモリーの中身も読めた上の3つの性質をあわせ持つ

出典：Wiz、IPA「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」（2024年7月5日）

2024年のPHPの脆弱性では、IPAが、国内の複数の組織でこの脆弱性が悪用されWebシェルが置かれていたと公表しました。置かれたWebシェルは、組織の内部への侵入や、ほかの組織を攻撃する踏み台に使われる恐れがあるとしています。今回も、修正版を当てたあとに、侵入の痕跡が残っていないかを確かめることが欠かせません。

10企業が取るべき対応

修正の手段は、PHPを更新することだけです。開発チームも、一時的な措置では安全にならないとしています。時間の順に並べます。

図表9確かめる順番
  1. 今日PHPがどこで動いているかを洗い出す

    自社のWebサーバーに加え、委託先やホスティング事業者のサーバー、ホスティングの管理画面、ベンダーの機器、PHPを同梱したソフトも含める。コマンドで確かめる版と、Webの処理に使われている版が違うことがあるので、Webの処理で確かめる。

  2. 今日修正版に更新する

    PHP 8.5.12、8.4.27、8.3.36、8.2.35のいずれかにする。Linuxの配布元やサポート事業者は事前に修正を受け取っているので、各社の更新を確認する。自社で更新できないサーバーは、委託先に更新の予定を問い合わせる。

  3. すぐ更新できないとき一時的に危険を減らす。止めることも選ぶ

    開発チームは、session.upload_progress.enabled=0、memory_limitの上限を外す設定、post_max_sizeを小さくする設定などを示している。アップロードを使わないアプリでは、multipart/form-dataのリクエストを手前で断つ方法もある。ただし一部の経路を塞ぐだけで、安全にはならない。サイトを止めることも選択肢に入れる。

  4. 更新のあと侵入された痕跡がないか確かめる

    PHPの処理がシェルやcurl、wgetなどを起動していないか、Webの公開フォルダーに見覚えのないファイルがないか、新しい定期実行の設定やアカウントが増えていないかを見る。メモリー不足のエラーの急増や、異常に大きいPHPSESSIDのCookieも手がかりになる。見つけたら、サーバーを切り離し、ログを残す。

  5. 今週中漏れた可能性のある秘密を入れ替える

    メモリーの中身が漏れた可能性があるサーバーでは、パスワード、APIキー、TLSの秘密鍵などの入れ替えを検討する。

  6. 今月中サポートの切れたPHPを棚卸しする

    8.1以前のPHPで動くシステムを一覧にし、移行の予定と、緊急時に誰が止めるかを決める。委託先との契約で、更新の責任と連絡の期限を決めておく。

出典：PHP「Security advisory」、CERT-EU、Huntress、Wiz、Sansec、GMO Flatt SecurityをもとにKEYRING編集部が作成

平時から備えておくこと

GMO Flatt Securityは、修正版の公開前に取れる備えとして、次の項目を挙げました。次の緊急事態に向けた、平時の点検項目としても使えます。

洗い出し

PHPを使う自社のシステムを、あらかじめ一覧にしておく

手順の確認

更新の手順と、更新後のアプリの動作の確かめ方を決めておく

止める連絡

サーバーを止めるときの、関係者への連絡の流れを確かめておく

データの最小化

サーバーに置くデータを、必要なものだけにする

権限の最小化

サーバーが持つクラウドの権限などを、必要なものだけにする

記録の保全

ログが残り、書き換えられにくいかを確かめる

出典：ITmedia NEWSが伝えるGMO Flatt Securityの提言（2026年10月21日）

役割ごとに確かめること

経営層
  • 緊急時に、サイトやサービスを止める判断を誰がするかを決めているか
  • 止めた場合の顧客への連絡と、業務への影響を見積もっているか
  • 古い仕組みを使い続けることの危険を、投資の判断に入れているか
情報システム部門
  • PHPを含む部品の一覧（どの版がどこで動くか）を持っているか
  • 修正版の公開から適用までの時間を、何時間と見ているか
  • 侵入の痕跡を調べる手順と、ログの保管期間を決めているか
委託先の管理
  • 委託先のサーバーで動くPHPの版を把握しているか
  • 緊急の更新を、何時間以内に行うかを契約で決めているか
  • 委託先が更新したことを、どう確かめるかを決めているか

11提言

今回、早く手を打てたのは、自社のどこでPHPが動いているかと、誰が止める判断をするかを、事前に決めていた組織でした。脆弱性が見つかってから台帳を作り始めても、修正版の公開には間に合いません。この調査から、KEYRINGは次の4つを提言します。

1部品の台帳を、平時に作る

Webサイトや業務システムが、どの言語のどの版で動いているかを一覧にし、委託先の分も含めて更新し続ける。

2「止める」を、判断の選択肢に入れる

修正版より先に攻撃が始まる時代には、更新を待つあいだ止めることが現実的な策になる。誰が、何を基準に止めるかを決めておく。

3サポートの切れた版を、残さない

サポートの切れた版は、緊急時に修正版が来ない。移行の期限を決め、移行できないシステムは外から切り離す。

4「攻撃は難しい」を、安全の根拠にしない

AIで攻撃の手間が下がった。深刻度が高い脆弱性は、攻撃が難しそうに見えても、すぐに直す前提で計画する。

提言は、公開された情報をもとにKEYRING編集部が考えたものです。

自社の状況を確かめるAI開発セカンドオピニオン

委託先の管理、システムに渡している権限、脆弱性への対応の手順を、第三者の基準で確かめた結果を表示します。設問に回答、約8分、無料。

診断を始める→
ほかの調査レポート No.002　2026年10月23日GMOのFX用サーバーから、取引口座はなぜ勝手に動かされたのか→

用語集

脆弱性
ソフトの設計や作りの欠陥で、攻撃に悪用できるもの
CVE
脆弱性ごとに付けられる世界共通の識別番号
CVSS
脆弱性の深刻度を0〜10で示す共通の指標。9.0以上がCritical（緊急）
リモートコード実行
離れた場所から、相手のサーバーで任意のプログラムを動かせること
Webシェル
外から命令を送ってサーバーを操作するために、攻撃者が置く不正なファイル
サポート切れ（EOL）
開発元が修正版を出さなくなった版
協調的な開示
脆弱性を見つけた人と開発元が、修正版の準備ができるまで公表を控え、日時を決めて同時に公表すること
mod_php・PHP-FPM
WebサーバーでPHPを動かす方式。前者はApacheに組み込む方式、後者は別の処理として動かす方式

参考文献

このレポートは2026年10月22日時点の公開情報にもとづきます。攻撃の状況や影響の範囲は変わる可能性があり、新しい情報があれば更新します。英語の資料の引用は編集部の翻訳です。最終閲覧日はいずれも2026年10月22日です。