この記事の要点
- PHP2Shell は、世界中の Web サイトを動かす言語「PHP」そのものに見つかった、きわめて危険な 2 つの欠陥（CVE-2026-109618 / CVE-2026-109619）の通称です。
- 攻撃者は、ログインも利用者のクリックも必要とせず、Web サーバーにリクエストを送るだけで、最悪の場合サーバーを乗っ取れます。
- 公開予定より前に技術情報が漏れ、修正版が出る前に出回ったことで、大きな騒ぎになりました。
- 対策はただ一つ、PHP を修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）に上げることです。「設定変更だけでは塞げない」と PHP 公式が明言しています。
- PHP 5 系・7 系には公式の修正がありません。古いサーバーを使い続けている場合は特に危険です。
2026 年 10 月、Web エンジニアやサーバー管理者の間で「PHP2Shell」という言葉が一気に広まりました。ニュースによっては「10 点満点中 10 点の危険度」といった見出しも並び、ふだんセキュリティの話題を追っていない方にも届いたと思います。
この記事では、プログラミングやサーバーに詳しくない方でも流れがつかめるように、そもそも何が起きたのか → なぜここまで騒ぎになったのか → 中身はどういう仕組みなのか の順で、たとえ話と図を使ってやさしく解説します。悪用につながる具体的な手順は載せません。
PHP2Shell とは何か（まず結論）
「PHP2Shell」は、PHP という言語の本体（エンジン）に見つかった 2 つの深刻な脆弱性につけられた通称です。名前は「PHP から Shell（＝サーバー上でコマンドを実行する状態）まで到達できてしまう」という意味合いです。なお、この呼び名は報道や研究者が使っているもので、PHP 公式の告知文には出てきません。
正式には、次の 2 つの CVE（脆弱性に付けられる世界共通の整理番号）を指します。
| 整理番号 | 通称での呼ばれ方 | ざっくり言うと |
|---|---|---|
| CVE-2026-109618 | OOM corruption（メモリ不足による破損） | メモリを使い切ったときの後片付けが中途半端になる |
| CVE-2026-109619 | stale global state（残ってしまった古い状態） | 前の処理の「古いメモ」を次の処理が使ってしまう |
どちらも最終的には RCE（リモートコード実行） につながり得ます。RCE とは、外部の第三者が、あなたのサーバーの上で好きなプログラムやコマンドを動かせてしまう、という最も重い部類の被害です。ファイルを盗む、改ざんする、他への攻撃の踏み台にする――何でもできてしまいます。
そもそも PHP とは（超入門）
PHP は、Web サイトの「裏側」で動くプログラミング言語です。ブラウザからページを開くと、サーバー上で PHP が動いて、データベースから記事を取り出したり、お問い合わせフォームの内容を受け取ったりして、表示する HTML を組み立てます。
PHP が重要なのは、使われている量が桁違いに多いからです。
- W3Techs の調査では、サーバー側の言語が判明している Web サイトのうち、4 分の 3 ほどが PHP を使っているとされます。
- 世界の Web サイトの 4 割前後を占めると言われる WordPress も、中身は PHP で動いています。
つまり、PHP 本体に穴が空くということは、世界中の膨大な数のサイトが、同時に同じ穴を抱えることを意味します。ここが今回の騒ぎの出発点です。
なぜここまで騒ぎになったのか
理由は大きく 5 つあります。
1. 対象があまりに広い
前述のとおり、PHP は Web の裏側で最も広く使われている言語です。特定のソフトの、特定の設定だけが危ない、という話ではなく「PHP で動く Web サーバー全般」が対象になり得ました。PHP 公式も、影響範囲を「Web リクエストを処理するすべての PHP 環境」と表現しています。
2. ログインも操作も要らない
多くの攻撃は「利用者がだまされて怪しいリンクを踏む」「IDとパスワードを盗む」といった前段を必要とします。ところが今回は、攻撃者がサーバーに特殊なリクエストを送るだけで成立し得ます。ログイン不要・利用者の操作不要。これは危険度を押し上げる大きな要素です。
3. 修正版が出る前に、情報が漏れた
PHP は 10 月 20 日に「翌 21 日に重大な修正をリリースします」と予告していました。ところが、その公開予定日より前に技術的な詳細が漏れて出回ってしまったと報じられています。守る側（管理者）がまだ更新できない状態で、攻める側に手がかりが渡ってしまったわけです。この「順番の逆転」が、警戒を一気に強めました。
4. 古い PHP は見捨てられた
修正版は新しい世代（8.2 系以降）にしか出ていません。すでにサポートの終わった PHP 5 系・7 系には、公式の修正がありません。「古いから大丈夫だろう」ではなく「古いからこそ、ふさがらない」状態です。古いサーバーを放置している現場ほど危険、という逆転が起きています。
5. 評価の高さ（と、食い違い）
危険度の指標 CVSS で、PHP 公式は 9.2（最大 10） と評価しました。一方、一部のセキュリティ企業は「10.0（満点）」と報じ、見出しとして広がりました。これについて PHP 側は「10.0 は誤り」としています。満点かどうかはさておき、9.2 でも十分に『今すぐ対応すべき』レベルである点は変わりません。
時系列のまとめ
| 日付（2026 年） | 出来事 |
|---|---|
| 10 月 20 日 | PHP が「翌日に重大な修正を出す」と予告。この前後で詳細が漏れ始めたと報道 |
| 10 月 21 日 | 修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）を公開。公式告知と技術勧告も同時公開 |
| 10 月下旬 | 悪用が始まったとする報告が出る一方、被害の全容はまだはっきりしない、とも報じられている |
脆弱性の中身を、たとえ話で
ここからが本題です。難しい用語を使わずに、何が起きているのかをイメージでつかみましょう。
まず「メモリ」と「ワーカー」のイメージ
PHP がリクエストを処理するとき、作業台（メモリ）の上に材料を広げて料理をするようなことをしています。そして、その料理を担当するのが ワーカー（係員） です。
1 人のワーカーは、お客さん（リクエスト）を次々とさばきます。普通は、1 人終わるたびに作業台をきれいに片付けてから、次のお客さんに取りかかります。
今回の 2 つの脆弱性は、どちらもこの「片付け」がうまくいかないすき間を突くものです。
1 つ目：後片付けが途中で止まる（CVE-2026-109618）
PHP には「作業台をここまで広げたら、それ以上は使わない」という上限（memory_limit）があります。攻撃者は、わざと大量の材料を一度に送りつけ、作業台を限界まで埋め尽くします（これを OOM＝メモリ不足と言います）。
問題は、ちょうどその「あと少しで埋まりきる」瞬間に、PHP が材料を並べ終える前に力尽きてしまうことです。すると、並べかけ・片付けかけの中途半端な状態が残ります。本来なら「これは失敗」と捨てられるべきなのに、後片付けの処理が、その壊れたデータを「ちゃんとしたデータ」として扱ってしまう――これが 1 つ目のバグです。
専門用語では「解放したはずのメモリを、まだ使えるものとして触ってしまう（use-after-free）」という種類の不具合です。この「すき間」が、後の乗っ取りの足がかりになります。
2 つ目：前のお客さんの「古いメモ」を使い回す（CVE-2026-109619）
先ほど、ワーカーは 1 人で次々にお客さんをさばく、と説明しました。2 つ目のバグは、ここに関わります。
PHP には、ファイルのアップロード状況を記録する機能（session.upload_progress、初期設定でオン）などがあります。この処理で作ったメモを、本来はお客さん 1 人が終わるたびに消すべきなのに、消したつもりで作業台の隅に残ってしまうことがあります。
次のお客さん（リクエスト）が来たとき、ワーカーはまっさらな状態から始めるべきなのに、前の人の古いメモを、自分のものだと思い込んで使ってしまう。攻撃者は、この「残ったメモ」に自分の都合のよい内容を仕込んでおくことができます。これが 2 つ目のバグです。
「乗っ取り」まではどうつながるのか
ここが一番気になるところだと思います。先に答えを言うと、1 回のリクエストで即・乗っ取り、ではありません。
攻撃者は、上の「すき間」や「使い回されたメモ」を手がかりに、
- まず、サーバーのメモリの中身を少しずつのぞき見て（情報漏えい）、
- PHP が自分の内部で使っている部品がどこに置かれているかを推測し、
- 最終的に、PHP が「自分の部品」だと思って呼び出す場所を、攻撃者のデータにすり替える、
という手順を、注意深く何度もリクエストを重ねて成立させる、と研究者は報告しています。根っこにあるのは「PHP が自分用に確保したはずのメモリの場所を、外から来たデータにすり替えられる」という一点です。本記事では、これ以上の具体的な手順・コードは扱いません。
なお、どの環境でも必ず成立するわけではなく、サーバーの構成（特に Apache の mod_php 構成が最もリスクが高いとされます）や設定によって成立しやすさは変わります。ただし「うちは条件に当てはまらないはず」という思い込みに頼るのは危険で、更新してふさぐのが唯一の確実な対策です。
自分のサイトは大丈夫？――確認のしかた
まず、使っている PHP のバージョンを確かめます。
- レンタルサーバーの場合：管理画面（コントロールパネル）に PHP のバージョン表示・切り替えの項目があります。エックスサーバー・さくらのレンタルサーバー・ロリポップ・ConoHa・mixhost など主要各社は、今回の対応状況をお知らせで公表しています。まずは契約先のお知らせを確認してください。
- 自分で管理しているサーバーの場合：
php -vで表示されます。ただしこれは「コマンドライン版」の結果で、実際に Web サイトを動かしている PHP とは別のことがあります。phpinfo()を出力するページや、Web サーバーの設定でも確認してください。
ひとつ注意点があります。Ubuntu・Debian・AlmaLinux などの OS では、バージョン番号を変えずに修正だけを取り込む（バックポート）ことがよくあります。番号が「8.3.31」のように修正版より小さく見えても、実は修正済み、というケースです。この場合は apt や rpm の更新履歴（changelog）に CVE 番号（CVE-2026-109618 / 109619）が載っているかで判断します。
やるべきこと（対策）
- 最優先は、修正版への更新です。 PHP 公式は「更新だけが完全な対策であり、設定変更では一部の経路を減らせるだけで安全にはならない」と明言しています。レンタルサーバーなら管理画面でバージョンを上げる、自前サーバーなら OS の更新を適用します。
- すぐに更新できない場合の緩和策（あくまで時間稼ぎ）：アップロード進捗機能（
session.upload_progress.enabled）を切る、リクエストのサイズ・項目数・入れ子の深さに上限を設ける、WAF（Web アプリケーションファイアウォール）を入れる、などが公式・各社から案内されています。PHP 8.5 ではfatal_error_backtracesを切る案内もあります。ただしこれだけでは塞ぎきれません。 - 古い PHP（5 系・7 系）を使っている場合は、公式修正がありません。サポート対象のバージョンへ上げる計画を、この機会に立ててください。
- 心配なときは、侵入の痕跡がないか（繰り返される不審なアクセス、極端に大きなリクエスト、身に覚えのないファイルなど）をログで点検します。
まとめ
- PHP2Shell は、Web の裏側で最も広く使われている PHP 本体の、2 つの深刻な脆弱性の通称です。
- ログインも操作も不要で、放置すればサーバー乗っ取りにつながり得ます。だからこそ短期間で大きな話題になりました。
- 仕組みは「メモリの後片付けのすき間」と「古い状態の使い回し」。入口は違いますが、どちらも最後はメモリの取り違えに行き着きます。
- 対策は明快で、PHP を修正版に上げること。設定変更は時間稼ぎにしかなりません。
当社では、お客様からお預かりしているサーバーやシステムの PHP バージョンを確認し、更新・緩和策・ログ点検までを含めて対応を進めています。「自社のサイトが対象か分からない」「古い PHP で動いていて不安」「更新で動かなくならないか心配」といったご相談にも対応します。サーバーの運用・保守やシステムの引き継ぎでお困りの際は、お気軽にご相談ください。
参考
- PHP 公式: Security advisory: Critical remote code execution vulnerabilities, update now（2026 年 10 月 21 日）
- GitHub Security Advisory: GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
- GitHub Security Advisory: GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- 報道: The Hacker News ／ SecurityWeek