PHP2Shell：PHPコアで何が壊れ、何が起き、次に何をすべきか

先週、PHP2Shellのアドバイザリを読み込んで一番印象に残ったのは、CVSSスコアではなく攻撃の入り口の広さでした。ログインもアカウントも権限も要りません。WebサイトのURLを知っているだけで攻撃を始められます。しかも脆弱性があるのは WordPress でも Laravel でも自社のコードでもなく、PHPそのものです。

本記事では、PHP2Shellとは何か、何ができてしまうのか、実際にどんな被害が確認されているのか、そして開発チームが今週、そしてこの先数年で何をすべきかを、ノイズを除いて整理します。数字にはすべて出典を付けました。情報は2026年10月26日時点のものです。

PHP2Shellとは

PHP2Shellは、PHPエンジンにある2つの脆弱性、CVE-2026-109618（OOMによるメモリ破壊からのRCE）とCVE-2026-109619（古いグローバル状態の残存によるRCE）を指す通称です。どちらもCVSS 4.0 で 9.2（緊急）と評価されています。脆弱なコードは2012年リリースの PHP 5.4まで遡り、2026年10月21日に PHP 8.2.35・8.3.36・8.4.27・8.5.12 で修正されました。

2つのバグは、ほぼすべてのリクエストが通る「メモリ管理」と「エラー処理」にあります。かみ砕くと次のとおりです。

• CVE-2026-109618：リクエストが最悪のタイミングで memory_limit に達すると、PHPは内部のリクエストデータが作りかけのまま処理を中断します。その後に走る後始末の処理が、その不完全なデータを正しいものとして扱ってしまいます。アドバイザリによれば、このメモリ不足はリクエストボディだけで引き起こせ、アプリケーションのコードが動く前に起こり得ます。
• CVE-2026-109619：PHPのワーカーは複数のリクエストをまたいで動き続けます。致命的エラーで通常のリセットが中断されると、あるリクエストのメモリを指すグローバル状態が、そのメモリの解放後も残ることがあります。同じワーカーが処理する次のリクエストが、もう自分のものではないメモリを操作してしまう、典型的な use-after-free です（アドバイザリ）。

発見者の一つである Wiz Research は、経路の一つでワーカーのメモリがクライアントに返ってしまうことも示しました。そこには他のユーザーのリクエストに含まれるパスワード、セッショントークン、APIキー、証明書が含まれる可能性があります。これは後で「修正済み」の意味を考えるときに重要になります。

「すべてのPHPサイト」が対象である理由と、mod_php が最も危険な理由

欠陥はエンジンにあるため、その上で動くアプリケーションは関係ありません。Wiz は WordPress・Drupal・Joomla の標準コンテナイメージで実証し、影響を受けるPHP上なら「Hello World」アプリでさえ脆弱になり得るとしています。Apache か Nginx かも関係ありません。重要なのは、PHPがWebサーバーにどう接続されているか（SAPI）です。

私が mod_php を最も危険だと考えるのはこのためです。PHPはApacheのプロセスの中で動いています。PHPを乗っ取られれば、Webサーバーとしてコードが実行され、そのプロセスが触れるすべてのサイトと秘密情報に手が届きます。FPMなら、少なくともプロセスの境界と、分離できるプールがあります。

「リクエスト1回で乗っ取れる」は正確ではない

初期の報道では、リクエスト1回でサーバーを奪えると言われました。アドバイザリの記述はもっと正確で、その違いは防御側にとって役に立ちます。認証が不要なのは事実です。しかし確認された攻撃は、同じPHPワーカーに届く複数のリクエストを連鎖させるもので、成功率はPHPのビルド、拡張機能、メモリ配置に左右されます。Sansec は10月22日、公開された概念実証コードが既定のPHP環境では動作しなかったと報告し、VulnCheck も公開コードのいずれも単体では x86-64 の ASLR を突破できないとしています。

だからといって安心してよいわけではありません。Wiz と Calif は動作するエクスプロイトを持っており、バグは本物で、攻撃者も研究者と同じAIツールを使えます。パニックにならず、落ち着いてパッチを当て、きちんと調査すべきだということです。

攻撃者が得るもの

• Webワーカー権限でのコード実行。設定ファイルのDB認証情報の読み取り、ユーザーデータの窃取、後で使うWebシェルの設置、サイトの改ざんなどにつながります。NSAは、こうした欠陥が「サーバーのファイルシステムやデータベースへの直接の経路になることが多い」と警告しています。
• 完全なRCEがなくても、メモリ上の秘密情報。メモリ漏えいの経路では、他のユーザーのリクエストのデータ（セッショントークン、パスワード、APIキー）が露出し得ます。
• 安価な攻撃インフラ。侵害されたサーバーは暗号資産のマイニング、プロキシ、DDoSの踏み台になります。Sophos が最初に捕捉したペイロードは、DDoS用のMirai系ボットネット「Potassium」でした。
• Webサイトだけでなくアプライアンスも。PHPは、それを表に出さない製品の中でも動いています。Palo Alto Networks はPAN-OS と Panorama の管理インターフェースが影響を受けることを確認し、Cisco も Expressway と Duo Access Gateway を挙げています。

