サイトアイコン HIBISEI Blog

PHPに重大な脆弱性「PHP2shell」発覚！AIが発見を支援した2つのRCEと対策を解説

You

PHPに、Webサイトやサーバーのセキュリティに重大な影響を及ぼす可能性がある2つの脆弱性が公表されました。

今回の脆弱性は「PHP2shell」と呼ばれ、悪用されると、攻撃者がログインしていなくても、サーバー上で任意のコードを実行される可能性があるようです。

特に注目されているのは、AIを活用したセキュリティ調査によって、PHP内部に潜んでいた問題の発見や検証が進められたことです。

PHPは、WordPressをはじめ、多くのWebサイトやWebアプリケーションで利用されています。そのため、PHPを利用している企業やWebサイト運営者にとって、今回の問題は決して無関係ではありません。

このページでは、PHP2shellの概要、2つの脆弱性の違い、攻撃が成立する仕組み、そしてWebサイト運営者が実施すべき対策をわかる範囲で解説します。

※このページは2026年10月29日時点の公表情報をもとにしています。

PHP2shellとは？2つの重大な脆弱性が公表

2026年10月21日、PHPの開発チームは、PHPの内部処理に関する2つの重大な脆弱性について、セキュリティ情報と修正版を公開しました。

独立行政法人情報処理推進機構（IPA）も、2026年10月22日に注意喚起を公表しています。

今回の2つの脆弱性は、次のとおりです。

項目内容
脆弱性の通称PHP2shell
CVE-2026-109618メモリー不足時の処理に起因するメモリー破損
CVE-2026-109619古い内部状態が残ることによるメモリーの不正使用
深刻度CVSS v4.0で9.2／10
主なリスク認証されていない攻撃者によるリモートコード実行
修正公開日2026年10月21日

CVEは、公開された脆弱性を識別するための番号です。
CVSSは、脆弱性の深刻度を評価するための指標です。

今回のCVSSスコアは9.2で、非常に深刻な問題として評価されています。

重要なのは、単にWebサイトが表示されなくなるだけの不具合ではないことです。
条件が成立すると、攻撃者がPHPの実行プロセスの権限で、意図しないコードを実行できる可能性があります。

リモートコード実行（RCE）とは？

今回の脆弱性を理解するうえで、最初に知っておきたいのが「RCE」です。

RCEは、Remote Code Executionの略で、日本語では「遠隔コード実行」と呼ばれます。

簡単にいうと、外部のコンピューターから送られたリクエストなどをきっかけに、攻撃対象のサーバー上で攻撃者が意図したプログラムを実行できてしまう状態です。

例えば、Webサイトのサーバーが攻撃者に悪用された場合、設定や権限によっては、次のような被害につながる可能性があります。

ただし、RCEが成立したからといって、必ずサーバー全体の管理者権限を取得されるわけではありません。実際に可能な操作は、PHPの実行ユーザーやサーバーの権限設定などによって異なります。

また、脆弱性が存在することと、実際に攻撃を受けて被害が発生したことは別です。影響を受ける環境では、速やかな修正と必要に応じた侵害調査が重要になります。

CVE-2026-109618：メモリー不足によって処理が壊れる脆弱性

1つ目は、PHPがメモリー不足に陥った際のエラー処理に関係する脆弱性です。

正式には「RCE via OOM corruption」と説明されています。

OOMは「Out Of Memory」の略で、プログラムが必要とするメモリーを確保できなくなる状態を指します。

PHPのメモリー不足とは？

PHPには、1回の処理で使用できるメモリー量を制限するmemory limitという設定があります。

これは、1つの処理がメモリーを使いすぎて、サーバー全体に影響を及ぼすことを防ぐための仕組みです。

通常、メモリーの上限に達すると、PHPはエラーを発生させ、処理を中断します。

ところが、今回の脆弱性では、特定のタイミングでメモリー不足が起きると、PHP内部に不完全な状態のデータが残り、その後の処理で問題が発生する可能性があります。

机と書類に例えると？

PHPを、机の上で書類を処理する事務担当者に例えてみます。

  1. 担当者は、届いた依頼書を机に広げて作業します。
  2. 机がいっぱいになると、新しい書類を置けなくなります。
  3. 本来なら、作業を安全に中断し、途中の書類を正しく片付ける必要があります。
  4. しかし、片付けの途中で不完全な書類や参照先が机に残り、後の作業で使われてしまう可能性があります。

