概要
2026年10月21日、PHP本体に存在する2件の重大な脆弱性が公表され、修正版が公開された。
この脆弱性は「PHP2Shell」と呼ばれ、外部から送信されたHTTPリクエストを処理する際に、PHP内部のメモリ管理に問題が発生するもの。
条件がそろうと、攻撃者が認証を受けずにサーバー上で任意のコードを実行できる可能性がある。
重要なのは、LaravelやWordPressなどのアプリケーション自体に問題がなくても攻撃が成立する可能性があるという点である。
通常のHTTPリクエスト処理
一般的なLaravelアプリケーションでは、次の順序で処理が実行される。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
[外部クライアント] | | HTTPリクエスト v [Apache / Nginx] | v [PHP実行環境] | v [Laravel] | +-- ルーティング | +-- 認証・認可 | +-- Controller | +-- DBアクセス | v [HTTPレスポンス] |
通常、Laravelではルーティングで定義された処理が実行され、必要に応じて認証・認可が行われる。
したがって、HTTPリクエストを送信しただけで、任意のPHPコードを実行できるわけではない。
今回の脆弱性は何が違うのか
今回の問題はLaravelのルーティングや認証処理ではなく、PHP本体の内部処理に存在する。
PHPはHTTPリクエストを処理するために、物理メモリ(RAM)を利用している。
例えば、次のような情報がメモリ上に配置される。
- HTTPリクエストの情報
- PHPの変数や配列
- セッション関連の内部情報
- PHPエンジンの管理データ
- 関数呼び出しに必要な内部情報
今回の脆弱性では、これらのメモリを管理する処理に不具合がある。
攻撃者が細工したリクエストを送信すると、特定の条件下でPHP内部のメモリ状態を破壊できる可能性がある。
脆弱性の技術的な内容
CVE-2026-109618:メモリ不足時の処理不備
PHPでは、メモリ不足(Out of Memory:OOM)が発生した場合、現在の処理を中断する仕組みがある。
今回の問題では、longjmp() による処理の中断が、不完全に初期化された内部データを残す場合がある。
その後の終了処理で、正常なデータとして扱ってしまう可能性がある。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
HTTPリクエスト | v PHP内部処理 | v メモリ確保処理 | v メモリ不足(OOM) | v longjmp() による処理中断 | v 内部データが不完全な状態 | v 終了処理が不正なデータを参照 | v メモリ破壊 | v 条件によって任意コード実行 |
CVE-2026-109619:解放済みメモリの参照
こちらは、解放済みのメモリを再び参照してしまう問題。
一般的に Use After Free(UAF) と呼ばれる種類の不具合に関連する。
PHPがリクエストの処理を終了すると、不要になったメモリは解放される。
しかし、今回の問題では、PHP内部のグローバルな状態に古いメモリ参照が残る場合がある。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
リクエストA | v 内部データをメモリに作成 | v 処理終了・メモリ解放 | v 古い参照が残存 | v リクエストB | v 同じPHPワーカーが処理 | v 解放済みメモリを参照 | v 不正なデータや制御情報を使用 | v 条件によって任意コード実行 |
なぜサーバーが乗っ取られるのか
ここが今回の最も重要なポイント。
通常のHTTPリクエストでは、アプリケーション側に用意された処理しか実行されない。
しかし、PHP本体のメモリ管理に不具合があると、PHPエンジン自体の動作に影響を与える可能性がある。
メモリ破壊によって、プログラムが参照するデータや実行の流れが不正な状態になる場合がある。
攻撃者がその状態を制御できると、本来実行されない処理へ誘導できる可能性がある。
つまり、次の2つは異なる。
通常のリクエスト
|
1 2 3 4 5 |
HTTPリクエスト ↓ Laravelで定義された処理 ↓ 正常なレスポンス |
脆弱性を悪用したリクエスト
|
1 2 3 4 5 6 7 8 9 |
細工されたHTTPリクエスト ↓ PHP内部処理の不具合 ↓ メモリ破壊 ↓ PHPの実行制御に影響 ↓ 攻撃者の意図したコードが実行される可能性 |
単にリクエストを送れば乗っ取れるという意味ではない。
PHPの内部不具合を利用して、プログラムの正常な実行制御を逸脱させることが問題である。
なお、メモリ破壊が発生しても、必ず任意コード実行に成功するわけではない。攻撃成立には追加の条件が必要となる。
Laravelの認証は有効なのか
Laravelの認証機能そのものが無効になるわけではない。
問題は、Laravelの認証処理より前の段階で攻撃が成立する可能性があること。
特にApacheの mod_php 方式では、アプリケーションコードの実行前に攻撃が成立することが実証されている。
そのため、Laravel側で認証を厳密に実装していても、今回のPHP本体の脆弱性を防げるとは限らない。
想定される被害
攻撃が成功し、任意コード実行に至った場合、次のような被害が考えられる。
| 被害 | 内容 |
|---|---|
| 情報漏えい | 設定ファイルやデータベース接続情報の取得 |
| 不正なプログラム実行 | PHP実行ユーザーの権限でコマンドを実行 |
| ファイル改ざん | Webアプリケーションのファイルを書き換える |
| データベース侵害 | 取得した認証情報を使ってDBへアクセス |
| マルウェア設置 | 不正プログラムの設置や永続化 |
| サーバー停止 | 異常終了やリソース消費によるサービス停止 |
ただし、PHPの実行権限を取得することと、OSのroot権限を取得することは別である。
攻撃者がどこまで操作できるかは、PHPの実行ユーザーやサーバーの権限設定によって異なる。
影響を受けるPHP環境
2026年10月21日に修正版が公開された。
| PHP系列 | 修正版 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
PHP 8.1以前については、PHP公式の通常サポートが終了しているため、ディストリビューション提供元のバックポート修正やサポート対象版への移行を確認する必要がある。
影響する実行方式には、Apache mod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedなどが含まれる。
サーバー管理者が確認すべき事項
- PHPのバージョンを確認する。
- Apache、Nginx、PHP-FPMなどの実行構成を確認する。
- 外部からPHPの処理にアクセスできるか確認する。
- 修正済みPHPへ更新する。
- Webサーバーのアクセスログ・エラーログを確認する。
- PHPプロセスによる不審なコマンド実行や外部通信を確認する。
PHPバージョン確認コマンド:
|
1 |
php -v |
ただし、CLI版とWebサーバーで使用しているPHPのバージョンが異なる場合があるため、Web側のPHP実行環境も別途確認する。
現在の状況
2026年10月22日時点で、脆弱性の存在と、研究者による任意コード実行の実証が公表されている。
また、セキュリティ企業Cloudflareは、この脆弱性を狙った攻撃通信や防御回避の試みを報告している。
一方、攻撃通信の観測と、実際にサーバーへの侵入が成功したことは区別する必要がある。
結論
今回のPHP2Shellは、PHPアプリケーションの認証やルーティングの不備ではなく、PHPエンジンのメモリ管理に存在する脆弱性である。
重要な点は次の3つ。
- 通常のHTTPリクエストでは、アプリケーションが定義した処理しか実行されない。
- 今回はPHP本体のメモリ管理の不具合を利用し、正常な実行制御から逸脱させる可能性がある。
- その結果、Laravelの認証とは無関係に、サーバー上で任意のコードが実行される可能性がある。
最も重要なのは、単にHTTPリクエストを受信することが危険なのではなく、そのリクエストを処理するPHPエンジンに、外部から悪用可能な不具合が存在するという点である。