これまでに確認された被害

ここは慎重に書きたいところです。「インターネットの70%」は見出しとしては強力ですが、被害の見積もりとしては不正確です。実際に測定されたものは次のとおりです。

これまでで最も目に見えるコストは、データ窃取ではなく予防的なサイト停止です。NSA、英国NCSC、CERT-EUの助言を受け、フィンランドは政府の公開Webサービスを一時停止し、オランダの政府機関や下院、Wikimediaの一部もオフラインになりました（BBC）。エディンバラ、ブリストル、オックスフォードの自治体サイトやパリ警視庁のサイトも停止しました（The Guardian）。日本では高市早苗総理がXで当夜中の対応を呼びかけ、国家サイバー統括室も、修正をすぐに適用できない場合はサイトの一時停止がリスク低減の有効策の一つだと発信しました（INTERNET Watch）。

確認された侵入について正直に言えば、公開されている証拠はまだ少ないのが現状です。watchTowr は自社のハニーポットで両CVEの悪用を観測しましたが、Sophos は侵害成功の初期報告を撤回し、10月22日時点で侵害成功の証拠はないとしています。ただし注意点が2つあります。Amazon のハニーポットは10月17日に攻撃を受けており、侵害がアドバイザリより前に起きている可能性があります。また JPCERT/CC は、攻撃経路によってはログに痕跡が残らない場合があると警告しています。「被害報告がない」ことは「被害がない」ことを意味しません。

最も怖かったのは情報漏えいの速さ

私が PHP2Shell で一番恐ろしいと感じたのは、バグそのものより、情報が外に漏れた速さです。協調的な情報公開は公開予定日の2日前までは機能していました。ところが10月20日 15:00 UTC 頃、CVE番号がネット上で出回り始めます。PHPはリリースを1日前倒ししました。数時間後、報告者の一社が誤って概念実証の動画を公開しました。10月21日の朝には、事前にパッチを受け取っていたベンダーが6時間以上早く修正版ビルドを公開し、誰でも修正差分を解析できる状態になりました（PHP Foundation、タイムライン）。

Amazon の結論は、すべてのセキュリティ責任者が心に留めておくべきものです。「AIによる解析で、パッチの差分やアドバイザリを動作するエクスプロイトに変えるコストが下がった」。7日や30日というパッチのSLAは、もはや存在しない猶予を前提にしています。

今すぐやるべきこと

1. パッチを当て、本当に効いているか確かめる

PHP 8.5.12、8.4.27、8.3.36、8.2.35へ更新してください。7.4・8.0・8.1は公式ビルドがなくソースのバックポートのみなので、保守されているパッケージを使います（Debian/Ubuntu なら Ondřej Surý 氏のリポジトリ、RHEL系なら Remi のリポジトリ、Ubuntu Pro、CloudLinux、TuxCare、Zend など。一覧は Sansec）。7.3以前には修正が一切ありません。アップグレードしてください。

よく見かける落とし穴は2つです。Webを処理しているPHPではなくCLIのバージョンを確認してしまうこと、そしてワーカーの再起動を忘れることです。

# 1. The version that actually serves web requests (the CLI can differ)
#    Put a temporary phpinfo() page behind auth, or check the FPM binary:
php-fpm8.3 -v            # adjust to your version
apachectl -M | grep php  # is mod_php loaded at all?

# 2. Distribution packages keep the old version number after a backport,
#    so look for the CVE in the changelog instead
zgrep CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz   # Debian/Ubuntu
rpm -q --changelog php-common | grep CVE-2026-109618                     # RHEL/Alma/Rocky

# 3. Restart every worker, or the old code keeps running in memory
sudo systemctl restart php8.3-fpm   # or: sudo systemctl restart apache2

2. 今日中にパッチを当てられない場合

PHPチームは、更新だけが完全な対策だと明言しています。暫定策は時間を稼ぐだけです。

• サイトをWAFの背後に置く。Cloudflare は、無料・有料のWAF利用者が10月21日 03:02 UTC から既定で保護されているとしています（PHPの既定のアップロード進捗フィールド名を使っている場合）。
• セッションのアップロード進捗機能を無効化し、PHP 8.5 では致命的エラーのバックトレースも無効化する。それぞれ実証された経路を一つずつ塞ぎますが、すべてではありません。
• リバースプロキシでリクエストサイズ、multipart のパート数、ネストの深さを制限する。アップロードを受け付けないアプリなら、multipart リクエストを入口で拒否する。
• どれもできず、機密データを扱うサイトであれば、NCSCの助言どおり、修正まで公開を停止する。

