【緊急】PHP2Shell脆弱性の対応と代表的な7つの対策

PHPの脆弱性への対策で最も重要なのは、PHP本体をサポート中の最新バージョンに保つことと、アプリケーション側でSQLインジェクションやクロスサイトスクリプティングなどの典型的な脆弱性を作り込まないことの2つです。

2026年10月21日（日本時間23時）には、認証なしで外部から任意のコードを実行されるおそれがある緊急の脆弱性「PHP2Shell」（CVE-2026-109618、CVE-2026-109619）の修正版が公開され、すべてのPHP利用者に直ちに更新することが強く推奨されています。

本記事では、PHP2Shellの概要と今すぐやるべき対応、PHPのサポート期限、PHPアプリで起きやすい代表的な7つの脆弱性とその対策まで、わかりやすく解説します。

【緊急】PHP2Shell（CVE-2026-109618／CVE-2026-109619）とは？

Nano Banana Proで作成

PHP2Shellとは、2026年10月21日に修正版が公開された、PHP本体に含まれる2件の重大な脆弱性の通称です。どちらも深刻度を示すCVSS v4.0のスコアが9.2と非常に高く、攻撃者が外部から任意のコードを実行できるおそれがあります。PHPを使ったWebサイトやWebサービスを運営しているすべての企業が対象になりうる、影響範囲の広い脆弱性です。

2件の脆弱性は、いずれもPHPがリクエストを処理する際の内部状態の管理に問題があります。CVE-2026-109618は、メモリ不足（OOM）時の処理によって、リクエストの内部データが不完全な状態のまま処理が進んでしまう問題です。CVE-2026-109619は、リクエストで使った内部状態がメモリ解放後も残り、同じワーカーで処理される後続のリクエストがその古い状態を使ってしまう問題です。

セキュリティ企業の解説では、デフォルトで有効になっているセッションの「アップロード進捗」機能などが、攻撃の入り口になりうると指摘されています。

影響を受ける環境

影響を受けるのは、PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedなど、PHPを動かす幅広い実行環境です。中でもApacheのmod_phpが最も危険とされ、認証なしのリクエストで、アプリケーションのコードが動く前に攻撃できることが実証されたと報じられています。

WordPress、Laravel、Symfonyといった、よく使われるCMSやフレームワークで構築したサイトでも攻撃の再現が確認されているため、「うちは特別なことをしていないから大丈夫」とは言えません。

国内でも、大手のWebサービスや金融機関などが予防措置として緊急メンテナンスを実施するなど、対応が急ピッチで進んでいます。さらに、悪用をうたう攻撃コードがすでにインターネット上に出回り始めているとの報告もあり、修正版の公開をきっかけに攻撃が本格化することが懸念されています。

修正バージョン一覧

PHP公式は、サポート中の4つのバージョン系列すべてに修正版を公開しています。お使いのPHPのバージョン系列に応じて、以下のバージョン以降に更新してください。

PHP 8.1以前はすでにサポートが終了しているため、PHP公式からの修正版は提供されていません。7.4、8.0、8.1向けに最小限の修正を加えたソースコードは公開されているものの、根本的な対策はサポート中のバージョンへの移行です。

Linuxディストリビューションの長期サポート版やレンタルサーバを使っている場合は、各提供元から修正パッケージが提供されていないかを確認してください。

今すぐやるべき対応

PHP2Shellへの対応で最優先なのは、PHPを修正バージョンへ更新することです。PHP公式も「完全な回避策はなく、更新が唯一の安全な選択肢」と明言しています。具体的には、次の順番で対応を進めましょう。

まず、サーバ上で「php -v」コマンドを実行するか、管理画面などで、現在使っているPHPのバージョンを確認します。次に、上の表を見て修正バージョンへ更新します。レンタルサーバやマネージドサービスを利用している場合は、提供元の対応状況やお知らせを確認しましょう。更新後は、PHP-FPMやWebサーバを再起動して、新しいバージョンが確実に読み込まれていることを確認します。

あわせて、アクセスログやエラーログに不審なリクエストがないかを調べ、万一侵害の痕跡が見つかった場合は、サーバ内のデータの流出有無や、サーバが持つクラウドの権限が悪用されていないかまで確認することが推奨されています。

すぐに更新できない場合の一時的な緩和策

どうしてもすぐに更新できない場合の一時しのぎとして、PHPの設定で「session.upload_progress.enabled」を無効（0）にする、巨大なリクエストを受け付けないよう「post_max_size」を適切に設定する、といった緩和策が紹介されています。

ただし、これらの設定では脆弱性を完全には防げず、別の経路で攻撃が成立する可能性が残ります。緩和策はあくまで更新までの時間稼ぎと考え、できるだけ早く修正版を適用してください。

そもそもPHPの脆弱性とは？——2つの種類を押さえる

出典：https://unsplash.com/ja

