PHP2shell（CVE-2026-109618/109619）とは？対象バージョンと対策手順 | UNIX Cafe

確認日：2026年10月23日

PHPは、サーバー上でWebページの表示やフォームの送信処理などを行うプログラミング言語です。PHPを使うサイトでは、サイトのプログラムだけでなく、それを動かすPHP本体にも更新が必要です。

IPA（情報処理推進機構）は10月22日、PHP本体に見つかった2件の脆弱性について注意喚起を公開しました。脆弱性とは、攻撃に悪用されるおそれがあるソフトウェアの欠陥です。今回は、外部の攻撃者がサーバーに意図しない処理を実行させる「遠隔コード実行」につながる可能性があります。この2件の組み合わせは「PHP2shell」と呼ばれています。

• IPAの注意喚起

サイトの管理者がまず行うことは、サイトを動かしているPHPのバージョンと、修正が適用されているかの確認です。この記事では、問題の仕組み、対象バージョン、対応の順序を説明します。

何が問題なのか

ブラウザーでページを開いたり、フォームを送信したりすると、サーバーに処理の依頼が届きます。この依頼を「リクエスト」と呼びます。PHPはリクエストを処理する間、メモリという一時的な作業領域にデータを置き、処理が終わると不要になった領域を解放します。

今回の2件は、この作業領域の扱いや、処理を終えた後の後片付けに関係します。以下のCVE番号は、個々の脆弱性を区別するための識別番号です。サーバー会社に問い合わせる際にも、この番号で対象を伝えられます。

どちらも深刻度はCritical（緊急）、CVSS v4.0の評価は9.2です。CVSSは脆弱性の深刻さを共通の基準で評価する仕組みで、数値の上限は10です。9.2は高い深刻度を示しますが、攻撃の成功率を表す数字ではありません。

どのような環境で問題になるのか

PHPをWebサーバーと連携させる方法には、いくつかの種類があります。たとえば、ApacheというWebサーバーにPHPを組み込む方式が「mod_php」、PHP専用の処理プログラムに仕事を渡す方式が「PHP-FPM」です。

CVE-2026-109618はmod_phpで、サイトのプログラムが動き始める前に、ログインなどの認証なしでコードを実行できることが確認されています。CVE-2026-109619はmod_phpに加え、アプリケーション側の条件を満たすPHP-FPMでもコード実行が検証されています。PHP-FPMを使っている場合も確認が必要です。

• CVE-2026-109618の検証結果
• CVE-2026-109619の検証結果

リクエストを実際に処理するプログラムを「ワーカー」と呼びます。たとえばPHP-FPMでは、複数のワーカーが依頼を分担します。攻撃が成立すると、このワーカーに許可された権限でコードが動くため、ワーカーが読み書きできるデータの漏えいや改ざんなどが想定されます。

2件はそれぞれコード実行が確認されており、必ず組み合わせなければ悪用できないわけではありません。なお、ここでの「確認」は公式解説にある検証結果を指し、実際のサイトで被害が発生したことを示すものではありません。

影響を受けるバージョンと修正版

利用中の環境で使っているPHPが更新対象かを判断するため、まずバージョンを次の表と照合します。たとえばPHP 8.3.35を使っている場合は8.3系に該当し、今回の修正版である8.3.36より前なので対象です。

表にない古い系列にも注意が必要です。IPAは、調査に関与したWizの情報として、PHP 5.4以降はいずれかの脆弱性の影響を少なくとも受けると紹介しています。

• IPAの影響範囲・対策

PHP 8.1以前はPHPプロジェクトの通常サポートが終了しています。ただし、LinuxなどのOSの配布元や、長期保守を提供する会社が、古い系列に修正を取り込む「バックポート」を提供する場合があります。この場合、表示されるPHPのバージョン番号だけでは修正済みか判断できないため、提供元の案内も確認します。

PHP公式も今回、7.4／8.0／8.1向けに必要最小限の修正を取り込んだソースコードを案内しています。これは通常サポートの再開を意味しません。

• PHP公式発表

対応は「確認・更新・動作確認」の順で進める

目的は、サイトへのリクエストを修正済みのPHPが処理する状態にすることです。修正版、または提供元が修正済みと確認した配布パッケージへ更新します。配布パッケージとは、OSなどにインストールできる形にまとめられたソフトウェアです。PHP公式は、設定変更だけでは完全な対策にならないと説明しています。

以下は、この方針を実際の運用に落とし込むための確認手順です。

1. PHPを使っている場所と管理者を確認する

更新漏れを防ぐため、公開サイトだけでなく管理画面も調べます。WordPressのように記事やページを管理するCMSを使っている場合も、その土台となるPHPが確認対象です。

PHPを自分で管理しているのか、サーバー会社に任せているのかを整理します。レンタルサーバーで利用者が直接更新できない場合は、サービス提供元に2件のCVE番号を伝え、対応状況と利用者側の作業の有無を確認してください。

2. 実際にサイトを動かしているPHPを確認する

ここで確かめたいのは、閲覧者からの依頼を処理するPHPのバージョンと修正状況です。サーバーの管理画面や提供元の案内で確認します。

