PHPの重大な脆弱性「PHP2Shell」（CVE-2026-109618／CVE-2026-109619）：影響範囲、修正版、確認方法とパッチ手順

この記事の要点（経営者向け）

本記事の情報は、2026年10月22日午前（日本時間）時点のものです。各社の対応状況は刻々と変わるため、最新の状況は末尾の出典をご確認ください。

• 何が起きたか

  PHPの開発チームは10月21日、重大な脆弱性2件（CVE-2026-109618とCVE-2026-109619、通称「PHP2Shell」）を修正したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開しました。悪用されると、ログインなしで外部からサーバー上のコードを実行されるおそれがあります。深刻度はいずれもCVSS v4.0で9.2（緊急）です。^[1][2][3]

• 誰が影響を受けるか

  PHP-FPM、ApacheのPHPモジュール（mod_php）、php-cgi、FrankenPHP、LiteSpeedなど、Webのリクエストを処理するすべてのPHPが対象です。WordPress、Drupal、Joomla、Magento、Laravelなどで作られたサイトも、動いているPHPが古ければ影響を受けます。アプリやプラグインを更新しても直りません。^[1][4][5]

• 悪用の状況

  情報は修正版の公開前に漏れており、CloudflareやwatchTowrは攻撃の通信を観測したと報告しています。Patchstackも、提携するホスティング会社から悪用の報告を受けたとしています。一方、米CISAとカナダのサイバーセキュリティセンターは、公表時点で悪用を確認していないとしています。CISAの「悪用が確認された脆弱性（KEV）」カタログには、本記事の確認時点で登録されていません。^{[5][6][4][7][8][9]}

• 今日やること

  自社と委託先が運用するPHPをすべて洗い出し、インターネットに公開しているものから修正版（またはOSベンダーの修正パッケージ）に更新し、PHPのプロセスを再起動してください。PHP 8.1以前は公式の修正版がなく、移行かベンダーの修正が必要です。すぐ更新できない場合は、CISAなどが一時的な停止や切り離しも選択肢に挙げています。^[7][10]

動画で解説（約5分）

PHP2Shellの仕組みと、確認から更新までの流れを、約5分の図解動画にまとめました。日本語のナレーションに、日本語と英語の字幕を付けています。詳しい手順と出典は、このあとの本文をご覧ください。

今日やること：5つのステップ

CISA、英国NCSC、CERT-EU、IPAの推奨を、実務の順番に並べ直しました。技術的な作業は担当者や委託先が行いますが、経営者は各ステップが終わったかを確認できます。^{[7][11][10][12]}

1. 01洗い出す：PHPで動いているサイトやシステムを一覧にします。コーポレートサイト、キャンペーンサイト、採用サイト、問い合わせフォーム、社内の管理画面、検証環境、委託先が運用するサイトまで含めます。PHPは製品や機器の内部に組み込まれていることもあり、利用者からは見えない場合があります。^[12][7] 自社のドメインにどんなサイトがあるか分からない場合は、ZeroKaiの無料パッシブ評価で、証明書の公開ログに記録されたホスト名を一覧にできます。
2. 02優先順位をつける：インターネットから届くものを最優先にします。ApacheのPHPモジュール（mod_php）は、開発チームが最もリスクが高いとしている構成です。^[1][7]
3. 03更新する：PHP 8.5.12、8.4.27、8.3.36、8.2.35のいずれか、またはOSベンダーやホスティング会社の修正パッケージに更新します。手順は後述の「環境別のパッチ手順」をご覧ください。^[1]
4. 04再起動して確かめる：更新しただけでは、動いているPHPのプロセスは古いままです。PHP-FPMやApacheを再起動し、コンテナはイメージを作り直して入れ替えます。そのうえで、Webで実際に動いているPHPのバージョンやパッケージを確認します。^[13][14]
5. 05侵害がないか確かめる：修正前に攻撃を受けていた可能性があるため、後述の「侵害の兆候を調べる」に沿ってログとプロセスを確認します。英国NCSCも、更新前の侵害の有無を確認し、攻撃者が残したバックドアを探すよう求めています。^[11]

