PHPの重大な脆弱性「PHP2Shell」（CVE-2026-109618・109619）｜業務システムで確認すること・修正版・8.1以前の対応【2026年10月】

2026年10月21日（日本時間23時ごろ）、PHPに2件の重大な脆弱性が公表され、修正版が公開されました。「PHP2Shell」と呼ばれるこの脆弱性は、ログインなしで外部からサーバー上のプログラムを実行される可能性があるもので、国内でも公表前後に多くの企業・自治体がWebサービスを予防的に停止しました。

この記事では、PHPで動く業務システムやWebサイトを持つ企業の担当者向けに、脆弱性の概要、修正版の一覧、自社で確認すべきこと、すぐに更新できない場合の暫定策、修正版が出ないPHP 8.1以前のシステムの扱いを整理します。情報は2026年10月23日時点のものです。

PHP2Shellとは

PHP2Shellとは、2026年10月21日に公表された、PHP本体の2件のリモートコード実行の脆弱性（CVE-2026-109618・CVE-2026-109619）の通称です。悪用されると、PHPを実行しているプロセスの権限で、攻撃者が任意のプログラムを動かせる可能性があります。

PHPは世界中のWebサイトや業務システムで使われているため、影響の範囲が非常に広いのが特徴です。公表前の10月17日には、攻撃を試みる通信がすでに観測されていたと報じられています。国内では、公表の前後に200を超える組織がサービスの全部または一部を予防的に止めました。

修正版と、修正版が出ないバージョン

無料ツール業務システムのサポート期限カレンダー｜OS・Office・DB・言語の終了日一覧【毎月更新】

自社で確認すべきこと（環境別）

やるべきことは、PHPがどこで、誰の管理のもとで動いているかによって変わります。

• どのサーバーでPHPが動いているかを洗い出す：公開サイトだけでなく、社内システム、取引先向けポータル、検証環境、使っていない古いサイトも対象です
• PHPのバージョンと動かし方を確認する：WordPressなら「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。phpinfoを置いた場合は、確認後すぐに削除します
• 修正の完了を確認する：修正版への更新、またはサーバー会社・委託先の完了告知を確認します
• 侵害の痕跡を確認する：更新前に攻撃を受けていないかを確認します（下の章を参照）
• 8.1以前のシステムの移行を計画する：今回しのげても、今後の脆弱性には修正が出ません

関連記事PHPバージョンアップの必要性と費用・進め方

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

PHPの開発チームは、更新までの間に攻撃の経路を減らす設定を案内しています。ただし、これらは特定の攻撃経路を防ぐだけで、安全になるわけではありません。根本的な対策は修正版への更新だけです。

• session.upload_progress.enabled を 0 にする：php.ini、PHP-FPMのプール設定、サーバー設定で指定し、すべてのワーカーを再起動します。アプリケーション内の ini_set() や .user.ini では間に合いません
• post_max_size を小さくする：ファイルのアップロードがなければ8M、必要なら32Mを目安にし、upload_max_filesize はそれより小さくします
• memory_limit を -1 にする：アプリケーションから上書きできない方法（FPMの php_admin_value など）で指定します
• PHP 8.5では fatal_error_backtraces を 0 にする：確認されている攻撃経路の1つを防ぎます
• WAFのルールを有効にする：一部のCDN・WAFサービスは、既知の攻撃パターンを防ぐルールを提供しています

不正アクセスの痕跡を確認する

JPCERT/CCは、修正を当てるだけでなく、すでに侵害されていないかを確認するよう呼びかけています。主な確認ポイントは次のとおりです。

• Cookie：過去のレスポンスで、PHPSESSID に異常に長い値や不正な形式の値が設定されていないか
• リクエスト：不審な multipart/form-data のリクエストがないか。その前後に、メモリ上限のエラーやHTTP 500エラーが出ていないか
• プロセス：PHPのワーカーが予期せず異常終了したり、頻繁に再起動したりしていないか
• その他：見覚えのない管理者アカウント、改ざんされたページ、不審なファイル、外部への不審な通信、Search Console の警告がないか

痕跡が見つからなくても、攻撃を受けていないとは言い切れません。侵害が疑われる場合は、ログなどの証拠を保全したうえで影響範囲を調べ、必要に応じてシステムを隔離します。

関連記事システム障害の対応フローと再発防止策

PHP 8.1以前の業務システムをどうするか

今回、PHP 7.4・8.0・8.1には例外的に修正コードが公開されましたが、今後の脆弱性でも同じ対応がある保証はありません。古いPHPで動く業務システムは、次の順で検討するのが現実的です。

1. 現状を把握するPHPのバージョン、使っているフレームワーク・ライブラリ、改修できる人がいるかを確認する
2. 当面の安全を確保するサーバー会社・保守会社の修正を確認し、外部からのアクセスをVPNやIP制限で絞れないか検討する
3. バージョンアップの影響を調べる8.3以降で動かしたときに、エラーになる箇所や改修が必要な範囲を洗い出す
4. 改修か作り直しかを決める改修範囲が広い、仕様書がない、担当者がいないといった場合は、システムの置き換えも含めて比較する

小さなPHPのバージョンアップなら数週間で済むこともありますが、古いフレームワークを使っている場合は、フレームワークの更新も必要になり、期間と費用が大きくなりがちです。PHP 8.2も2026年12月31日にサポートが終了するため、まとめて8.3以降への移行を計画するのがおすすめです。

関連記事レガシーシステムとは？放置するリスクと脱却の方法

関連記事システム保守の引き継ぎ（乗り換え）の進め方と注意点

関連記事PHPのバージョン確認方法｜WordPress・サーバー管理画面・コマンドでの調べ方と結果の読み方

関連記事PHP 8.2のサポート終了は2026年12月31日｜影響と8.3・8.4への移行手順・スケジュール例

関連記事Webサイトの改ざん・不正アクセスの確認方法と初動対応｜症状・調べ方・個人情報保護委員会への報告と相談窓口

よくある質問

まとめ

PHP2Shellは、ログイン不要でサーバー上のコードを実行される可能性がある重大な脆弱性です。PHP 8.2〜8.5は修正版へ更新し、8.1以前は提供元の独自修正を確認したうえで、サポート中のバージョンへの移行を計画しましょう。更新とあわせて侵害の痕跡を確認し、古いPHPで動くシステムは、今回を機に今後の保守の体制まで見直すことが大切です。

参考：PHP公式「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）、JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（2026年10月22日）、Rapid7の技術解説、各レンタルサーバー会社の告知。

関連記事中小企業の業務システムに必要なセキュリティ対策