今回の問題は、単に机がいっぱいになることではありません。
メモリー不足が発生した際の内部処理が不完全になり、メモリーの破損につながる可能性があることです。

なぜメモリー破損が危険なのか？

メモリーは、プログラムがデータを保存したり、処理を進めたりするために使う領域です。

その内容が壊れると、プログラムが誤ったデータを使用したり、本来想定していない動作をしたりする可能性があります。

今回の脆弱性では、攻撃者が特定の条件を満たすリクエストを送ることで、メモリー破損を悪用し、任意のコードを実行できることが実証されています。

特にApacheのmod_php構成では、アプリケーションのPHPコードが実行される前の段階で攻撃を成立させる経路が確認されています。

（Apache：Apache HTTP Server。インターネットでウェブコンテンツを配信するフリー+オープンソースのウェブサーバー
　mod_php構成：PHPを動作させる方式の１つ）

また、PHP-FPMでも、アプリケーション側の処理経路を介したリモートコード実行が確認されています。

（PHP-FPM：FastCGI Process Manager。PHP標準のアプリケーションサーバーの１つ）

これは、Webサイトのプログラムだけを調べても、PHPエンジン自体に潜む問題をすべて発見できるわけではないことを示しています。

CVE-2026-109619：古い内部状態が残り、解放済みメモリーを使ってしまう脆弱性

2つ目は、PHPの内部状態が適切にリセットされず、既に解放されたメモリーを後続の処理で使用してしまう問題です。

正式には「RCE via stale global state」と説明されています。

ここでいうグローバル状態とは、PHPのワーカーが保持するエラー情報、セッション情報、オブジェクトや拡張機能に関係する内部状態などを指します。

仕事が終わったのに、古い情報が残っていたら？

この問題も、事務担当者に例えると理解しやすくなります。

  1. 担当者が、お客様Aの依頼を処理します。
  2. 仕事が終わり、Aさんの書類は片付けられます。
  3. ところが、担当者のメモには「Aさんの書類はあそこにある」という古い参照先が残ってしまいます。
  4. 次にお客様Bの依頼を処理するとき、その古い参照先を使ってしまう可能性があります。

コンピューターでは、メモリー上のデータが解放されても、その場所を指す参照が残っていると、後の処理が無効なメモリーを使用してしまうことがあります。

この問題を「Use-After-Free（UAF）」と呼びます。

Use-After-Freeとは？

Use-After-Freeは、既に解放されたメモリーをプログラムが再び使用してしまう不具合です。

メモリーが解放された後、その領域は別のデータの保存に使われる可能性があります。そのため、古い参照を通じて読み書きすると、予期しないデータを扱ったり、メモリー破損を起こしたりする可能性があります。

今回の脆弱性では、致命的なエラーなどによって内部状態のリセットが不完全になると、リクエストの処理が終わった後も、古いメモリーへの参照が残る場合があります。

同じワーカーが後続のリクエストを処理するとき、通常の初期化処理が完了する前に、その古い状態が利用されることが問題です。

報告者は、ApacheのもDmod_phpで動作する実際のアプリケーションに対して、リモートコード実行を実証しています。また、PHP-FPMについても、特定のアプリケーション処理経路を通じた攻撃が確認されています。

ただし、Use-After-Freeが発生するだけで、必ず任意のコードを実行できるわけではありません。攻撃の成立には、メモリーの状態や後続処理など、複数の条件が関係します。

2つの脆弱性は何が違う？

ここまで説明した2つの問題は、どちらもPHP内部の処理に関係していますが、原因は異なります。

比較項目CVE-2026-109618CVE-2026-109619
主な原因メモリー不足時の処理の不整合古い内部状態の残存
問題の種類メモリー破損Use-After-Free
たとえ未完成の書類を使ってしまう片付けた書類の古い参照先を使ってしまう
主なリスク条件次第でRCE条件次第でRCE
根本的な対策PHPの修正版への更新PHPの修正版への更新

どちらも、プログラムがエラーになったときに安全な状態を維持できないことが、深刻な問題につながっています。

また、2つの脆弱性は別々の問題ですが、エラー処理やメモリー管理に関連しているため、両方に対する修正を適用することが重要です。

AIがPHPの脆弱性発見を支援した

