PHPは世界中のWebサイトで利用されているプログラミング言語であり、WordPressやLaravelなど、多くのWebシステムの基盤となっています。

深刻な脆弱性が発見された以上、速やかな対応が必要なのは当然です。

しかし、今回のニュースをきっかけに「PHPは危険」「WordPressを使い続けるべきではない」「別の技術へ移行すれば安全になる」といった主張も見られます。

果たして、本当にそうなのでしょうか。

ソフトウェア開発の観点から見ると、こうした単純な結論には慎重な検討が必要です。

本記事では、PHPの脆弱性をきっかけに、プログラミング言語の実行環境、WordPressの安全性、そしてセキュリティ報道のあり方を整理します。

PHPの脆弱性とWordPressの脆弱性は同じではない

まず、整理しておきたいのは、PHPとWordPressは別のソフトウェアだということです。

PHPはプログラミング言語とその実行環境であり、WordPressはPHPで開発されたCMS（コンテンツ管理システム）です。

PHPの実行環境に脆弱性が発見されたからといって、それがWordPressのプログラム自体の欠陥であるとは限りません。

例えば、PHPを使用する代表的なシステムには、次のようなものがあります。

• WordPress
• Laravelで構築されたWebアプリケーション
• PHPによる独自開発の業務システム
• その他のPHP製CMSやWebサービス

PHPの実行環境に問題があれば、WordPressに限らず、これらのシステムにも影響が及ぶ可能性があります。

ただし、実際に攻撃が成立するかどうかは、PHPのバージョン、サーバー構成、脆弱性を引き起こす条件などによって異なります。

したがって、今回の問題を単純に「WordPressが危険」と表現するのは正確ではありません。

JavaScriptにも実行エンジンが存在する

ここで、PHP以外のプログラミング言語について考えてみましょう。

例えばJavaScriptです。

JavaScriptはブラウザ上で動作するプログラミング言語ですが、ブラウザが直接ソースコードを実行しているわけではありません。

内部にはJavaScriptエンジンが組み込まれています。

代表的なものには、Google ChromeやMicrosoft Edgeで利用されているV8、FirefoxのSpiderMonkey、SafariのJavaScriptCoreがあります。

これらのエンジンは、JavaScriptを解析し、必要に応じて機械語へコンパイルしながらプログラムを実行します。

そして重要なのは、これらのエンジン自体もソフトウェアだということです。

例えばV8は、主にC++で開発されています。

つまり、JavaScriptのソースコードに問題がなくても、V8の内部処理に不具合が存在する可能性があります。

実際、JavaScriptエンジンでも、メモリ破壊や型の取り扱いに関する脆弱性が過去に発見されています。

PHPだけが特別に脆弱性を抱えやすいというわけではありません。

どのプログラミング言語にも脆弱性が存在する可能性がある

プログラミング言語には、それぞれ実行環境やライブラリが存在します。

例えば、次のようなものです。

これらの実行環境も、人間が設計・開発したソフトウェアです。

そのため、プログラムの不具合が存在する可能性を完全に否定することはできません。

特に、CやC++などで実装された部分では、メモリ管理に関する問題が発生することがあります。

例えば、次のような脆弱性です。

• Use-after-free（解放済みメモリへのアクセス）
• バッファオーバーフロー
• 不正なメモリアクセス
• 型の取り扱いの不備
• 整数オーバーフロー

こうした問題が実行環境に存在すれば、アプリケーション側のコードが適切に書かれていても、影響を受ける可能性があります。

もちろん、すべての言語や実行環境が同じ危険度という意味ではありません。

メモリ安全性を重視した設計、実行時の検証、サンドボックスなど、言語や環境によって安全性を高める仕組みは異なります。

しかし、どの技術についても「100%安全」と保証することは困難です。

WordPressを使わなければ安全になるのか？

今回の脆弱性を受けて、WordPressから別の技術への移行を勧める意見もあります。

