PHPの重大な脆弱性「PHP2Shell」について、実際の攻撃への悪用が確認されています。PHPは、WordPressなどのWebサイトをサーバー上で動かすソフトウェアです。自社サイトの担当者がまず確かめたいのは、WordPressを更新したかではなく、そのサイトで動くPHPに修正が適用されたかです。
修正版は2026年10月21日に公開されました。その後、2件の脆弱性は米国CISAの「悪用が確認された脆弱性」の一覧に掲載され、11月3日にはシンガポールの政府機関CSAが、特定のファイアウォール製品への攻撃について注意を呼びかけています。IPAの注意喚起、CSAの11月3日の発表
ただし、PHPを使うすべてのサイトで侵入が確認されたわけではありません。この記事では、11月7日に確認した公式情報をもとに、Web事業者が自社への関係と対応状況を確かめる方法を整理します。
PHP2Shellで何が起きるのか
PHP2Shellは、PHP本体の2件の脆弱性、CVE-2026-109618とCVE-2026-109619の通称です。メモリ不足時の処理や、処理を終えた後に残る内部データの扱いに問題があり、条件がそろうと、ログインしていない第三者がサーバー上で不正なプログラムを動かせるおそれがあります。PHP公式のセキュリティ告知
実行されるのはPHPの実行プロセスが持つ権限の範囲です。Webページの改ざんや、その権限で読み取れるデータへの不正アクセスにつながる可能性があります。「悪用されたら必ずサーバーの最高権限を奪われる」という意味ではありません。JPCERT/CCの注意喚起
WordPress本体、テーマ、プラグインの更新は引き続き大切ですが、PHP本体の更新とは別の作業です。サイトの見た目や管理画面が正常でも、PHPの修正が済んでいるとは判断できません。
図はWebサイトの構成を簡略化したものです。上からサイト・CMS、それを動かすPHP、サーバーの基盤を表しています。PHP2Shellの修正対象は、真ん中のPHPです。
自社に関係するのは、どんな場合？
確認が必要なのは、主に次のような環境です。
- WordPressなどのCMSを使うサイト。 CMSだけでなく、PHPの修正状況を確認します。
- PHPで作られた独自のECサイト、会員サイト、予約システム、問い合わせフォーム。 トップページが静的なページでも、別の機能でPHPを使っている場合があります。
- PHPを内部に組み込んだ業務製品やネットワーク機器。 自社でPHPをインストールした覚えがなくても、製品の管理画面などで使われていることがあります。
PHP公式は、Webリクエストを処理するPHP全般を確認対象とし、特にApacheのmod_phpという実行方式を高リスクとしています。攻撃が実際に成立するかは、PHPの版、設定、実行環境などにも左右されます。実行方式だけを理由に対応不要と判断せず、修正適用の有無を確認してください。 PHP公式の対象環境
自社がPHPを使っていないと確認できれば、そのWebサイトのPHP2Shell対応は不要です。ただし、外部サービスや機器については、それぞれの提供元の案内を確認する必要があります。
修正版は8.2.35・8.3.36・8.4.27・8.5.12
10月21日に公開された、今回の2件を修正する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本家のサポートが終了しているため、提供元による修正の有無と、サポートされる版への移行方針を確認します。IPAの対象バージョンと対策
ここで注意したいのが、画面に出るバージョン番号だけでは、未修正と断定できない場合があることです。OSやサーバーの提供会社が、番号を大きく変えずに修正部分だけを適用することがあります。
例えば、エックスサーバーの11月2日版の案内では、対象のレンタルサーバーについて、PHP 5.1〜8.1は利用者の設定バージョンを変えずに修正パッチを適用したと説明しています。一方、同社のVPSは利用者側での対応が必要です。同じ会社でもサービスによって対応範囲が違うため、会社名だけで判断せず、自社の契約サービスとドメインを照合しましょう。エックスサーバーの公式案内
なお、このエックスサーバーの案内は当初の2件を対象としており、後述のCVE-2026-115560は対象外です。
開発会社・サーバー会社に確認する5つのこと
非技術職の担当者が、攻撃の成立条件を一人で調べる必要はありません。契約している保守会社やサーバー会社に、対象のURL・契約サービスを伝え、次の5点を確認すると対応状況を整理できます。
- 対象サイトでPHPを使っているか。 本サイトだけでなく、会員画面、フォーム、サブドメイン、公開されたテスト環境も確認対象に含めます。
- 2件のCVEへの修正が適用済みか。 「最新版です」だけでなく、実際にWebサイトを処理しているPHPの版、修正済みパッケージ、または提供元の対応済み案内を確認します。
- 修正をいつ反映し、必要な再起動まで終えたか。 「修正版を提供開始」と「自社の環境に適用完了」は区別します。
- 未対応なら、暫定措置と更新予定は何か。 担当者、実施時期、サイト停止の有無、表示・フォーム・注文などの動作確認範囲を決めます。
- 未修正だった期間について、侵害の確認が必要か。 ログの保存状況と、不審なファイルや通信、異常終了などを調べる範囲を相談します。
これは問い合わせ時の確認項目です。自社でサーバーを管理している場合は、社内の管理担当者と同じ内容を確認してください。外部のSaaSを利用している場合は、利用者がPHPを直接変更せず、サービス提供元の影響・対応案内を確認します。
実際の悪用は、どこまで確認されている？
CSAの11月3日の注意喚起は、Palo Alto Networksの影響を受けるPAN-OSで、インターネットに公開された管理画面が攻撃されたとしています。また、別のLinuxカーネルの脆弱性と組み合わせ、侵入後に最高権限を得たとの報告にも言及しています。CSAの悪用状況
この事実は、一般のWordPressサイトすべてで同じ攻撃が成立することを示すものではありません。一方、「攻撃はまだ理論上の話だから待ってよい」ともいえません。
JPCERT/CCは、修正の適用に加えて侵害の有無の調査を推奨しています。不審なログが見つからなくても、記録の不足などで痕跡を確認できない場合があります。サイトの改ざんや見覚えのないファイルなどがある場合は、削除や初期化を急ぐ前に保守担当者へ連絡し、ログなどの証拠を保全して調査してください。JPCERT/CCの侵害調査に関する案内
すぐ更新できない場合と、追加の脆弱性
PHP公式は、設定変更による緩和策を案内していますが、特定の攻撃経路への対処に限られ、更新の代わりにはならないと説明しています。WAFなどを使っている場合も、それだけで今回の修正確認を省略しないでください。
更新が難しい場合は、専門の担当者とアクセス制限や一時停止の必要性を判断し、移行計画を立てます。設定値の変更にはサイトの動作への影響があり得るため、記事を見て本番環境に一律の設定を入れるのではなく、公式案内と自社環境に基づいて対応してください。PHP公式の緩和策
なお、10月23日には、特定の設定とアプリケーションの処理が重なった場合に影響する別の脆弱性、CVE-2026-115560も告知されています。11月7日に確認したPHP公式案内では、次の通常リリースで修正する方針が示されています。10月21日の2件の修正と混同せず、自社が追加の条件に該当するか、公式の暫定設定が必要かも開発会社に確認しましょう。PHP公式の追加告知
まずは、自社のサイトで動くPHPについて「誰が管理し、今回の修正をどこまで反映したか」を確かめることが先決です。対応済みなら、その根拠となる案内や報告を残し、古いPHPを使い続けている場合は、その後の更新計画まで決めておきましょう。
情報確認日：2026年11月7日。対応状況は変わるため、作業前にはPHP公式と利用している製品・サービスの最新案内を確認してください。