PHP2Shellとは何か

PHP2Shellは、PHP本体（インタープリター）のメモリ管理とエラー処理にある欠陥です。特定のアプリやプラグインではなくPHPそのものの問題のため、PHPで動くほぼすべてのWebサイトに関係します。^[15][16] 2件の脆弱性は次のとおりです。

• CVE-2026-109618（GHSA-w8hw-w9fx-j79w）「メモリ不足時の破損によるRCE」：リクエストの処理中にメモリの上限（memory_limit）に達すると、PHPは処理を途中で打ち切ります。そのとき、まだ準備が終わっていない内部データが残り、後片付けの処理がそれを正しいデータとして扱ってしまいます。細工したフォーム送信（multipart）などで意図的にこの状態を起こせます。^[2]
• CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）「古い状態の再利用によるRCE」：PHPのワーカープロセスは多くのリクエストを順に処理します。致命的なエラーなどでリクエストが途中で終わると、解放済みのメモリを指す内部状態が残り、同じワーカーが処理する次のリクエストがそれを使ってしまいます（解放後の使用、use-after-free）。ファイルアップロードの進捗表示機能（session.upload_progress）を経由する経路が確認されています。^[3]

影響は、Webサーバーの実行ユーザーの権限でのコード実行、プロセスのメモリの読み取り、サービス停止です。報告者のWizは、コード実行に至らなくても、ワーカーのメモリからパスワード、トークン、APIキーなどを読み取れることを実証しています。^[3][16][17]

深刻度について：PHPのセキュリティチームは、2件ともCVSS v4.0で9.2（緊急）と評価しています。攻撃の難しさは「高」とされていますが、認証も利用者の操作も不要です。公開前に出回ったCVSS 10.0という数字は誤りだと開発元が説明しています。Red Hatは自社製品への影響を「重要（Important）」と評価しています。^[2][15][18]

影響を受ける環境

PHPの開発チームは「Webのリクエストを処理するすべてのPHP」が危険にさらされているとしています。構成によってリスクの高さは異なります。^[1][2][3]

• Apache＋mod_php：最もリスクが高い構成です。2件とも、既定の設定で認証なしのリモートコード実行が実証されています。^[2][3]
• PHP-FPM（nginxやApacheと組み合わせる一般的な構成）：CVE-2026-109619は、アプリ側の条件が整えばリモートコード実行が実証されています。CVE-2026-109618は、ソースコードの分析から影響を受けるとされていますが、完全な攻撃はまだ実証されていません。^[2][3]
• FrankenPHP、LiteSpeed（LSAPI）、php-cgi：影響を受けるとされています。FrankenPHPはmod_phpと同様の動きをするため、アプリに依存しない攻撃を受けやすいと分析されています。^[2][1]
• WordPressなどのCMS：Wizは、最新のWordPress、Drupal、Joomlaのコンテナイメージに対して、認証なしのリモートコード実行を実証しました。CMS本体やプラグインの更新では直らず、PHPの更新が必要です。^[16][5]
• 製品や機器に組み込まれたPHP：管理画面などにPHPを使っている製品や機器もあります。IPAは、まず製品のマニュアルや提供元のセキュリティ情報を確認するよう呼びかけています。オランダNCSCは、PHPを使っている可能性のある製品の一覧を公開しています。^[12][11] 例えばPleskは、管理パネル自体が使うPHP（sw-engine）も修正の対象だとしています。^[19]
• コマンドラインだけで使うPHP：バッチ処理などWebに公開していない用途は、外部から直接攻撃される経路にはなりにくいものの、更新の対象です。^[20]

規模の目安として、W3Techsの調査ではサーバー側の言語が分かるWebサイトの69.3%がPHPを使っています。インターネットに公開されている影響を受けうるホストの数は、推計によって大きく異なります。^[21]

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