例えば、WordPressを使用せず、静的HTMLを配信するWebサイトへ変更する方法です。

確かに、静的サイトにはセキュリティ上の利点があります。

公開サーバー上でPHPを実行しなければ、PHPランタイムを狙った攻撃面を減らせます。

また、データベースや動的処理を公開環境から取り除くことによって、攻撃対象を小さくできる場合もあります。

これは技術的に合理的な選択です。

しかし、静的サイトに変更したからといって、すべてのセキュリティリスクがなくなるわけではありません。

静的サイトでも、JavaScriptライブラリ、ビルドツール、外部サービス、ホスティング環境、管理者アカウントなどに脆弱性が存在する可能性があります。

さらに、更新作業やコンテンツ管理の方法によっては、新たな運用上の負担が生じることもあります。

重要なのは、WordPressを使うか使わないかではありません。

システム全体の構成を理解し、どのようなリスクが存在するのかを把握することです。

PHPを使わなければ安全になるのか？

これも同じです。

例えば、PHPで構築されたシステムをNode.jsへ移行したとします。

Node.jsではJavaScriptが利用され、内部ではV8エンジンが動作しています。

PHPの実行環境に依存しなくなるため、今回のようなPHP固有の脆弱性による影響は回避できます。

しかし、今度はNode.js、V8、利用するパッケージなどの安全性を管理する必要があります。

PythonやJava、C#へ移行する場合も同様です。

移行先の言語や実行環境にも、それぞれ固有のセキュリティリスクがあります。

したがって、PHPを使用しないこと自体が安全性の保証になるわけではありません。

むしろ、移行によって新しい不具合が発生したり、十分に理解していない技術を運用することになったりすれば、別のリスクが生じる可能性もあります。

技術移行は、セキュリティだけでなく、保守性、運用コスト、開発体制、必要な機能などを総合的に判断すべきものです。

メディアの報道は不安を煽りすぎていないか？

今回の報道で特に検討すべきなのは、脆弱性の発見を特定の技術そのものの危険性と結びつけるような論調です。

もちろん、深刻な脆弱性を報道し、利用者や管理者に注意を促すことは重要です。

しかし、例えば「PHPを使用しているWebサイトが多数存在する」という事実と、「それらのWebサイトがすべて攻撃可能である」という話は違います。

脆弱性が存在することと、実際に攻撃が成立することも同じではありません。

攻撃が成立するには、対象のバージョン、サーバー構成、入力条件など、さまざまな要素が関係します。

それらの条件を十分に説明せず、危険性だけを強調すると、利用者に必要以上の不安を与えてしまう可能性があります。

また、今回の問題を理由に、WordPressやPHPからの移行を一律に推奨することには、慎重な判断が必要です。

移行によって攻撃面を減らせる場合はありますが、それがすべてのWebサイトにとって最適な対策とは限りません。

メディアには、危険性を伝えるだけでなく、技術的な条件や具体的な対策を正確に伝えることが求められます。

脆弱性が発見されたことは、必ずしも悪いことではない

もう一つ考えておきたいことがあります。

それは、脆弱性が発見されること自体の意味です。

ソフトウェアには、長期間発見されていない不具合が存在する可能性があります。

脆弱性が公表されていないからといって、そのソフトウェアに問題が存在しないとは限りません。

むしろ、問題が発見され、修正され、利用者へ情報が公開されることは、セキュリティを改善するうえで重要なプロセスです。

近年はAIを活用したコード解析や脆弱性調査も進歩しています。

これまで発見が難しかった問題が、今後さらに明らかになる可能性もあります。

その結果、さまざまな言語や実行環境で脆弱性の報告が増えることも考えられます。

しかし、報告件数が増えることが、そのままソフトウェアの品質低下を意味するわけではありません。

問題を発見し、修正できることも、健全なソフトウェア開発に欠かせない要素です。

本当に重要なのは継続的なセキュリティ対策

では、今回のような問題には、どのような対応が必要でしょうか。

