PHP2Shellはログイン不要で侵入される｜仕組みと対策を整理

2026年10月21日、Webサイトの多くを支えるプログラミング言語「PHP」に、認証なしでサーバーを操作される恐れのある重大な脆弱性が2件公表されました。首相がSNSで修正パッチの準備を呼びかけ、国内では銀行やゲーム、ECなどのサービスが予防的に停止する事態になりました。

一方で、「PHPはプログラミング言語なのに、言語そのものに脆弱性があるのはおかしいのでは？」と感じた方も多いのではないでしょうか。私も最初はそこが引っかかりました。

今回は、その疑問を出発点に、PHP2Shell（CVE-2026-109618／CVE-2026-109619）が何なのか、攻撃者はどうやってシステムに入るのか、そしてWordPressを運用している中小企業が何をすればよいのかを、公表情報をもとに順に整理します。

WordPressではなく、その下で動くPHPそのものを更新しないと防げない脆弱性です。

1. 「PHPの脆弱性」の多くは言語仕様ではなく、PHP本体のバグ

「PHPの脆弱性」と言うときの「PHP」は、多くの場合、言語仕様ではなくPHPを動かすインタプリタと付属ライブラリを指しています。PHPの本体（Zend Engine）や標準関数・拡張モジュールはC言語で書かれたプログラムなので、ほかのソフトウェアと同じようにバグがあり、それが脆弱性になります。

PHPに関係する脆弱性は、おおむね次のように分類できます。

今回のPHP2Shellは、表の1行目「インタプリタ本体のバグ」に当たります。言語の文法や仕様に欠陥があったわけではありません。

「PHPの脆弱性」と聞いたら、まず「PHP本体のプログラムのバグ」だと捉えると整理しやすくなります。

2. PHP2Shellは本体のメモリ管理バグ2件で、深刻度は最上位の「緊急」

PHP2Shellは、PHPのコアインタプリタにあるCVE-2026-109618とCVE-2026-109619の2件の総称で、どちらもCVSS v4.0で9.2と評価されています。認証なしの攻撃者が、影響を受けるWebサーバー上で遠隔からコードを実行できる可能性があります。

どちらもC言語で書かれたプログラムによくある、典型的なメモリ管理のバグです。PHP開発チームは日本時間10月21日23時ごろに修正版を公開しましたが、その前日には脆弱性の詳細が予定より早く外部に漏れていました。

今回の脆弱性は、OpenAIのAI（GPT-5.6 Sol）が発見したと発表されています。報道によれば、バグ自体は何年もPHPのコードに存在しており、OpenAIが資金を出した8月の監査でAIが実際に悪用可能であることを示したとのことです。攻撃にも防御にもAIが使われる時代になったことを示す事例と言えます。

3. 悪用されるとシステム停止では済まず、データを盗まれる恐れがある

PHP2Shellは「リモートコード実行（RCE）」と呼ばれる種類の脆弱性で、システムが止まるだけでなく、サーバーを操作されること自体が問題です。名前の「Shell」も、外部からサーバーを操作できる状態（シェル）を奪われることを意味しています。

コードを実行された場合、一般的に次のような被害が考えられます。

攻撃者が操作できる範囲は、基本的にPHPを動かしているユーザーの権限内です。共用レンタルサーバーであれば、そのアカウントのファイルやデータベースが主な被害範囲になります。

止まるだけなら復旧すれば済みますが、今回は顧客情報が抜かれる可能性があるので、放置できない種類の脆弱性です。

4. 「コード実行」はPHPのコードだけでなく、OSコマンドにも及ぶ

「コードを実行される」とは、攻撃者が用意した任意の処理を、サーバー上のPHPプロセスとして動かされることを指します。ただし、その範囲はPHPのコードだけにとどまりません。

ネイティブコードとは、CPUが直接理解して実行できる命令（機械語）のことです。PHPのコードは人間が読める文字で書かれ、インタプリタが解釈しながら実行します。一方、C言語で書かれたPHP本体はコンパイルされてネイティブコードとして動いています。