PHPの脆弱性とは、PHPを使ったWebサイトやシステムに存在する、攻撃者に悪用されうるセキュリティ上の弱点のことです。PHPは世界中のWebサイトで使われており、WordPressをはじめ多くのCMSやWebサービスの土台になっています。利用者が多いぶん攻撃者にも狙われやすく、脆弱性への対策はWebサイトを運営するうえで欠かせません。

PHPの脆弱性は、大きく2種類に分けて考えるとわかりやすくなります。1つ目は、PHPという言語の処理系（PHP本体）そのものに含まれる脆弱性です。PHP2Shellや後述のCVE-2024-4577がこれにあたり、PHP本体を更新することで対策します。

2つ目は、PHPで書かれたアプリケーションのプログラムに含まれる脆弱性です。SQLインジェクションやクロスサイトスクリプティングなどが代表例で、PHP本体が最新でも、プログラムの書き方に問題があれば攻撃を受けてしまいます。

両方の対策がそろって初めて安全になる

この2種類は、対策の担当や方法がまったく異なります。PHP本体の脆弱性はサーバの管理者が更新で対処し、アプリケーションの脆弱性は開発者が安全なコードを書くことで対処します。どちらか一方だけでは不十分で、「PHPを最新に保つ」と「安全なコードを書く」の両方がそろって初めて、Webサイトを守ることができます。

PHPのサポート期限——EOLのバージョンを使い続ける危険性

PHPには、バージョンごとにサポート期限が決められています。各バージョンはリリースから約2年間の「アクティブサポート」（バグ修正とセキュリティ修正）を受けたあと、さらに約2年間の「セキュリティサポート」（セキュリティ修正のみ）を受け、その後はサポート終了（EOL：End of Life）となります。

特に注意したいのが、PHP 8.2のセキュリティサポートが2026年12月31日で終了する点です。現在PHP 8.2を使っている場合、PHP2Shellの修正版を適用したうえで、年内に8.3以降への移行を計画することをおすすめします。

EOLのPHPを使い続けるリスク

サポートが終了したPHPには、新しい脆弱性が見つかっても公式の修正版が提供されません。PHP2Shellのような重大な脆弱性が見つかったとき、EOLのバージョンを使っているサイトは無防備な状態に置かれてしまいます。

「今は問題なく動いているから」とバージョンアップを先送りにすることは、セキュリティの観点では大きなリスクです。PHPのバージョンアップでは、古い書き方のコードやプラグインが動かなくなることもあるため、余裕を持って計画的に進めることが大切です。

過去の重大事例——CVE-2024-4577では国内でも被害が発生

出典：https://unsplash.com/ja

PHP本体の脆弱性は、実際に日本国内で被害を出したこともあります。代表的なのが、2024年6月に修正されたCVE-2024-4577です。Windows上で動作するPHPに存在したOSコマンドインジェクションの脆弱性で、外部から任意のコードを実行されるおそれがありました。

IPA（情報処理推進機構）によると、この脆弱性は国内の複数の組織で悪用され、該当するWebサービスにWebシェル（サーバを遠隔操作するための不正なプログラム）が設置されていたとの指摘があります。

米国CISAの「悪用が確認された脆弱性」のカタログにも掲載されました。修正版はPHP 8.1.29、8.2.20、8.3.8以降で、それより古い5系・7系・8.0系はサポート終了のため、サポート中のバージョンへの移行が求められました。脆弱性が公表されてから攻撃が始まるまでの期間は年々短くなっており、修正版が出たらすぐに適用する体制を整えておくことが重要です。

PHPアプリで起きやすい代表的な7つの脆弱性と対策

ここからは、PHPで書かれたアプリケーション側で起きやすい代表的な脆弱性と、その対策を紹介します。いずれもIPAの「安全なウェブサイトの作り方」などでも取り上げられている基本的なものばかりで、正しい書き方を知っていれば防げるものです。

①SQLインジェクション

SQLインジェクションとは、入力欄などから不正なSQL文を送り込まれ、データベースの情報を盗まれたり、書き換えられたりする脆弱性です。ユーザーの入力値をそのままSQL文に組み込んでいると発生します。

対策は、PDOなどの「プリペアドステートメント」を使い、入力値をSQL文とは別に渡すことです。

// 安全な書き方（プリペアドステートメント）
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute([':email' => $_POST['email']]);
$user = $stmt->fetch();

②クロスサイトスクリプティング（XSS）

クロスサイトスクリプティングとは、Webページに不正なスクリプトを埋め込まれ、訪問者のブラウザで実行されてしまう脆弱性です。Cookieの盗難や偽の入力画面の表示などに悪用されます。

対策は、ユーザーの入力値を画面に表示するときに、必ずhtmlspecialchars関数でエスケープすることです。

// 出力時に必ずエスケープする
echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8');

③クロスサイトリクエストフォージェリ（CSRF）

CSRFとは、ログイン中のユーザーが罠のページを開いたときに、本人の意図しない操作（退会、送金、設定変更など）を勝手に実行させられる脆弱性です。