特定の言語やCMSを排除することよりも、次のような基本的な対策を継続することが重要です。

1. PHPなどの実行環境をサポート対象のバージョンに保つ
2. WordPress本体、テーマ、プラグインを適切に更新する
3. OSやWebサーバー、ライブラリの脆弱性情報を確認する
4. サーバーやアプリケーションの権限を必要最小限にする
5. 不要な機能や外部からのアクセスを制限する
6. バックアップと復旧手順を整備する
7. 脆弱性が公表された場合は、実際の影響条件を確認して対策する

これらはPHPやWordPressに限った話ではありません。

Node.jsでもPythonでもJavaでも、基本的な考え方は共通しています。

また、更新できない古いシステムについては、リスクを把握したうえで、ネットワーク分離やアクセス制限などの暫定対策、あるいは計画的な移行を検討する必要があります。

まとめ：PHPが悪い、WordPressが悪いという問題ではない

今回のPHPの脆弱性は、決して軽視できる問題ではありません。

影響を受けるシステムについては、適切な更新や対策を速やかに実施すべきです。

しかし、それを理由に「PHPは危険」「WordPressを使わなければ安全」と結論づけるのは、技術的に正確ではありません。

JavaScriptにもPythonにもJavaにも、それぞれ実行環境があり、脆弱性が発見される可能性があります。

そして、別の技術へ移行したとしても、セキュリティリスクが完全になくなるわけではありません。

重要なのは、使用している技術の特性とリスクを理解し、適切に管理し続けることです。

脆弱性が発見された技術が悪いのではなく、脆弱性を正しく理解せず、必要な対策を講じないことが問題なのではないでしょうか。

セキュリティに100%の安全はありません。

だからこそ、必要以上に恐れるのではなく、正確な情報に基づいて冷静に判断することが大切です。

今回の問題を、特定の技術への批判だけで終わらせず、ソフトウェア全体のセキュリティを見直すきっかけにすることが重要です。

概要

2026年10月21日、PHP本体に存在する2件の重大な脆弱性が公表され、修正版が公開された。

この脆弱性は「PHP2Shell」と呼ばれ、外部から送信されたHTTPリクエストを処理する際に、PHP内部のメモリ管理に問題が発生するもの。

条件がそろうと、攻撃者が認証を受けずにサーバー上で任意のコードを実行できる可能性がある。

重要なのは、LaravelやWordPressなどのアプリケーション自体に問題がなくても攻撃が成立する可能性があるという点である。

通常のHTTPリクエスト処理

一般的なLaravelアプリケーションでは、次の順序で処理が実行される。

[外部クライアント]
       |
       | 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() による処理の中断が、不完全に初期化された内部データを残す場合がある。

その後の終了処理で、正常なデータとして扱ってしまう可能性がある。

HTTPリクエスト
      |
      v
PHP内部処理
      |
      v
メモリ確保処理
      |
      v
メモリ不足（OOM）
      |
      v
longjmp() による処理中断
      |
      v
内部データが不完全な状態
      |
      v
終了処理が不正なデータを参照
      |
      v
メモリ破壊
      |
      v
条件によって任意コード実行

CVE-2026-109619：解放済みメモリの参照

こちらは、解放済みのメモリを再び参照してしまう問題。

一般的に Use After Free（UAF） と呼ばれる種類の不具合に関連する。

PHPがリクエストの処理を終了すると、不要になったメモリは解放される。

しかし、今回の問題では、PHP内部のグローバルな状態に古いメモリ参照が残る場合がある。

リクエストA
      |
      v
内部データをメモリに作成
      |
      v
処理終了・メモリ解放
      |
      v
古い参照が残存
      |
      v
リクエストB
      |
      v
同じPHPワーカーが処理
      |
      v
解放済みメモリを参照
      |
      v
不正なデータや制御情報を使用
      |
      v
条件によって任意コード実行

なぜサーバーが乗っ取られるのか

ここが今回の最も重要なポイント。