メモリ破壊系の脆弱性が危険なのは、PHP側の制限（disable_functionsによる関数の無効化など）が効かなくなる可能性があるためです。攻撃者がメモリの中身をうまく書き換えると、インタプリタの解釈を通さずに処理を実行させられる場合があります。

なお、今回の2件で攻撃者が具体的にどの形でコードを実行するのか、詳しい手口は私が確認した公開情報では明らかにされていません。上の表は、メモリ破壊系RCEの一般的な整理です。

5. 侵入はログイン画面を通らず、細工したHTTPリクエストから始まる

PHP2Shellによる攻撃は、予約システムやWordPressのログイン画面をまったく経由しません。ログインを突破するのではなく、その下で動いているPHP本体のバグを突くためです。

攻撃の流れは、次のとおりです。

1〜4は公表された脆弱性の内容に基づく流れで、報告されている攻撃の多くはPHPのセッションのアップロード進捗機能を経由しています。5〜7はコード実行に成功した後の典型的な流れで、今回もWebシェルの設置を狙った試み（失敗）が確認されています。

リクエストはプログラミング言語ではなく、HTTPで送られる

攻撃のリクエストは特別な言語で書かれたものではなく、ブラウザが普段使っているHTTPという通信の決まりに沿った文字の並びです。たとえば、通常のファイルアップロードは次のような形をしています（一般的な例で、攻撃コードではありません）。

POST /contact.php HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=----abc
Content-Length: 1234

------abc
Content-Disposition: form-data; name="file"; filename="photo.jpg"
（ファイルの中身）
------abc--

攻撃者はこの形式のまま、中身のデータの組み立て方や大きさを細工して送ります。見た目は普通のリクエストなので、送信元のツールがPythonでもcurlコマンドでも、サーバーに届くものは同じです。だからこそ、ボットで世界中のサーバーに一斉に送りつけることができます。

ログイン画面を通らない攻撃なので、パスワードを強くしても2要素認証を入れても、今回の脆弱性は防げません。

6. 攻撃の試みは数百万件、ただし成功した被害の全容はまだ不明

公表直後から攻撃の試みは急増し、Cloudflareのネットワーク全体で数百万件に達しました。同社によると、公表前の10時間は数千件でしたが、公表後45分で数万件、2時間以内に数十万件に跳ね上がりました。攻撃者はWAF（Webアプリケーションファイアウォール）の防御をすり抜けようと、送るデータを書き換えながら試していると報告されています。

攻撃は修正版の公開前から始まっていました。Amazonは、公表の4日前にあたる10月17日に、自社のハニーポット（攻撃観測用のおとりサーバー）で悪用の試みを観測したと発表しています。

一方で、攻撃が実際に成功した被害の規模は、10月23日時点ではまだはっきりしていません。セキュリティ企業watchTowrは、成功した攻撃はまだ観測していないとしており、観測された活動はスキャンや動作しない攻撃コードの利用にとどまっていたとする分析もあります。オランダのサイバーセキュリティ機関NCSC-NLは、悪用成功の初期兆候を調査中と発表しています。

国内では、株式会社バルテックが「PHPの脆弱性を標的としたサイバー攻撃」による顧客情報流出の可能性を公表しましたが、PHP2Shellによるものかは特定されていません。

大量に狙われているのは確かなので、「まだ被害報告が少ない」は対策を後回しにする理由になりません。

7. 対策はPHPの更新が最優先、WordPressの更新では防げない

欠陥はWordPressやプラグイン、テーマより下のPHP本体にあるため、WordPressを更新しても今回の脆弱性は防げません。WordPress.orgも、今回の件でWordPress側の更新は不要で、PHPの更新だけが修正になると説明しています。

特に注意が必要なのは、PHP 7系と8.1を使い続けているサイトです。修正版が出たのは8.2〜8.5だけで、7系と8.1には通常の修正版が提供されず、8.2も2026年12月末でサポートが終了します。古いバージョンのまま運用しているクライアントサイトがあれば、早めに移行計画を立てる必要があります。

すぐに更新できない場合の緩和策はありますが、完全な対策にはなりません。PHPの設定で session.upload_progress.enabled を 0 にすると、CVE-2026-109619の攻撃経路の1つを塞げると確認されています。ただしPHP開発チームは、完全な緩和策はなく、更新が唯一の安全な選択だとしています。