対策は、フォームごとに推測できないトークンを発行し、送信時にそのトークンが正しいかを確認することです。Laravelなどのフレームワークには、CSRF対策の仕組みが標準で用意されています。

// トークンの発行（フォーム表示時）
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

// トークンの検証（送信時）
if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'] ?? '')) {
    exit('不正なリクエストです');
}

④OSコマンドインジェクション

OSコマンドインジェクションとは、PHPからサーバのコマンドを実行する処理に不正な文字列を入力され、意図しないコマンドを実行されてしまう脆弱性です。サーバを乗っ取られる深刻な被害につながります。

対策は、exec関数やsystem関数などでOSコマンドを呼び出す処理をできるだけ使わないことです。どうしても必要な場合は、escapeshellarg関数で引数をエスケープし、入力できる値を許可リストで限定します。

⑤ファイルインクルード・ディレクトリトラバーサル

ファイルインクルードやディレクトリトラバーサルとは、ファイル名を外部から指定できる処理を悪用され、意図しないファイルを読み込まれたり、サーバ内の機密ファイルを閲覧されたりする脆弱性です。

対策は、include文やファイル読み込みの処理に、ユーザーの入力値を直接使わないことです。読み込むファイルはあらかじめ許可したものだけに限定し、basename関数でディレクトリ部分を取り除くなどの対策を組み合わせます。

⑥セッション管理・パスワード管理の不備

セッションIDを推測されたり、ログイン前後で同じセッションIDを使い続けたりすると、他人になりすまされるおそれがあります。ログインに成功したら、session_regenerate_id関数でセッションIDを新しく発行し直しましょう。

また、パスワードは平文や古いハッシュ方式で保存せず、password_hash関数とpassword_verify関数を使って安全に保存・照合します。

// パスワードの保存と照合
$hash = password_hash($password, PASSWORD_DEFAULT);
if (password_verify($input, $hash)) {
    session_regenerate_id(true); // ログイン成功時にセッションIDを更新
}

⑦安全でないデシリアライズ

PHPのunserialize関数に、外部から受け取ったデータをそのまま渡すと、不正なオブジェクトを作られて意図しない処理を実行されるおそれがあります。外部とデータをやりとりする場合は、unserialize関数ではなく、json_encode関数とjson_decode関数を使うのが安全です。

PHPの代表的な脆弱性と対策のまとめ表

ここまで紹介した脆弱性と対策を一覧表にまとめました。自社のサイトやシステムのチェックにご活用ください。

WordPressなどCMSを使っている場合の注意点

出典：https://unsplash.com/ja

WordPressなどのCMSを使っている場合は、PHP本体に加えて、CMS本体、テーマ、プラグインの3つを最新に保つことが重要です。実際の攻撃では、PHP本体よりも、更新されずに放置されたプラグインやテーマの脆弱性が狙われるケースが多く見られます。

使っていないプラグインやテーマは削除し、更新が長期間止まっているプラグインは代替を検討しましょう。また、PHPのバージョンを上げる前には、テスト環境でサイトが正常に動くかを確認しておくと安心です。古いプラグインが新しいPHPに対応しておらず、バージョンアップ後に画面が真っ白になるといったトラブルを防げます。

脆弱性対策を続けるための運用のポイント

PHPの脆弱性対策は、一度やれば終わりではありません。新しい脆弱性は次々と見つかるため、継続的に情報を集め、すばやく対応できる体制をつくることが大切です。

情報収集の手段としては、PHP公式サイトのリリース情報、IPAやJPCERT/CCの注意喚起、脆弱性情報データベースのJVNなどが役立ちます。社内に担当者を決めて、重要な情報を見落とさない仕組みをつくりましょう。あわせて、不正なリクエストを遮断するWAF（Webアプリケーションファイアウォール）の導入や、専門家による定期的な脆弱性診断も有効です。アクセスログを改ざんされにくい形で保管しておくと、万一攻撃を受けたときの調査にも役立ちます。

よくある質問（FAQ）

まとめ：PHPの脆弱性対策は「本体の更新」と「安全なコード」の両輪で

PHPの脆弱性には、PHP本体に含まれるものと、PHPで書かれたアプリケーションに含まれるものの2種類があります。

2026年10月に修正された「PHP2Shell」は、認証なしで外部から任意のコードを実行されるおそれがある緊急の脆弱性で、PHP 8.5.12、8.4.27、8.3.36、8.2.35以降への更新が強く推奨されています。

PHP 8.1以前を使っている場合や、2026年末でサポートが終わるPHP 8.2を使っている場合は、サポート中のバージョンへの移行もあわせて進めましょう。

アプリケーション側では、SQLインジェクション、クロスサイトスクリプティング、CSRFなどの典型的な脆弱性を、決まった書き方で確実に防ぐことが基本です。PHP本体の更新と安全なコード、そして継続的な情報収集と運用体制。この3つをそろえることが、PHPで動くWebサイトとお客様の情報を守るいちばんの近道です。