PHP2Shell は、プログラミング言語 PHP の本体（エンジン）に見つかった2つの重大な脆弱性、CVE-2026-109618 と CVE-2026-109619 の通称です。どちらも、ログインなしの外部からサーバー上で任意のコードを実行できる遠隔コード実行（RCE）で、深刻度は10段階中9.2（CVSS v4.0）と評価されています。問題は PHP のエンジンそのものにあるため、アプリ側のコードがどれだけ堅牢でも防げません。影響範囲は、Web リクエストを処理するほぼすべての PHP（2012年の 5.4 以降）に及びます。PHP 開発チームは2026年10月21日に修正版を公開しましたが、公開前の10月17日には実際の攻撃も観測されています。本記事では、何が起きたのか、自社が影響を受けるかの確認方法、そして最優先でやるべき更新と暫定策を扱います。
結論から書きます。やるべきことは一つ、PHP を修正版へ今すぐ更新することです。アプリの設定や認証では防げません。LOCKED は PHP を修正する製品ではありませんが、万一サーバーが侵害されたときに被害を広げないためのアカウントと権限の管理を担います。更新を最優先にしたうえで、その後の守りの点検にお使いください。
無料で製品資料をお送りしています。侵害後の被害を抑えるアカウント管理の見直しにお使いください。 製品資料をダウンロードする →
PHP2Shellとは、PHPエンジン自体に見つかった2つの重大RCE
多くの Web サイトは、裏側で PHP というプログラムがリクエストを処理しています。調査会社 W3Techs によれば、サーバー側の言語が判明している Web サイトの約69%が PHP を使っています。その土台に、2つの穴が同時に見つかりました。
CVE-2026-109618 は、メモリ不足（OOM）の処理に起因する破損です。リクエストの処理中にメモリ上限を超えて中断されると、本来は無効になったはずのデータが、後続の処理で有効なものとして扱われてしまいます。この穴には、解放済みのメモリの中身が外部に漏れる「メモリ情報漏えい」の副作用もあります。漏れる中身には、パスワード、セッション情報、API キー、TLS の秘密鍵などが含まれ得ます。かつて世界中を騒がせた Heartbleed に例えられています。
CVE-2026-109619 は、解放済みメモリを後から使ってしまう use-after-free と呼ばれる種類の穴です。あるリクエストの処理で残った古い状態が、同じワーカーが処理する次のリクエストに影響し、遠隔コード実行につながります。
この2つを連鎖させると、認証を突破することなくサーバーを乗っ取れます。2026年3月のaxiosのサプライチェーン攻撃が特定のライブラリの問題だったのに対し、今回は PHP という土台そのものの問題であり、影響範囲が桁違いに広いのが特徴です。
ゼロトラスト実装の現実
ゼロトラストの理想と現実のギャップを分析。段階的な実装アプローチと、ID管理・デバイス管理から始める現実的なロードマップを提示します。
なぜ怖いのか：未認証・アプリ側で防げない・ほぼ全PHPが対象
この脆弱性が「2026年で最大級」と言われるのは、3つの条件が重なっているからです。
第一に、未認証で成立します。攻撃者はアカウントを持つ必要がありません。ログイン画面の手前で、1つのリクエストを送るだけで引き金を引けます。
第二に、アプリ側では防げません。PHP は、アプリのコードが動く前にリクエストを解析します。穴はその解析段階にあるため、アプリの認証やメンテナンスモードは素通りされます。WordPress や Magento のような完成度の高いアプリでも、PHP が脆弱なら影響を受けます。
第三に、対象がほぼすべての PHP 環境です。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed のいずれも影響を受け、とくに mod_php 構成の危険度が高いとされています。脆弱なコードは2012年公開の PHP 5.4 までさかのぼり、既定の設定のままで脆弱です。
実際の悪用も始まっています。Amazon の脅威情報チームは、一般公開の4日前にあたる10月17日、自社のおとりシステムで PHP2Shell の攻撃を観測したと報告しました。修正版公開の当日10月21日には、Cloudflare が公開前の早朝から攻撃を観測しています。インターネットに露出した PHP サーバーは130万〜190万台規模との推計もあり、今後の無差別な悪用が警戒されています。
まず確認：自社が影響を受けるか
自社に PHP を使うシステムがあるなら、まずバージョンを確認します。サーバーで php -v を実行するか、アプリの管理画面やバージョン情報から確認できます。Web サーバー経由とコマンドライン（CLI）でバージョンが違う場合があるので、実際に Web リクエストを処理している PHP を確認してください。
見落としやすいのが、自分で意識していない PHP です。社内のグループウェア、古い業務アプリ、ベンダーに任せた受託システム、ネットワーク機器の管理画面など、PHP が組み込まれている場所は多岐にわたります。どこに PHP があるかを把握できていない場合は、ソフトウェア部品表（SBOM）で構成を棚卸しし、ソフトウェア構成解析（SCA）で脆弱なバージョンを洗い出すのが近道です。「どこで何のバージョンの PHP が動いているか」を即答できる状態が、こうした一斉対応のときに効きます。
自社システムに潜む PHP の棚卸しから、無料でご相談を承っています。 デモ・個別相談を申し込む →
対策は「今すぐPHPを更新」。それが唯一の完全な修正
設定変更による回避策はありますが、後述するとおり完全ではありません。確実に塞ぐ唯一の方法は、PHP を修正版へ更新することです。2026年10月21日に公開された修正版は次のとおりです。
| 使用中のバージョン | 更新先 |
|---|---|
| PHP 8.5.x | 8.5.12 |
| PHP 8.4.x | 8.4.27 |
| PHP 8.3.x | 8.3.36 |
| PHP 8.2.x | 8.2.35 |
| PHP 7.4 / 8.0 / 8.1 | 公式リリースなし。PHP 開発チームが最小限のソース修正（バックポート）を公開 |
| PHP 5.4〜7.3 | サポート終了。修正なし。サポート対象への移行が必要 |
Linux ディストリビューションや LTS を提供するベンダーには、公開に先立って修正が渡されています。ディストリビューションのパッケージで運用している場合は、OS ベンダーの更新を適用してください。サーバーを自社で管理していない場合は、ホスティング事業者に更新状況を確認します。英国の国家サイバーセキュリティセンター（NCSC）は、すぐに修正できないシステムは一時的にオフラインにすることも検討するよう呼びかけています。
すぐ更新できないときの暫定策（完全ではない）
即時の更新が難しい場合に、公開されている暫定策を挙げます。いずれも露出を減らすだけで、安全にするものではありません。更新できたら元に戻してください。
- Web サーバー側で multipart/form-data のリクエストを遮断する — 既知の引き金はファイルアップロード形式のリクエストです。nginx や Apache で弾けますが、ファイルアップロードやカート・決済の一部が動かなくなるため、適用後に動作を確認してください。
- サービスを停止または読み取り専用にする — PHP-FPM を止めて静的なメンテナンス画面を出す、あるいは GET と HEAD 以外のリクエストを拒否して閲覧だけ許す、といった形です。更新までの時間稼ぎになります。
- PHP の設定で一部を無効化する — CVE-2026-109618 向けにメモリ上限の扱いを変える、CVE-2026-109619 向けにセッションのアップロード進捗機能を無効化する（PHP 8.5 では加えてエラー時のバックトレースを無効化する）、といった設定が案内されています。変更後は全ワーカーの再起動が必要で、単独では不十分とされているため、他の策と組み合わせます。
- WAF で既知の攻撃を弾く — Cloudflare は既知の経路向けの WAF ルールを提供しています。ただし自社を経由する通信にしか効かない時間稼ぎであり、更新の代わりにはなりません。
欧州の CERT-EU も、すぐ更新できない組織に対し、インターネットに面したアプリを公開ネットワークから隔離するよう勧めています。
侵害された後に備える：権限の最小化とアカウント衛生
PHP2Shell は PHP を更新すれば塞げます。ただし、更新前に侵入されていた可能性や、メモリ情報漏えいで認証情報が抜かれた可能性は、更新だけでは消えません。公開前から攻撃が観測されていた以上、「すでに入られていたかもしれない」前提での点検が要ります。
遠隔コード実行で入り込んだ攻撃者が次に狙うのは、たいてい他のシステムへの横展開と、認証情報の窃取です。ここで被害の広がりを左右するのが、アカウントと権限の設計です。サーバーが1台乗っ取られても、そのアカウントに余計な権限が付いていなければ、他システムへの横展開は食い止めやすくなります。ただし、そのサーバーが正規に扱えるデータや認証情報（データベースの接続情報、API キーなど）は、権限を絞っていても攻撃者の手に渡り得ます。被害は「そこで止まる」のではなく「そこに限定される」であり、侵害が疑われるなら、そのサーバーが扱う認証情報の洗い出しと再発行まで必要です。逆に、強い権限を使い回していれば、1台の侵害が全体へ一気に広がります。
LOCKED DAS は、アカウントの権限を必要な範囲に絞り、退職者や不要なアカウントを確実に止めるので、1台の侵害が他システムへ横展開する範囲を小さく抑えます。LOCKED MSO の多要素認証は、盗まれたパスワードによる不正ログインを止めます。ただし、メモリ情報漏えいで盗まれ得るのはパスワードだけでなくセッション情報も含まれるため、侵害が疑われるなら、パスワードの変更に加えてセッションの無効化や鍵の再発行まで行うのが安全です。更新で穴を塞ぎ、権限とアカウントで被害を限定する。この二段構えが、土台が揺れたときの守り方です。
なお、インシデント対応の手順そのものはインシデント対応プロセスの構築で扱っています。発覚から封じ込め、調査、復旧までの流れを、平時に決めておいてください。
侵害を前提にした権限設計とアカウント管理を、無料でご相談いただけます。 資料請求・デモ依頼はこちら →
参考資料
- PHP公式：ダウンロード（最新版の入手）
- JPCERT/CC：注意喚起・脆弱性情報
- IPA：重要なセキュリティ情報
- Sansec：PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)
- Tenable：php2shell (CVE-2026-109618, CVE-2026-109619) FAQ