今回の問題で注目されるもう一つの点が、AIを活用したセキュリティ調査です。

AIは、大量のソースコードを分析したり、複雑な処理の組み合わせを調べたりする作業を支援できます。

今回の調査では、AIを活用した分析や検証が、PHP内部に潜んでいた問題の発見・調査に貢献したと報告されています。

ただし、AIが単独で脆弱性を発見し、すべてを解決したというわけではありません。実際の調査では、研究者や開発者による検証、再現テスト、修正作業なども重要な役割を果たしています。

AIによって、これまで人間が調べるのに多くの時間を必要としていた処理経路についても、より広範囲な分析が可能になりつつあります。

一方で、脆弱性を発見する能力が高まっても、すべてのサーバーが自動的に修正されるわけではありません。

修正プログラムの開発、互換性の検証、利用者への配布、実際の環境への適用までには、別の作業が必要です。

今後は、AIによる脆弱性の発見と、人間や組織による迅速な修正対応を、どのように両立させるかが重要になります。

WordPressを利用しているサイトも対策が必要？

PHPは、WordPressをはじめ、多くのWebサイトで使用されています。

そのため、WordPressを利用している場合も、サーバー側のPHPが影響を受けるバージョンでないか確認する必要があります。

ただし、WordPressを使っているサイトがすべて同じ条件で攻撃を受けるわけではありません。実際のリスクは、PHPのバージョン、実行方式、設定、アプリケーションの処理経路などによって異なります。

対策では、次の3つを分けて考えることが重要です。

1. PHPのバージョンを確認する

レンタルサーバーの管理画面などで、実際にWebサイトが使用しているPHPのバージョンを確認します。

PHPのバージョンは、WordPressの管理画面にあるサイトヘルスや、サーバー会社の管理画面から確認できる場合があります。

2. WordPress本体・テーマ・プラグインを更新する

今回の問題はPHP本体の脆弱性ですが、WordPress本体やテーマ、プラグインにも別の脆弱性が存在する可能性があります。

それぞれの提供元が公開しているセキュリティ情報を確認し、必要な更新を適用しましょう。

3. バックアップと動作確認を行う

更新前には、Webサイトのファイルとデータベースをバックアップしておきます。

更新後は、トップページ、ページ、問い合わせフォーム、管理画面などが正常に動作するか確認しましょう。

なお、今回のような重大な脆弱性では、バックアップを取るだけで安心するのではなく、修正版への更新を優先することが重要です。

PHP2shellの修正版と対応バージョン

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系列への移行を検討しましょう。

レンタルサーバーを利用している場合は、PHPの更新方法や適用できるバージョンが事業者によって異なります。サーバー会社の公式案内を確認してみてください。

また、PHPの更新後は、サイトが正常に動作することも確認しましょう。

PHPのバージョンを確認し、今回の脆弱性に対する修正が適用されている状態にすることが重要です。

【追記】2026年10月27日：悪用された脆弱性として登録

IPAは2026年10月27日の更新で、CVE-2026-109618とCVE-2026-109619が、米国のサイバーセキュリティ・インフラストラクチャ安全保障庁（CISA）の「Known Exploited Vulnerabilities（KEV）カタログ」に掲載されたことを公表しました。

KEVカタログは、実際に悪用されたことが確認された脆弱性を掲載するリストです。

IPAは、国内での攻撃被害事例については把握していないと説明しています。ただし、国内で被害が確認されていないことは、今後も攻撃されないことを意味するわけではありません。

影響を受けるPHPを利用している場合は、速やかに修正版への移行を進めましょう。

まとめ：PHPの脆弱性は、発見後の迅速な対応が重要

今回公表されたPHP2shellは、PHP内部のメモリー管理やエラー処理に関係する2つの重大な脆弱性です。

いずれも、条件が成立すると、認証されていない攻撃者によるリモートコード実行につながる可能性があります。

AIを活用した調査が脆弱性の発見・検証を支援する一方、修正プログラムを適用する作業は、Webサイトやサーバーの管理者にとって重要な課題です。

WordPressを運営している場合も、PHPのバージョンを確認し、サーバー会社の案内に従って必要な更新を行いましょう。

セキュリティ対策は、一度実施すれば終わりではないのが大変です。
新たな脆弱性の情報を確認し、適切な更新を継続することが、Webサイトを安全に運営するために必要になります。

モバイルバージョンを終了