PHPの公式アドバイザリとNVDに記載された、サポート中のブランチごとの影響範囲と修正版は次のとおりです。^{[2][3][22][17]}

サポートが終了した古いブランチについて：PHP 8.1以前には、PHPプロジェクトから公式の修正版は出ません。深刻さを考慮して、セキュリティチームはPHP 7.4、8.0、8.1向けに、ソースからビルドする人のための最小限の修正（バックポート）を公開しました。PHP 5.4〜7.3には、PHPプロジェクトからの修正はありません。報告者のWizは、PHP 5.4以降のほぼすべてのバージョンが少なくとも1件の影響を受けるとしています。^[1][21][16]

• 古いPHPを使っている場合の選択肢は、OSベンダーやLTSベンダー（Ubuntu Pro、AlmaLinux、cPanel、Pleskなど）の修正パッケージを使うか、サポート中のブランチに移行するかです。^{[1][25][26][27][19]}
• CISAは、すぐに更新できない場合や、PHP 8.1以前を使い続ける場合は、更新できるまでそのシステムをオフラインにするよう求めています。^[7]

OS・プラットフォームごとの修正パッケージ

• Ubuntu：サポート中のすべてのリリースで修正済みです。22.04はphp8.1 8.1.2-1ubuntu2.28、24.04はphp8.3 8.3.6-0ubuntu0.24.04.13、26.04はphp8.5 8.5.4-0ubuntu1.5、26.10はphp8.5 8.5.9-0ubuntu2.1以降です。20.04以前はUbuntu Pro（ESM）で提供され、Ubuntu Proは5台まで無料です。自動更新（unattended-upgrades）が有効でも、PHPを使うサービスの再起動は必要です。^[14][28][25]
• Debian：12（bookworm）はphp8.2 8.2.35-1~deb12u1（DLA-4848-1）、13（trixie）はphp8.4 8.4.27-1~deb13u1（DSA-6574-1）で修正されています。セキュリティ用のリポジトリが有効になっているか確認してください。^[29]
• Red Hat Enterprise Linux：RHEL 8、9、10とOpenShift Dev Spaces 3が影響を受けます。Red Hatは影響度を「重要（Important）」とし、修正を順次公開中です。RHELの標準構成はPHP-FPMで、mod_phpより悪用が難しいとしています。RHELやUBIをもとにしたコンテナも、ベースイメージの更新後に作り直す必要があります。^[18]
• AlmaLinux：8、9、10のすべてのPHPストリーム（サポートが終了したストリームを含む）の修正版が、10月21日（UTC）に本番リポジトリで公開されました。例えばAlmaLinux 10の標準PHP 8.3は php-8.3.33-1.el10_2.alma.1、AlmaLinux 9の標準PHP 8.0は php-8.0.30-8.el9_8.alma.1 です。確認には「rpm -q php-common」を使い、php -vには頼らないよう案内しています。AlmaLinux 8は、ストリームを選ばずに入れた場合の標準がPHP 7.2です。^[26]
• Rocky Linux（CIQ）：CIQは、有償版の一部（RLC Pro LTS 9.6と9.2）で修正パッケージを公開し、ほかは準備中としています。コミュニティ版のRocky Linuxは、Rocky Linuxのエラッタを確認してください。^[20]
• AWS：Amazon Linuxの修正パッケージは10月22日に公開予定です。Elastic Beanstalkは10月21日に更新したPHPプラットフォーム（v4.13.12）を公開しました。Lightsailは稼働中のインスタンスをAWSが更新できないため、更新されたブループリントから新しいインスタンスを作って移行する必要があります。^[17]
• Docker（公式PHPイメージ）：8.5.12、8.4.27、8.3.36、8.2.35のタグが公開されています。イメージを指定し直して作り直し、動いているコンテナを入れ替えてください。^[30][13]
• Homebrew（開発用のMacなど）：php、php@8.4、php@8.3、php@8.2はそれぞれ修正版に更新済みです。php@8.1は8.1.34のままで、非推奨とされています。^[31]
• Windows：修正版のバイナリはPHPのダウンロードページで公開されています。^[1]
• cPanel（EasyApache 4）：ea-php74（7.4.33-19）、ea-php80（8.0.30-12）、ea-php81（8.1.34-5）、ea-php82〜85（8.2.35、8.3.36、8.4.27、8.5.12）が修正済みです。7.4より古いPHPには、TuxCareの延長サポートを使うよう案内しています。CloudLinuxが提供するPHPは、CloudLinuxの情報を確認してください。^[27]
• Plesk：Plesk提供のPHP 8.2〜8.5は修正版に更新済みです。サポート終了の7.4、8.0、8.1はバージョン番号が変わらず、2026年10月21日にビルドされたものが修正版です。Plesk自体の管理画面が使うPHP（sw-engine）は、Plesk Obsidian 18.0.81 Update 4で修正され、18.0.80向けは準備中としています。^[19]
• Remiのリポジトリ（rpms.remirepo.net）：PHPの開発チームは、公開当日には更新がないとして、ディストリビューションのパッケージへの切り替えか、ソースからのビルドを呼びかけています。^[1]

