ITワクワク塾PHP2Shellとは？PHPの重大な脆弱性とサイト運営者がやること
2026年10月21日の夜、多くのWebサイトやゲームが一斉に緊急メンテナンスに入りました。きっかけは、Webサイトを動かすプログラミング言語PHPに見つかった2件の重大な脆弱性です。
本記事では、PHPの開発元や公的機関が出した一次情報をもとに、この脆弱性の中身と、公表から修正までの流れを解説します。修正版が公開された直後がなぜ危ないのか、サイトを運営している人は何をすればよいのかも、あわせて整理しました。
【メモ】
同じ10月21日には、Node.jsも10件の脆弱性を直した修正版を公開しました。中身と開発者がやることは、Node.jsのBrotli脆弱性とは？で解説しています。
PHP2Shellとは
PHP2Shell（php2shell）は、2026年10月に公表された、PHP本体の2件の脆弱性の呼び名です。調査を担当したセキュリティ企業のWizが公表の際に使い、米国のサイバーセキュリティ機関CISAも、同じ名前で注意を呼びかけました。主な点を表にまとめます。
| 項目 | 内容 |
|---|---|
| 対象の脆弱性 | CVE-2026-109618、CVE-2026-109619 |
| 不具合がある場所 | PHP本体（WordPressなどのアプリではない） |
| 悪用されると | 遠隔コード実行（RCE）。サーバーのメモリの中身を読み出されることもある |
| 攻撃の条件 | ログインは要らない |
| 深刻度（CVSS v4.0） | どちらも10点満点中9.2 |
| 影響を受けるもの | Webのリクエストを処理するPHPのすべて（CISAによる） |
| 修正版 | PHP 8.5.12、8.4.27、8.3.36、8.2.35（2026年10月21日23時公開） |
CVE番号は、世界中の脆弱性を見分けるために1件ずつ付けられる識別番号を指します。遠隔コード実行（RCE：Remote Code Execution）とは、インターネットの向こうにいる攻撃者が、他人のサーバーの上で、自分の用意したプログラムを動かせてしまうことです。今回はログインしていない状態からでも攻撃できると確かめられました。
【メモ】
遠隔コード実行がどんな弱点から起こり、なぜ特に重く扱われるのか、どう備えればよいかは、遠隔コード実行（RCE）とは？で解説しています。
名前にあるシェルは、サーバーに命令を打ち込むための窓口のことです。PHPを足がかりにサーバーを操作されてしまう、という意味の名前と読めます（命名の由来は公表されていません）。
PHPがリクエストを処理する流れ
PHP2Shellの2件は、どちらもPHPがリクエストを処理するときの、作業場所の準備と片付けの不備から起こります。2件の仕組みを知るために、まずPHPがリクエストを処理する流れを見ておきましょう。
ブラウザーでページを開くと、サーバーに「このページを見せてください」という依頼が届きます。この依頼が、リクエストです。下の図は、1つのPHPがリクエストを受けてからページを返すまでの流れを示しています。
PHPは、リクエストを受け取るたびに、メモリという作業場所を準備してページを組み立てます。返し終えたら作業場所を片付け、次のリクエストに備える流れです。
PHPは、ページを開かれるたびに起動し直すわけではありません。1つのPHPが、何百件ものリクエストを順番に受け持ちます。そのため、準備や片付けが不十分だと、前のリクエストの残りが、あとの処理に持ち越されかねないのです。
【メモ】
ブラウザーとサーバーがどのように役割を分けているかは、クライアントサーバーシステムとは？で解説しています。
2件とも、リクエストの処理が途中で失敗したときに、この準備や片付けが正しく行われなくなる不具合でした。違いを表にまとめます。
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| きっかけ | メモリが足りなくなり、処理が途中で止まる | 処理が途中で止まり、片付けたはずの場所を指すメモが残る |
| 誤りが起こる場面 | 止まったリクエスト自身の後片付け | 同じPHPが次のリクエストを受け、準備を終える前 |
| 攻撃に使うリクエスト | 1回で済む場合がある | 2回 |
CVE-2026-109618の脆弱性の仕組み
CVE-2026-109618は、メモリが足りなくなったときの処理の打ち切り方に不備があり、作りかけのデータが残ってしまう脆弱性です。攻撃者は、1回のリクエストでこの不備を突けます。流れを図にしました。
PHPには、1件のリクエストが使えるメモリの上限があり、上限を超えるとその場で処理を打ち切ります。ところが、作業場所を準備している途中で打ち切ると、作りかけのデータが残ってしまいました。そのあとに動く後片付けの処理は、このデータを正しいものとして読んでしまうのです。
攻撃者は、わざとメモリを使い切らせるリクエストを送ります。PHPの開発チームは、その方法の例として、ファイルを送る形式（multipart/form-data）のリクエストに、見出しを数えきれないほど付けるやり方を挙げました。リクエストの大きさは上限に収めたまま、PHPの中で使うメモリだけを膨らませられるというわけです。
この誤りは、リクエストの本文を読み込む段階で起こります。ApacheにPHPを組み込んで動かす形（mod_php）では、アプリのプログラムが動き始める前に攻撃が成立すると確かめられました。
CVE-2026-109619の脆弱性の仕組み
CVE-2026-109619は、片付けたはずの作業場所を指すメモが残り、次のリクエストで使われてしまう脆弱性です。攻撃には、同じPHPが受ける2回のリクエストを使います。
PHPは、エラーの内容やセッションの状態などを、リクエストをまたいで使える場所にメモしています。このメモは、そのリクエストの作業場所を指すものです。本来なら作業場所を片付ける前に、メモも消さなければなりません。
1回目のリクエストで、エラーやメモリ不足を起こして処理を途中で止めると、メモを消す前に作業場所だけが片付けられます。その結果、メモはもう使われていない場所を指したまま残るのです。
2回目のリクエストを同じPHPが受けると、準備を終える前に動く一部の処理が、この古いメモを頼りに作業を始めてしまいます。PHPの開発チームは、設定についての警告を出す処理と、ファイルの送信の進み具合を記録する処理を例に挙げました。攻撃者は、解放された場所に自分の用意したデータが入るよう仕向けておき、そのデータを使わせるという流れです。
どちらの脆弱性も、攻撃者が送るリクエストの中身しだいで、残ったデータを思いどおりに使わせられます。うまくいけば、サーバーのメモリの中身を読み出したり、サーバー上で好きな命令を動かしたりできてしまうというわけです。これが、先に説明した遠隔コード実行にあたります。
【ポイント】
不具合があるのは、WordPressなどのアプリではなくPHP本体のほうでした。調査したWizは、「Hello World」と表示するだけの簡単なプログラムでも、修正前のPHPなら影響を受けるとしています。
なぜWordPressが名指しされたのか
危険なのは、修正前のPHPを使っているすべてのサイトです。WordPress本体やプラグインに不具合があったわけでもなく、WordPress.orgも、WordPressの更新は必要ないと案内しています。
今回の攻撃には、ログインが要りません。Wizは、ログインしていない状態から、WordPress、Drupal、Joomlaのサイトでサーバー上の命令を動かせることを実演しました。PHPの開発チームによると、サーバーの設定によっては、アプリのプログラムが動き始める前の段階で攻撃が成立します。
そのため、アプリやプラグインを最新にしていても、パスワードを強くしていても防げません。WordPressに入れるセキュリティ対策のプラグインも、PHPの上で動くプログラムなので、PHPそのものの不具合は止められないのです。
乗っ取られたときに失うものも、小さくありません。多くのアプリは、記事や会員の情報を保存するデータベースのパスワードを、サーバー上の設定ファイルに書いています。サーバー上で命令を動かされれば、このパスワードを盗まれたり、ページを書き換えられたり、訪問者を偽サイトへ誘導する仕掛けを埋め込まれたりしかねません。Wizは、メモリから読み出せる情報として、パスワード、ログインの状態を保つための情報、APIキーを挙げました。
それでもWordPressの名前が繰り返し挙がったのは、影響を受ける人がいちばん多かったためです。理由は次の3つに分けられます。
| 理由 | 内容 |
|---|---|
| 数が多い | サーバー側の言語が分かるサイトの69.3%がPHPを使い、WordPressだけで全Webサイトの39.6%を占める（W3Techsの調査、2026年10月22日） |
| 狙う場所が共通 | どのサイトにもログイン画面の /wp-login.php のような共通の場所があり、攻撃者はサイトを自動で探し出して、まとめて攻撃を試せる |
| 自分で対処しにくい | 技術者ではない個人や小さな会社が、レンタルサーバーを借りて運営する例が多い。PHPのバージョンも、サイトを作ったときのままのことが珍しくない |
IPAも、サポートが終わった古いPHPを使い続けているサイトが見られると指摘していました。同じ危険を抱えたサイトの中で、最も数が多く、自分で対処できない運営者が多いのがWordPressだったのです。
公表から修正までの流れ
PHPの開発チームは、予定より1日早く修正版を公開しました。公開までの出来事、各社のメンテナンス、なかでも評価を集めたエックスサーバーの対応を順に見ていきます。
修正版の公開までの出来事
PHPの開発チームは当初、10月22日23時に修正版を公開する予定でした。公開を1日早めたのは、修正版より先に情報が外へ出てしまったためです。主な出来事を、時刻の順に並べました。
| 日本時間 | 出来事 |
|---|---|
| 8月11日 | セキュリティ企業のCalifとOpenAIが、同じ原因の不具合をそれぞれPHPに報告する。8月下旬にはWizも報告 |
| 10月17日 | Amazonのおとりのサーバーに、この不具合を狙ったとみられる攻撃の試みが届く（Amazonが21日に公表） |
| 10月21日 0時ごろ | 2件のCVE番号が、フォーラムやSNSに出回る |
| 10月21日 4時30分 | PHPの開発チームが、修正版を21日23時に公開すると予告する |
| 10月21日 5時ごろ | 報告した企業の1社が、攻撃の実演動画を誤って公開する。すぐに消されたが、コピーが広まる |
| 10月21日 夕方〜夜 | レンタルサーバー各社や大手のサービスが、緊急メンテナンスに入る。首相がXで呼びかける |
| 10月21日 23時 | PHPの開発チームが修正版を公開する |
| 10月22日 朝以降 | サーバー各社が、修正版や修正の取り込みをサーバーに当て終えたと順に発表する |
PHPの開発を支えるPHP Foundationは、実演動画のコピーが出回ったことで、攻撃の準備が早まったと説明しています。ただし、公開の時点では、CISAもIPAも実際の攻撃を確認していませんでした。
修正版の公開の約1時間前には、高市早苗首相が自身のXに次のように投稿しています。
投稿では、公開しているWebサイトでPHPを使っているかを確かめ、23時に公開される修正版をすぐに当てられるよう準備してほしいと求めました。すぐに当てられない場合は、Webサイトを一時的に止めることもリスクを下げる方法の1つだとしています。
緊急メンテナンスに入った主なサービス
10月21日の夕方から22日の朝にかけて、レンタルサーバーのほか、動画、通販、ゲームなどのサービスが相次いでメンテナンスに入りました。主なサービスの停止と再開を表にまとめます。
| サービス | 停止の開始（日本時間） | 再開の状況 |
|---|---|---|
| さくらのレンタルサーバ | 21日23時 | 22日6時30分に作業を完了 |
| ConoHa WING | 21日19時 | 22日12時からサーバーを順に再起動するメンテナンスを追加し、20時45分に修正の完了を発表 |
| エックスサーバー | 21日16時 | 利用者のサーバーは止めずに稼働。管理画面は22日9時30分、公式サイトは22日20時10分から順に再開。23日16時20分の時点で、サーバーパネルの一部の機能はメンテナンス中 |
| ニコニコ | 21日19時 | ニコニコ動画などは22日15時30分、ニコニ・コモンズなどは22日20時に再開し、21時30分にすべての完了を発表 |
| BASE | 21日15時50分 | 22日8時に完了（7時の予定から延長） |
| ウマ娘 プリティーダービー | 21日22時ごろ | 22日2時30分に終了 |
| グランブルーファンタジー | 21日22時 | 22日7時に終了（DMM版とGREE版を除く） |
| Pokémon Sleep | 21日23時 | 22日に、セキュリティ対策とVer.3.9.0へのアップデートの作業を終えたと発表 |
【メモ】
各社の公式の告知とXの投稿をもとに、10月24日の時点でまとめました。エックスサーバーは23日16時20分、ニコニコは22日21時30分の更新が最新です。その後に状況が変わっている場合があります。
エックスサーバーの対応がXで評価された理由
各社のメンテナンスのなかで、X上で特に評価を集めたのがエックスサーバーの対応です。Yahoo!リアルタイム検索の「話題順」で、エックスサーバーをほめる投稿のうち最も反応が多かったのは、Web制作者のたにぐち まこと氏の投稿でした。いいねの数は、10月22日19時の時点で600件を超えています。
投稿は理由として、作業の早さ、情報公開の量と質、バージョンアップの対応を挙げています。公式の発表と見比べると、それぞれ次のような対応でした。
まず、止めたのは自社の公式サイトと管理画面だけで、利用者のサーバーは動かし続けました。Webサイトの表示やメールの送受信は、メンテナンス中もそのまま使えると案内しています。修正版の公開前から、利用者のサーバーにも被害を抑えるための対策を当てていたそうです。サーバー会社の中には、利用者のサイトごと止めたところもありました。
次に、修正は新しいバージョンから順に、すべてのサーバーへ当てられています。公式のXで発表された完了の時刻は、次のとおりです。
| 完了の時刻（10月22日） | 修正を当て終えたPHPのバージョン |
|---|---|
| 6時44分 | 8.2〜8.5 |
| 12時8分 | 7.4〜8.1 |
| 14時3分 | 5.6〜7.3 |
PHPの開発チームが修正版を出していない8.1以前にも、エックスサーバーは独自の修正を当てています。Xでは5.6まで遡って修正したことに驚く声が相次ぎました。その後もさらに古い5.1〜5.5への修正を進め、23日17時の時点で、対象のサーバーの過半数に当て終えたと発表しています。
最後に、進み具合の伝え方です。公式のXでは「メンテナンス状況について」と題した投稿を何度も出し、どのバージョンまで修正が済んだかを、そのつど知らせました。お知らせのページにも、利用者のサーバーで行っている対策を、よくある質問として載せています。
一方で、管理画面が止まっていた間は、PHPのバージョンを切り替えることも、自分でサイトを止めることもできませんでした。不安を訴える投稿も目立っています。サポートが終わった古いPHPへの修正も、サーバー会社の判断で行われたもので、次も同じ対応があるとは限りません。そのため、8.1以前を使っている場合は、この機会にサポート中のバージョンへ移っておくと安心です。
修正版の公開前後で、危険はどう変わったか
修正版の公開前から、危険はありました。ただし、公開を境に攻撃の試みは桁違いに増えています。最も危ないのは、修正版が公開されてから、自分のサーバーに修正が当たるまでの間です。
公開前の段階でも、攻撃者が自力で同じ不具合を見つける可能性はあります。今回は別々の3社が数週間のうちに同じ不具合を見つけていました。見つける力のある人が探せば、たどり着ける不具合だったことになります。そのうえ、CVE番号と実演動画が先に漏れ、攻撃者に手がかりを与えてしまいました。
実際に、Amazonの公表によると、CVE番号が出回るより前の10月17日に、攻撃の試みが観測されています。Amazonが置いたおとりのサーバー（ハニーポット）に届いたもので、攻撃者がどこから情報を得たのかは分かっていません。本物のサーバーで攻撃が成功したかどうかも、分からないとしています。
運営者の側からは、公表前の不具合の場所を知る方法がなく、その不具合だけを狙って防ぐことはできません。サポート中のバージョンを使い続け、修正版が出たらすぐ当てられる状態にしておくのが、運営者にできる備えになります。攻撃らしい通信をまとめて遮断する仕組み（WAF）や、日ごろのバックアップも、被害を小さくする助けになるはずです。
修正版が公開されると、修正前と修正後のプログラムを見比べられるようになり、どこを直したかが分かります。直した場所が分かれば不備の場所も分かるので、自力で探す技術がない攻撃者でも、狙う方法を作れてしまうのです。
CloudflareのCEOのMatthew Prince氏は、Cloudflareのネットワークで観測した攻撃の試みの件数をXで公表しました。
| 時点 | 攻撃の試み |
|---|---|
| 公開前の10時間 | 数千件 |
| 公開後45分 | 数万件 |
| 公開後2時間以内 | 数十万件 |
| 投稿時点（10月22日10時25分） | 数百万件 |
公開前の数千件は、漏れた情報をもとにした試みと考えられます。10月23日の時点で、CISA、IPA、JPCERT/CCは、攻撃が成功した例を確認したとは発表していません。修正版の公開前に、各社のメンテナンスを待たずに自分でサイトを止めた運営者がいたのは、このためです。財務省も21日のうちに、自分のサイトの一部を止めていました。
一方、修正を当て終えたサーバーは、この2件の攻撃を受けても影響を受けません。各社が修正版の公開に合わせて夜を徹して作業したのは、危ない期間をできるだけ短くするためでした。
緊急メンテナンスでサイトや管理画面が止まったのは、主にPHPを入れ替えて再起動する作業のためです。サーバー会社によっては、ファイルの管理画面やWebメールも「予防措置」として止めていました。
サイト運営者がやること
修正を当てる人は、サイトがどこで動いているかで変わります。まず自分のサイトの場合を確かめ、そのうえで、修正版が出ないとき、修正までサイトを止めるとき、修正が当たったあとの点検を順に見ていきましょう。
サイトが動いている場所ごとの対応
サイトがどこで動いているかによって、修正を当てる人と、運営者がやることが変わります。
| サイトが動いている場所 | 修正を当てる人 | 運営者がやること |
|---|---|---|
| レンタルサーバー | サーバー会社 | お知らせで修正が済んだかを確かめ、実際に動いているPHPのバージョンを見る |
| VPSやクラウドの仮想サーバー | 自分 | OSを更新し、PHPを入れ替えて再起動する |
| コンテナ | 自分 | 修正済みのPHPを使って作り直す |
| 静的サイト | なし | 影響を受けない |
レンタルサーバーでは、サーバー会社が「今のバージョンのまま修正を当てる」と案内していれば、管理画面でPHPのバージョンを切り替える必要はありません。新しいバージョンを選んでも、その中身が修正済みとは限らないためです。
修正済みかどうかは、番号だけでは判断できない場合があります。PHPの開発チームが出した修正版なら「8.4.27」のように最後の数字が上がりますが、サーバー会社が今の番号のまま修正を当てることもあるためです。ConoHa WINGは、番号を変えずに修正を当てたため、WordPressのサイトヘルスに「8.5.11」のような古い番号が表示されても修正済みだと案内しました。番号が上がっていないときは、サーバー会社のお知らせで、自分のバージョンの修正が済んだかを確かめてください。
VPSやクラウドの仮想サーバーを借り、OSから自分で管理している場合は、サーバー会社のメンテナンスを待たずに、すぐ修正を当てられます。UbuntuやRed Hat Enterprise Linuxなどの多くのLinuxでは、PHPの番号を上げずに、今の番号のまま修正だけを取り込む仕組みです。番号を見ただけでは修正済みか分からないため、使っているLinuxのセキュリティ情報で確かめてください。PHPとアプリをまとめた「コンテナ」で動かしている場合も、修正済みのPHPでの作り直しが必要です。
すぐに修正できないときは、サーバーの手前に置いて攻撃らしい通信を遮断する仕組み（WAF）が、時間稼ぎになります。Cloudflareは、修正版の公開より約9時間早い21日12時2分に、無料の利用者も含めて遮断のルールを自動で適用しました。ただし、PHPの開発チームも、WAFは完全な対策ではないとしています。
あらかじめ作ったHTMLを配るだけの「静的サイト」は、ページを開かれてもサーバーでプログラムが動きません。PHPを使っていないので、今回の脆弱性の影響を受けないのです。なお、IPAは、製品や機器の内部でPHPが使われている場合もあるとして、マニュアルや提供元の情報を確かめるよう呼びかけました。
PHPのバージョンが古く、修正版が出ない場合
PHPの開発チームが修正版を出したのは、8.2、8.3、8.4、8.5の4つだけで、バージョンごとの状況は次のとおりです。
| PHPのバージョン | 公式の修正版 | サポート |
|---|---|---|
| 8.3〜8.5 | 出ている | 続いている |
| 8.2 | 出ている | 2026年12月31日で終わる |
| 8.1以前 | 出ない | すでに終わっている |
サーバー会社によっては、古いバージョンにも独自に修正を当てています。上で紹介したエックスサーバーがその例です。一方で、さくらインターネットは、古いPHPを使っている利用者にPHP 8.3への移行を求めました。まずは、サーバー会社のお知らせで、自分のバージョンが修正の対象に入っているかを確かめてください。
対象に入っていなければ、サポート中のバージョンへの切り替えが必要です。ただし、PHPのバージョンを上げると、古いテーマやプラグインが動かなくなることがあります。切り替える前に、サイト全体のバックアップを取り、WordPress本体、テーマ、プラグインを最新にしておけば、トラブルを減らせるはずです。
切り替えが済むまでの間は、次に説明する方法でサイトを止めておくことも考えてください。WordPress.orgも、古いPHPを使っていて、すぐに更新できない場合は、サーバーを止めることを検討するよう呼びかけています。
修正が当たるまでサイトを止める
修正が当たる前の時間帯は、サイトを一時的に止めることでリスクを下げられます。首相の投稿、CISA、英国のNCSCも、すぐに修正できない場合の対応として、システムの一時停止を挙げていました。
止めるときは、PHPが動く前に止める方法を選んでください。よく使われる止め方を、PHPが止まるかどうかで分けると次のようになります。
| 止め方 | PHPは止まるか |
|---|---|
サーバーの設定ファイル（.htaccess）で、全てのアクセスに「メンテナンス中」（HTTPの503）を返す |
止まる |
| サーバー会社の管理画面で、パスワードによるアクセス制限（Basic認証）をかける | パスワードを通るまでは止まる |
WordPressの「メンテナンスモード」のプラグインや、.maintenance ファイルを使う |
止まらない。メンテナンス画面を出すためにPHPが動く |
トップページの index.php の名前を変える |
止まらない。ログイン画面などのほかのPHPファイルは動き続ける |
WordPressの中で使うメンテナンスの仕組みは、どれもPHPの上で動いています。今回の対策としては、.htaccess かBasic認証のように、PHPに届く前に止める方法を選ぶのが確実です。
修正が当たったあとに確かめる
修正が当たっても、それより前に入り込まれていれば、裏口が残ったままになります。修正の前にサイトを止めていなかった場合は、次の点を確かめておくと安心です。
| 確かめる場所 | 見ること |
|---|---|
| WordPressのユーザーの一覧 | 覚えのない管理者が増えていないか |
| プラグインの一覧 | 入れた覚えのないプラグインがないか |
| サーバーのファイル | 見覚えのないファイルや、最近書き換えられたファイルがないか |
| サイトの表示 | 身に覚えのない広告やリンクが入っていないか |
Web制作者のなかじ（中島大介）氏は、修正版が出る前の21日午前中に、管理しているWordPressを全部点検したとXに投稿しました。複数のサイトで、バックドア（あとから入り直すための裏口）、見知らぬ管理者、正体の分からないプラグインやファイルが見つかったそうです。
点検したのは攻撃の試みが増える前なので、侵入の原因は今回の脆弱性とは限りません。古いプラグインなどから、以前に入り込まれていた可能性もあります。今回の騒ぎを、自分のサイトを点検するきっかけにしてください。
サーバーのログを見られる場合は、JPCERT/CCが注意喚起で挙げた痕跡も手がかりになります。ただし、レンタルサーバーでは、契約によって見られないログもあるでしょう。
| 見る場所 | 見ること |
|---|---|
| アクセスログ | 普段と違う、ファイルを送る形式（multipart/form-data）のリクエストがないか |
| サーバーの応答の記録 | 異常に長い、または形のおかしいPHPSESSIDというクッキーを返していないか |
| エラーログ | メモリ不足のエラーや、HTTPの500エラーが急に増えていないか |
| PHPの動作の記録 | リクエストを処理する役のプログラム（ワーカー）が、予期せず止まったり再起動を繰り返したりしていないか |
調べ始める日は、公表日の21日ではなく、Amazonが最初の試みを観測した10月17日にするよう、Amazonは勧めています。JPCERT/CCも、攻撃の方法やログの設定によっては痕跡が残らないとして、痕跡が見つからないことは安全の証明にならないとしました。
侵入された疑いがあるときは、WordPress.orgの「My site was hacked」のページに、調べ方と立て直し方がまとめられています。
参考にした一次情報
- PHP「News Archive - 2026」（10月20日の予告、10月21日のセキュリティアドバイザリと修正版）
- The PHP Foundation「Today’s PHP security release and how we’re strengthening PHP security」
- GitHub Security Advisory「GHSA-w8hw-w9fx-j79w」（CVE-2026-109618）
- GitHub Security Advisory「GHSA-6wmf-4rv5-p3rp」（CVE-2026-109619）
- WordPress.org「Critical PHP security release」
- Wiz「PHP2Shell」
- CISA「Critical Vulnerabilities in PHP Require Immediate Patching」
- IPA「PHPの脆弱性に関する事前周知」
- IPA「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」
- JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」
- AWS Security Blog「Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot」
- 高市早苗首相のX投稿（2026年10月21日）
- さくらインターネット「緊急メンテナンス」
- ConoHa WING「ニュース」（「【重要】PHPの脆弱性への弊社対応完了のお知らせ（終報）」を含む）
- エックスサーバー「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」
- エックスサーバー公式のX投稿「メンテナンス状況について③」（2026年10月22日）
- エックスサーバー公式のX投稿「メンテナンス状況について④」（2026年10月22日）
- エックスサーバー公式のX投稿「メンテナンス状況について⑤」（2026年10月22日）
- たにぐち まこと氏のX投稿（2026年10月22日）
- ニコニコインフォ「ニコニコ メンテナンスのお知らせ（2026/10/21(水) 19:00〜）」
- Pokémon Sleep「メンテナンス終了のお知らせ」（2026年10月22日）
- Cloudflare「PHP vulnerabilities WAF protection」
- Matthew Prince氏のX投稿（2026年10月22日）
- なかじ（中島大介）氏のX投稿（2026年10月21日）
- 財務省「PHPの脆弱性対応に伴うWebサイト・一部コンテンツの一時停止のお知らせ」
- W3Techs「Usage statistics of PHP」
- W3Techs「Usage statistics of WordPress」