; Temporary, partial stopgap from the PHP advisories. Patching is the only fix.
; PHP-FPM reads its pool config, not the CLI php.ini:
; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 only:
php_admin_flag[fatal_error_backtraces] = off

3. 10月17日まで遡って侵害を調査する

パッチは扉を閉めるだけで、その前に誰かが入ったかどうかは教えてくれません。出発点としては JPCERT/CC の3つの確認項目が有用です。過去のレスポンスに不自然に長い、または異常な形式の PHPSESSID Cookie がないか。不審な multipart/form-data リクエストの前後にメモリ上限エラーやHTTP 500が出ていないか。PHPワーカーが予期せず異常終了・再起動していないか。これに、Webサーバーからのシェル起動、Webルート内の見覚えのないPHPファイル、新しい cron ジョブ、説明のつかない外部通信といった、侵害後の一般的なチェックを加えます。

何も見つからなくても、公開されていたホストの秘密情報はローテーションしてください。メモリが漏れる経路があるため、パッチ適用済みのサーバーでも、適用前にDBパスワード、APIキー、セッション署名鍵が漏れていた可能性があります。パッチは漏れた情報を取り戻してはくれません。

長期的な対策

私は Facebook に「根本的な解決策はなく、あるのは防御と被害の最小化だけだ」と書きました。今回の調査を経て、それを具体的な5つの施策にまとめます。

1. どこでPHPが動いているかを把握する。Forescout の Sai Molige 氏の言葉が的確です。「Xがどこで動いているかをどれだけ早く特定できるか」を、パッチの速さとは別に測る能力として扱うこと。アプライアンス、コントロールパネル、ベンダー製品の中のPHPも含みます。
2. 更新を自動化し、パッチの猶予を「時間」単位にする。ディストリビューションのパッケージは自動でセキュリティ更新、ベースイメージはパイプラインで再ビルド・再デプロイ、緊急時の手順書は事前に訓練しておく。Amazon は重大な脆弱性のパッチ期限を時間単位で測るよう勧めています。
3. mod_php とサポート終了版から離れる。サイトごとに1プール、プールごとに別ユーザーの PHP-FPM と、サポート中のPHPブランチへ移行する。W3Techs によればPHPサイトの34.5%がまだバージョン7以前で、いずれもPHPの公式リリースはもう提供されていません。
4. Web層は侵害される前提で設計する。ワーカーは最小権限で動かし、不要な外向き通信を遮断し、秘密情報をWebルートの外に置き、社内システムからネットワークを分離する。挙動はリアルタイムで監視する（どのCVEであれ、Webサーバーが sh を起動したら不審です）。最初の悪用はシグネチャができる前に来ることが多いからです。
5. 攻撃者より先に、自分のコードにAIを使う。PHPプロジェクト自身も、Anthropic の Claude Mythos や OpenAI のツールでコードをスキャンしています。各チームも同じ種類のAIレビューを、自社コードと依存関係に対してCIに組み込めます。

より大きな視点：AIは攻撃のコストを下げた

PHP2Shell のバグは、目の前にありながら見過ごされてきました。PHPの開発者は2024年の監査で最初の兆候に気づいていましたが、現実的な攻撃方法を示せる人はおらず、修正方針の合意もできず、作業は何か月も停滞しました。PHP Foundation 自身がこれを構造的な失敗と認めています。2026年に変わったのはツールです。Wiz は、フロンティアモデルを使うことで「研究者1人が1週間で、以前なら世界トップクラスのチームが数か月かけていた作業を終えた」と書いています。

PHP2Shell は単独の出来事ではありません。同じ日に Node.js は、同梱する Brotli デコーダの境界外書き込みでリモートコード実行につながり得るCVE-2026-111497を修正しました。報告者は OpenAI の Codex Security チームです。PHPのセキュリティチームは、AIで報告量が増えるなか、7月1日以降に15件のCVEを公開し、100件を超える無効な報告を処理したとしています。私の見立てでは、信頼できない入力の近くにあるメモリ安全でないコンポーネント（言語ランタイム、圧縮・画像ライブラリ、Webサーバー、機器のファームウェア）は、どれも同じ圧力にさらされます。かつて「悪用は難しすぎる」と片付けられた古いバグが、再び現実の脅威になります。

Facebook の投稿では、機密性の高いシステムはインターネットから隔離されていてPHPも使わないので、被害はおそらく経済的なものにとどまるとも書きました。大筋では今もそう考えています。ただ PHP2Shell は、その境界が見た目より薄いことも示しました。機密ネットワークを守るファイアウォールの管理画面の中でもPHPは動いています。最も弱い環は、最も強いはずだと思って買った機器であることが多いのです。

私の結論。バグの発見と兵器化がますます安くなる世界に、恒久的な解決策はありません。あるのは、より速いループだけです。何を動かしているかを把握し、時間単位でパッチを当て、侵害を前提に設計し、リアルタイムで監視し、攻撃者が使うのと同じAIを先に自分のコードに使うこと。