自社が影響を受けるかの確認方法

1. 01外から見える範囲を把握する：インターネットに公開しているサイトの一覧を作ります。英国NCSCは、古いバージョンに限らず、PHPを使うものをすべて洗い出すよう求めています。^[11] 一覧づくりには、ZeroKaiの無料パッシブ評価が使えます。証明書の公開ログから自社ドメインのホスト名を集め、忘れられがちなサブドメインも含めて一覧にします。
2. 02サーバーごとにパッケージを確認する：Ubuntuでは「apt list '?installed ?name(^php[0-9.]+$)'」、AlmaLinuxなどRHEL系では「rpm -q php-common」、cPanelでは「rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618」（php81は確認するバージョンに置き換え）で確認できます。前節の修正済みの版数と比べてください。^[14][26][27]
3. 03動かし方（SAPI）を確認する：mod_phpは最もリスクが高い構成です。AlmaLinux 8では「httpd -M 2>/dev/null | grep -E 'mpm_|php'」の結果にmpm_prefork_moduleとphp_module（またはphp7_module）があればmod_phpです。^[26][1]
4. 04WordPressのサイト：管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPのバージョンを確認できます。ただし、共用サーバーではバックポートのため版数だけでは判断できないことがあるので、サーバー会社のお知らせもあわせて確認してください。^[32]
5. 05コンテナ：PHPを含むイメージと、そのもとになっているイメージを洗い出します。アプリが独自にPHPを同梱している場合もあります。^[13]
6. 06製品・機器・外部サービス：PHPを組み込んだ製品は、提供元の情報を確認します。オランダNCSCがPHPに依存する製品の一覧をGitHubで公開しています。^[12][11][20]

環境別のパッチ手順

どの環境でも、更新したあとにPHPのプロセスを再起動するまでは古いコードが動き続けます。長時間動くコマンドラインのPHP処理も再起動してください。^[14][20]