通常のHTTPリクエストでは、アプリケーション側に用意された処理しか実行されない。

しかし、PHP本体のメモリ管理に不具合があると、PHPエンジン自体の動作に影響を与える可能性がある。

メモリ破壊によって、プログラムが参照するデータや実行の流れが不正な状態になる場合がある。

攻撃者がその状態を制御できると、本来実行されない処理へ誘導できる可能性がある。

つまり、次の2つは異なる。

通常のリクエスト

HTTPリクエスト
   ↓
Laravelで定義された処理
   ↓
正常なレスポンス

脆弱性を悪用したリクエスト

細工されたHTTPリクエスト
   ↓
PHP内部処理の不具合
   ↓
メモリ破壊
   ↓
PHPの実行制御に影響
   ↓
攻撃者の意図したコードが実行される可能性

単にリクエストを送れば乗っ取れるという意味ではない。

PHPの内部不具合を利用して、プログラムの正常な実行制御を逸脱させることが問題である。

なお、メモリ破壊が発生しても、必ず任意コード実行に成功するわけではない。攻撃成立には追加の条件が必要となる。

Laravelの認証は有効なのか

Laravelの認証機能そのものが無効になるわけではない。

問題は、Laravelの認証処理より前の段階で攻撃が成立する可能性があること。

特にApacheの mod_php 方式では、アプリケーションコードの実行前に攻撃が成立することが実証されている。

そのため、Laravel側で認証を厳密に実装していても、今回のPHP本体の脆弱性を防げるとは限らない。

想定される被害

攻撃が成功し、任意コード実行に至った場合、次のような被害が考えられる。

ただし、PHPの実行権限を取得することと、OSのroot権限を取得することは別である。

攻撃者がどこまで操作できるかは、PHPの実行ユーザーやサーバーの権限設定によって異なる。

影響を受けるPHP環境

2026年10月21日に修正版が公開された。

PHP 8.1以前については、PHP公式の通常サポートが終了しているため、ディストリビューション提供元のバックポート修正やサポート対象版への移行を確認する必要がある。

影響する実行方式には、Apache mod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedなどが含まれる。

サーバー管理者が確認すべき事項

1. PHPのバージョンを確認する。
2. Apache、Nginx、PHP-FPMなどの実行構成を確認する。
3. 外部からPHPの処理にアクセスできるか確認する。
4. 修正済みPHPへ更新する。
5. Webサーバーのアクセスログ・エラーログを確認する。
6. PHPプロセスによる不審なコマンド実行や外部通信を確認する。

PHPバージョン確認コマンド：

php -v

ただし、CLI版とWebサーバーで使用しているPHPのバージョンが異なる場合があるため、Web側のPHP実行環境も別途確認する。

現在の状況

2026年10月22日時点で、脆弱性の存在と、研究者による任意コード実行の実証が公表されている。

また、セキュリティ企業Cloudflareは、この脆弱性を狙った攻撃通信や防御回避の試みを報告している。

一方、攻撃通信の観測と、実際にサーバーへの侵入が成功したことは区別する必要がある。

結論

今回のPHP2Shellは、PHPアプリケーションの認証やルーティングの不備ではなく、PHPエンジンのメモリ管理に存在する脆弱性である。

重要な点は次の3つ。

1. 通常のHTTPリクエストでは、アプリケーションが定義した処理しか実行されない。
2. 今回はPHP本体のメモリ管理の不具合を利用し、正常な実行制御から逸脱させる可能性がある。
3. その結果、Laravelの認証とは無関係に、サーバー上で任意のコードが実行される可能性がある。

最も重要なのは、単にHTTPリクエストを受信することが危険なのではなく、そのリクエストを処理するPHPエンジンに、外部から悪用可能な不具合が存在するという点である。

参考資料

• PHP公式セキュリティ情報
• 英国NCSCの注意喚起
• Wiz Research：PHP2Shell技術解説
• Palo Alto Networks Unit 42