レンタルサーバーでは、事業者側ですでに対応済みのケースもあります。たとえばさくらインターネットは、10月23日の追記で、さくらのレンタルサーバで提供しているPHPに必要な修正を適用済みと発表しています。利用中の事業者のお知らせを確認し、自分で対応が必要かどうかを判断してください。

まずは自分のサイトのPHPバージョンと、サーバー会社のお知らせを確認するところから始めてください。

8. よくある質問

Q. WordPress本体やプラグインを最新にしていれば大丈夫ですか？

A. 大丈夫ではありません。今回の欠陥はWordPressより下のPHP本体にあるため、PHPそのものを修正版へ更新する必要があります。

Q. WAFを入れていれば防げますか？

A. WAFは攻撃の一部を止められますが、それだけでは不十分です。攻撃者はWAFをすり抜けるためにデータを書き換えながら攻撃を試していると報告されており、PHPの更新は必須です。

Q. AIのジェイルブレイク（脱獄プロンプト）と同じ種類の攻撃ですか？

A. 細工した入力でシステムに想定外の動作をさせる点は共通していますが、仕組みは異なります。ジェイルブレイクはAIの判断を言葉でだます攻撃で、プログラムのバグを突くものではありません。PHP2Shellはプログラムのメモリ管理バグを突く攻撃で、条件が揃えば確実に動作し、サーバーの操作権そのものを奪われる恐れがあります。

Q. レンタルサーバーを使っていれば、自分では何もしなくてよいですか？

A. 事業者によって異なります。サーバー側でPHPの修正を適用済みのケースもあれば、利用者がPHPバージョンを切り替える必要があるケースもあります。利用中の事業者のお知らせを必ず確認してください。

9. まとめ

今回の件は、WordPressやプラグインを最新にしていても、その下で動くPHPが古ければ守れないことをはっきり示しました。サイトの安全はアプリだけでなく、サーバー環境まで含めて管理する必要があります。

この機会に、管理しているすべてのサイトのPHPバージョンを一覧にして、サポート期限まで確認しておくと安心です。

参考リンク

• CISA：Critical Vulnerabilities in PHP Require Immediate Patching
• PHP（GitHub）：PHP 8.4.27 リリース
• 日経クロステック：PHPの重大な脆弱性で緊急メンテナンス相次ぐ　さくらやCygames、pixivなど
• INTERNET Watch：多くのサイトが予防的に公開停止、高市総理が対応呼びかけ―「PHPの深刻な脆弱性」対応で何が起きた？
• ITmedia NEWS：PHP「緊急」脆弱性悪用の試み、数百万件に　CloudflareのCEOが報告
• C3index：PHPの重大な脆弱性（2026年10月）への対応
• Huntress：Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities
• AWS Security Blog：Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
• SecurityWeek：PHP2Shell Exploitation Started Days Before Patches
• The Register：Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure
• SiliconANGLE：PHP2Shell attacks began four days before patches
• Brandefense：PHP2Shell: Fixed PHP Versions and Free Check
• Codeable：PHP Security Release on 21 October 2026: What WordPress Site Owners Need to Do
• さくらインターネット：【重要】PHPの脆弱性に関する当社の対応状況について
• note（zephel01）：PHPの緊急脆弱性2件、分かっていることと分かっていないこと

※記事内の情報は2026年10月23日時点の公開情報に基づいています。攻撃の試みの件数（数千件・数万件・数十万件・数百万件）は、Cloudflareが自社ネットワーク全体で観測した数値であり、インターネット全体の件数ではありません。また、試行件数は成功した被害件数とは異なります。
※「コード実行」の3つの形（PHPコード・OSコマンド・ネイティブコード）と「RCEで起こりうる主な被害」は、メモリ破壊系RCE全般についての一般的な説明です。今回の2件における具体的な攻撃手口は、確認した公開情報では詳しく示されていません。
※侵入の流れのうち、Webシェル設置以降はコード実行に成功した後の典型的な流れを示したもので、今回の攻撃で実際に確認された被害の流れではありません。