• Ubuntu・Debian：「sudo apt update && sudo apt upgrade」で更新し、PHP-FPM（例：php8.3-fpm）またはApache（mod_phpの場合）を再起動します。PHPだけを更新する場合は「sudo apt install --only-upgrade '?name(^php[0-9.]+$)'」も使えます。迷う場合はサーバーを再起動すれば確実です。^[14]
• AlmaLinux・Rocky Linux・RHEL：「sudo dnf clean metadata && sudo dnf upgrade 'php*'」で更新し、「sudo systemctl restart php-fpm」（mod_phpの場合は httpd）で再起動します。サポートが終了したストリームを使っている場合は、アプリの動作を確認したうえで、サポート中のストリームへの移行も計画してください。^[26][20]
• cPanel：WHMからcPanelを更新するか、「yum clean all && yum makecache」のあと「/scripts/rpmup」を実行します。^[27]
• Plesk：Pleskの更新でPHPと管理画面（sw-engine）を更新し、「ツールと設定」→「PHP設定」でバージョンを確認します。Linuxでは「/opt/plesk/php/8.3/bin/php -v」のように、バージョンごとに確認できます。^[19]
• コンテナ：Dockerfileのベースイメージを修正版のタグに変えて作り直し、すべての環境で入れ替えます。古いイメージから起動したコンテナが残っていないか確認してください。^[13][30]
• ソースからビルドしている場合：php.netから修正版を入手します。PHP 7.4、8.0、8.1は、セキュリティチームが公開した最小限のバックポートを適用できますが、恒久的な対策としてはサポート中のブランチへの移行が必要です。^[1]
• クラウドの管理サービス：Elastic Beanstalkはプラットフォームを更新し（マネージド更新が有効なら次のメンテナンス時間に自動適用）、Lightsailは更新されたブループリントから作り直します。^[17]
• 共用レンタルサーバー：PHPの更新はサーバー会社が行います。お知らせで対応状況を確認し、管理画面で古いPHPを選んでいる場合は、サポート中のバージョンに切り替えてください。^[5][33]

日本の状況：公的機関とレンタルサーバー各社

IPAは10月21日、修正版の公開に先立って事前準備を呼びかける注意喚起を出しました。PHPを使うプログラムの棚卸しを求め、サポートが終了した古いPHPを使い続けているサイトも見られると指摘しています。発信時点で、IPAは悪用を確認していないとしています。^[12] 本記事の確認時点（10月22日午前）では、JPCERT/CCの注意喚起とJVNに本件の掲載は見当たりませんでした。^[34]

• エックスサーバー：10月21日16時から公式サイトや管理画面を予防的に止めました（不正アクセスによるものではないとしています）。22日6時45分の更新で、PHP 8.2〜8.5は対象のすべてのサーバーへの修正の適用を終え、古いバージョンは準備ができたものから順に適用中としています。^[35]
• さくらインターネット：さくらのレンタルサーバやマネージドサーバなどで、10月21日23時から22日6時30分まで、PHPのバージョンアップのための緊急メンテナンスを行い、完了しました。古いPHPを使っている人にはPHP 8.3の利用を求めています。^[33]
• KAGOYA：レンタルサーバープランでPHP 8.2〜8.5を使っている人には、修正版を確認したうえで順に更新するとしています。そのほかのプランやバージョンは、対応方針を調整中としています（10月21日時点）。^[36]
• そのほかの各社：AB通信のまとめでは、ロリポップ！はPHPの脆弱性への予防措置としてメンテナンスを行ったと明記し、ConoHa WINGやお名前.comなどはPHPに触れずに「システムの保守作業」などとしてメンテナンスを告知しています。自社が契約しているサーバー会社のお知らせを確認してください。^[32]

共用のレンタルサーバーでは、PHPの更新はサーバー会社の仕事ですが、サイトの中身（WordPressのプラグインや独自のプログラム）と、管理画面で選ぶPHPのバージョンは利用者側の責任です。VPSや専用サーバー、クラウドのサーバーでは、PHPの更新も利用者側で行う必要があります。^[32][5]

すぐ更新できない場合の緩和策