端末でコマンドを入力できる場合、次のコマンドでもPHPのバージョンを表示できます。

php -v

ただし、これは端末から起動するPHPの情報です。同じサーバーでも、Webサイト用には別のPHPを使っていることがあります。この結果だけで対応完了とせず、Web側の設定や提供元の情報と照合してください。

3. 復旧の準備をしてから更新する

更新でサイトの動作に影響が出た場合に備え、サイトのファイルやデータベースのバックアップを用意します。可能であれば、本番とは別の確認用環境で、ログイン、フォーム送信、ファイルアップロードなどを試してから更新します。

更新方法は、レンタルサーバーの管理画面、OSの更新機能など、導入方法によって異なります。利用している環境の手順に従ってください。

4. 新しいPHPで動いていることを確認する

更新したファイルを配置しても、古いワーカーが動き続けている場合があります。環境の手順に従ってサービスを再起動し、実際に動いているPHPが修正済みであることを確認します。

PHPと必要なソフトウェアをひとまとめにした「コンテナ」で運用している場合は、修正済みの内容で作り直したコンテナへの入れ替えを確認します。最後に主要機能をもう一度試し、エラーの記録が増えていないかを調べます。

すぐに更新できない場合の暫定対策

暫定対策の目的は、更新が完了するまでに悪用される可能性を下げることです。以下の設定は一部の攻撃経路を減らしますが、脆弱性そのものを完全には解消しません。サーバーの管理者が、サイトへの影響と併せて検討する必要があります。

メモリ不足を利用する攻撃経路を減らす

CVE-2026-109618では、PHPが設定されたメモリ上限に達したときの処理が、攻撃のきっかけになり得ます。公式は、この上限によるメモリ不足を起こさせないため、PHPの上限を解除する方法を挙げています。

その設定が memory_limit=-1 です。管理者側で適用し、サイト側の設定などで有限の上限に戻されないことを確認したうえで、全ワーカーを再起動します。

ただし、PHP自身の上限をなくすと、メモリ使用量が増えるおそれがあります。また、サーバー側でメモリを確保できなくなる場合の問題は残ります。受け付けるリクエストの大きさなどを制限し、コンテナや、Linuxでプログラム群の資源を制御する「cgroup」による制限も併せて検討します。たとえば、ワーカー群が使えるメモリ量をOS側で管理する方法です。これらも完全な対策ではありません。

OS側の制限なら何でも代用できるわけではありません。プログラムのアドレス空間やデータ領域を制限する RLIMIT_AS／RLIMIT_DATA は、メモリ確保の失敗を引き起こして脆弱な処理に到達させるため、公式は使用を避けるよう求めています。

• OOMに関する公式の緩和策

古い内部状態を使う攻撃経路を減らす

CVE-2026-109619では、使用済みのメモリへの参照が次のリクエストまで残ることが問題です。確認済みの経路を減らすため、公式は次の機能の無効化を案内しています。

設定は管理者が適用し、全ワーカーを再起動します。別の内部状態を使う経路は残り得ます。また、画面にエラーメッセージを表示しなくても内部の処理は行われるため、エラーの非表示だけでは防げません。

• 内部状態の残留に関する公式の緩和策

アップロード進捗の無効化は、届いたリクエストをPHPが読み取る前から有効であることが必要です。そのため、PHPの基本設定ファイルである php.ini や、PHP-FPMのワーカーのグループを管理する「FPMプール」の設定、サーバー設定で適用します。

PHPのプログラム内から設定を変える ini_set() や、ディレクトリごとに設定を指定するFPMの .user.ini は、この対策に必要な時点には間に合いません。

• PHP公式の設定上の注意

暫定対策が難しい場合

安全に運用できる見通しが立たない場合は、外部からのアクセス制限やサービスの一時停止も検討します。古いPHPを使い続けている場合は、サポート中のPHPへの更新や、保守を受けられるサービスへの移行を含めて対応を決めます。

• IPAの更新が難しい場合の案内

10月23日付の追加情報：セッション関連の別の問題

PHP公式は、今回の2件とは別の CVE-2026-115560 に関連する追加案内も公開しています。

「セッション」は、複数のアクセスにまたがって情報を保持する仕組みです。たとえば、ページを移動してもログイン状態を維持するために使われます。そのデータを保存できる形式に変換することを「シリアライズ」と呼びます。

追加案内の問題は、特定のセッション設定と、サイトのプログラムが実行途中でシリアライズ方式を変更する処理が重なる場合に発生します。PHP公式は、次の通常バグ修正リリースまで、先ほど説明したアップロード進捗を session.upload_progress.enabled=0 で無効にすることを提案しています。

今回の2件の修正版へ更新した場合も、この追加事項は別途確認します。実行時にシリアライズ方式を変更しないアプリケーションは、機能を有効のままにできると説明されています。

• PHP公式：Informational advisory: Session upload progress（2026年10月23日）

※本記事は確認日時点の公開情報を整理したものです。適用するパッケージや設定は、PHP公式および利用サービス・OSの提供元の最新情報と照合してください。