• CVE-2026-109618向け：memory_limitを-1にし、アプリが上書きできないよう php_admin_value で設定します。ほかの設定で上限が戻っていないかも確認します。代わりに、コンテナやcgroupのメモリ上限で、できれば問題のワーカーだけが止まるようにします。RLIMIT_ASやRLIMIT_DATAは、かえって脆弱な処理を引き起こすため使わないでください。^[1][2][26]
• あわせて、post_max_sizeを小さくします（アップロード不要なら8M、必要なら32M、upload_max_filesizeはそれ未満）。Webサーバーやプロキシで、リクエストの大きさ、入力項目の数、multipartのパート数、ヘッダー数、入れ子の深さを制限します。Content-Lengthがないリクエストも対象にしてください。^[1]
• CVE-2026-109619向け：session.upload_progress.enabled を0にします。使っていなければ、修正後もオフのままにすることを開発チームは勧めています。PHP 8.5では fatal_error_backtraces も0にします。リクエストごとに適用している無効な設定や非推奨の設定（.htaccessやPHP_VALUEなど）を取り除きます。エラーの表示や記録を止めても効果はありません。^[1][3]
• アップロードを使わないアプリでは、multipart/form-dataのリクエストをPHPに届く前に止める方法もあります。CIQは、PHP 8.4以降はPOST以外のメソッドでもmultipartを解析できるため、POSTだけに絞らないよう注意しています。性能に余裕があれば、PHP-FPMの pm.max_requests を1にして、ワーカーをリクエストごとに入れ替える方法も挙げられています。^[2][3][20]
• 使っていないPHPは止める：PHPが入っていても使っていないサーバーでは、PHP-FPMやmod_phpを止めます。^[20]
• WAF：CISAは、WAFが更新までの間ある程度の防御になりうるとしています。Cloudflareは10月21日（UTC）から、無料プランを含むWAFで既定で防御ルールを有効にしています。ただし、Cloudflareを経由しない直接のアクセスを受け付けるサーバーでは効果がありません。AWS WAFでは、AWSが本文8KB超を止めるルールと、CVE-2026-109619向けのカスタムルールを公開しています。WAFが大きなリクエスト本文を最後まで検査できるかも確認してください。^{[7][5][4][17][13]}
• 切り離す：CISAと英国NCSCは、すぐ更新や緩和ができない場合、システムをオフラインにすることも検討するよう求めています。CERT-EUは、インターネットに公開しているアプリの隔離を勧めています。^[7][11][10]

侵害の兆候を調べる

攻撃はアプリより下の層で起きるため、アプリのログにはほとんど痕跡が残らないことがあります。Datadogは、リクエスト、PHPのエラーログ、Webサーバーが起動したプロセスの3つの層を組み合わせて調べるよう勧めています。どれか1つだけでは決め手になりません。^[13][16]

• リクエスト

  異常に大きなフォーム送信、極端に長い項目名（Datadogの検証では約3.5MB）、ヌルバイトなどの制御文字を含む値、ヘッダーが大量にあるmultipartや空のファイル項目が多数あるリクエスト。^[13][26]

• PHPのエラーログ

  「Allowed memory size of … bytes exhausted … in Unknown on line 0」というメモリ不足のエラー。「Unknown on line 0」は、スクリプトが動く前のリクエスト初期化中に失敗したことを示します。繰り返されるHTTP 500も手がかりです。^[13][16]

• Webサーバーのログ

  Apacheのエラーログの「AH00052: child pid … exit signal Segmentation fault (11)」など、ワーカーのクラッシュ。説明のつかないワーカーの再起動。^[13][16]

• レスポンス

  異常に大きい、または形の崩れたPHPSESSIDのCookie。メモリの中身が漏れているおそれがあります。^[16]

• プロセス

  PHPのワーカーやApacheがシェル（sh、bashなど）を起動している、ツールをダウンロードしている、外部へ通信している。最も直接的な侵害の証拠です。^[13][7]

• CVE-2026-109619の手がかり

  リクエスト初期化時の設定に関する警告、終了処理中の警告、致命的エラー、実行時間切れが、攻撃者が触れられる経路で起きていないか。^[3][13]

侵害が疑われる場合の対応

1. 01サーバーをネットワークから切り離し、被害の広がりを止めます。^[11][10]
2. 02作り直す前に、Webサーバー、PHP、OSのログを保全します。調査や報告に必要になります。
3. 03攻撃者が残したバックドアを探します。英国NCSCは、更新前に侵害がなかったかを調べ、バックドアを探すよう求めています。^[11]
4. 04サーバーが持っていたパスワード、APIキー、トークン、証明書の鍵を交換します。今回の脆弱性ではメモリの中身が漏れるおそれがあるためです。^[16][4]
5. 05侵害が確認された場合は、信頼できる状態からサーバーを作り直し、修正版を適用してからネットワークに戻します。
6. 06自社で調べきれない場合は、インシデント対応の専門会社に相談します。個人情報が漏れた可能性がある場合は、報告や通知の義務がないか、弁護士などの専門家に確認してください。^[11]
7. 07ほかの入口も確認します。ZeroKaiでは、所有権を確認したドメインについて、Shodanが観測したリモートアクセス（RDPなど）、ファイル共有、データベース、FTPのサービスがインターネットに公開されていないかを表示します。

経緯

悪用の状況とリスクの見方

• watchTowrは、自社のハニーポット網で10月21日に悪用を観測したとしています。Cloudflareは攻撃の通信と、防御を回避しようとする攻撃コードの変化を観測しました。Datadogは、悪用の報告が複数あり、無差別なスキャンも広く行われているとしています。^[6][5][13]
• Patchstackは、提携するホスティング会社から悪用の報告を受けた一方、修正版の公開直後の時点では、自社の観測では探りの攻撃だけで、侵害の確かな証拠はまだないとしていました。^[4]
• CISAとカナダのサイバーセキュリティセンターは公表時点で悪用を確認しておらず、IPAも攻撃を確認していないとしていました。本記事の確認時点で、CISAのKEVカタログには登録されていません。^{[7][8][12][9]}
• 攻撃の難しさ：PHPの評価では攻撃の複雑さは「高」で、成功させるにはメモリ配置の調整や、同じワーカーに複数のリクエストを届けることが必要です。一方Wizは、AIを使うことで、こうした調整の手間が大きく下がったと指摘しています。CIQは、オランダNCSCが近いうちに大規模な悪用が起きる可能性が高いと見ていると紹介しています。^{[2][3][16][20]}

まとめると、「すでに大規模な被害が出ている」とは確認されていませんが、攻撃は始まっており、条件がそろえば認証なしで乗っ取られうる脆弱性です。インターネットに公開しているPHPは、今日中の更新を目標にするのが妥当です。

よくある質問

印刷用チェックリスト

• 自社と委託先が運用する、PHPを使うサイト・システム・製品を一覧にした
• インターネットに公開しているもの、mod_phpを使うものを最優先にした
• 修正版（8.5.12／8.4.27／8.3.36／8.2.35）またはベンダーの修正パッケージに更新した
• PHP-FPM・Apacheを再起動し、コンテナを作り直して入れ替えた
• パッケージの版数で、修正が入ったことを確認した（php -vだけで判断していない）
• レンタルサーバー会社・製品の提供元のお知らせを確認した
• PHP 8.1以前は、修正パッケージの適用か移行、または切り離しを決めた
• 更新できないものに、緩和策とWAFを適用した（時間稼ぎと理解したうえで）
• ログとプロセスで侵害の兆候を確認した
• 兆候があったサーバーの認証情報を交換した
• 不要になった緩和策の扱いを決め、PHP 8.2はサポート終了（2026年12月31日）前の移行を計画した

ZeroKaiでできること

今回のような脆弱性で最初につまずくのは、「どこにPHPのサイトがあるか分からない」ことです。ZeroKaiは、ドメインを入力するだけで、証明書の透明性ログに記録されたホスト名を一覧にし、管理画面や検証環境に見える名前を目立たせます。所有権を確認したドメインでは、Shodanが観測したリモートアクセス、ファイル共有、データベース、FTPといった公開サービスも表示します。SPFやDMARCなどメールとDNSの設定も確認できます。コンソールでは、CISAのKEVカタログやJVN iPediaの脆弱性情報も参照できます。