PHP2Shellへの対応では、公開サイトを動かすPHPに修正が反映されているかを確かめ、侵入が疑われる場合は過去の記録も調べる必要があります。
修正版の公開を知っていることと、自社の環境で対応が終わっていることには隔たりがあるためです。
セキュリティ企業CYFIRMAは、日本を含む地域を対象とする攻撃活動について警告しました。
本記事では、この報告を手掛かりに、攻撃者に関する情報をどこまで確かなものとして扱えるか、運営者は何を依頼し、どの結果を受け取ればよいかを整理します。
脆弱性の発見経緯やAIによる調査の詳細は、既存の「AIが発見したPHPの重大脆弱性『PHP2Shell』とは？サイトへの影響と必要な対策」で解説しています。
今回は攻撃活動と対応判断に焦点を当てます。
CYFIRMAが10月23日に公開し、本文で24日時点の状況を追記した警告では、日本を含む地域でPHP環境を探る活動が報告されています。
同社は、監視した非公開の通信内容や観測情報に基づき、北朝鮮との関連を評価しました。
対象として挙げられたのは政府機関、金融機関、物流、航空、製造業などです。
ただし、Lazarusとの関連について同社が示す確信度は中程度で、言語や活動パターンなどに基づきます。
「北朝鮮による攻撃が確定した」「Lazarusが日本企業へ侵入した」と言い切る根拠にはできません。
企業の防御では、帰属の確定を待たずに、自社で使うソフトウェアと外部公開の範囲を調べられます。
ニュースの中で目を引く攻撃者名と、運営担当者が着手する条件は切り分けて考える方が、対応を止めずに済みます。
出典：CYFIRMA
https://www.cyfirma.com/research/cyfirma-threat-advisory-suspected-dprk-campaign-staging-php2shell-targeting-against-global-php-infrastructure/
PHP2Shellは、PHP本体の重大な脆弱性「CVE-2026-109618」「CVE-2026-109619」を指す呼称です。
条件が成立すると、ログインしていない攻撃者による遠隔コード実行につながり得ます。
前者はメモリ不足時の処理、後者はリクエスト間に残る内部状態の扱いに関係します。
PHP公式はWebリクエストを処理する各種PHP環境に対応を求め、Apacheのmod_phpを特にリスクの高い構成としています。
WordPressを利用している場合も、CMS本体の更新とは別に、実行基盤の修正状況を確認する必要があります。
ここで利用中の言語名が分からなくても、確認を諦める必要はありません。
契約中のサーバー会社や保守会社へ、対象ドメインでPHPが使われているかを問い合わせるところから始められます。
出典：PHP公式セキュリティアドバイザリー
https://www.php.net/archive/2026.php#2026-10-21-5
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
CYFIRMAによると、監視対象の攻撃者側は216ホストを候補として挙げ、21のノードから低頻度の確認を進めていると述べました。
この数字は、攻撃者側の発言を同社が報告したもので、216件すべての脆弱性や侵入成功を第三者が確認した集計ではありません。
同社は標的一覧そのものを確認できておらず、具体的な被害組織名も挙げていません。
日本が対象地域に含まれることは注意する理由になりますが、そこから国内の特定企業やサービスの被害を推定することはできません。
情報の意味を整理すると、対応の範囲も変わります。
標的候補への言及は環境確認のきっかけになり、不審な通信の記録は追加調査の材料になります。
一方、情報漏えいの公表には、実際に何が起きたかを裏付ける証拠が必要です。
別の一次情報として、Amazon Threat Intelligenceは、10月17日に監視用のハニーポット「MadPot」でPHP2Shellの悪用試行を観測したと公表しています。
修正版が公開された21日より前の出来事です。
ただし、AWSは、これらの試行が実環境で成功したかは不明と説明しています。
また、この観測とCYFIRMAが報告する活動を、同じ攻撃者によるものと結び付ける証拠は示されていません。
複数の報告があるからといって、一つの攻撃キャンペーンにまとめると事実関係が変わってしまいます。
運用面では、更新した日より前にも調査対象の期間があると分かります。
修正を適用した時点から監視を始めるだけでは、先行する接触の有無を見落とすおそれがあるため、ログの保存状況と遡って確認できる期間を担当者に尋ねてください。
出典：Amazon Threat Intelligence
https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
CYFIRMAは、攻撃者が公開済みのPoC、つまり脆弱性を再現する検証コードの選別・評価にAIを利用していると分析しています。
この点の確信度も中程度です。使用モデルや製品名、AIだけで攻撃を完了したことまで確認された報告ではありません。
したがって、本件を「AIが日本のサイトを自動で乗っ取った」と紹介するのは不適切です。
公開された技術情報を攻撃者が検討する過程で、AIが作業を補助している可能性として捉える必要があります。
以下は、その評価を踏まえた編集上の分析です。
多数の検証コードや実行条件を読み比べる時間が短くなれば、修正版の公開後、防御側が確認・承認・更新を進めている間に攻撃準備が進む可能性があります。
AIの能力だけを比較するより、組織側にどこで待ち時間が生じるかを見直す方が、具体的な改善につながります。
例えば、保守契約に緊急更新が含まれるか分からず、担当部署を探すところから始める企業では、技術的には更新できても着手が遅れます。
検証環境がない、停止を判断する責任者が決まっていない、休日の連絡先が古いといった問題も、対応を長引かせる要因になります。
こうした待ち時間は、平時に決めておけば短縮できます。
外部公開システムの一覧、運用窓口、緊急更新の承認者、一時的に公開を制限する条件をそろえることで、警告を受けてから担当者を探す作業を減らせます。
AIを使って公式発表の要点や確認事項を整理する場合も、更新の対象や完了判定は実環境の情報と照合してください。
生成された説明が正しくても、別のサーバーや旧コンテナが残っていれば、対応範囲の抜けは解消されません。
10月21日に公開された2件の修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。
ただし、Linuxディストリビューションなどでは、元のバージョン番号を維持したまま修正を取り込む場合があります。
数字の大小だけで未対応と断定せず、提供元のセキュリティ情報とパッケージのリビジョンを確認します。
PHP 8.1以前についても、PHPプロジェクトの通常サポート終了と、提供元による修正提供の有無は別です。
利用するOSや長期サポート事業者の案内を確かめ、修正の根拠を記録する形にしてください。古い系列を使い続けられるかどうかは、保守条件も含めた判断になります。
PHP公式は10月23日、セッションのアップロード進捗機能に関する別の問題「CVE-2026-115560」に注意を促しました。
特殊な設定とアプリケーションの動作が組み合わさる場合に関係し、21日の更新だけで解決する問題ではありません。
公式は次回の通常修正版まで、session.upload_progress.enabled=0を設定するよう提案しています。
既に適用している場合は維持する案内です。
設定変更はアップロード関連の動作にも関係するため、管理担当者が適用場所と機能への影響を確認し、実際の稼働環境で反映を確かめます。
さらに26日には、Brotliの別の脆弱性に対応したWindowsパッケージの再ビルドも案内されました。
これはPHP2Shellの2件とは異なる更新です。Windows環境ではパッケージの更新情報も追い、複数の注意喚起を一つの「対応済み」にまとめない管理が必要になります。
出典：PHP公式・2026年10月の更新情報
https://www.php.net/archive/2026.php
AWSはPHP2Shell向けのWAFマネージドルールを案内し、10月23日にはルールグループの更新と追加問題への対応も説明しています。
ただし、自社の通信が対象のWAFを経由し、適切なルールが適用されているかは別途確認が必要です。
運営者が受け取るべき回答は「WAFを入れています」という製品の有無だけでは足りません。
どのドメインを保護し、どのルールをいつ有効にしたか、監視だけか遮断する設定か、対象外の経路がないかまで確認すると、対策の実態が見えます。
また、WAFやPHPの更新は、それ以前に侵入がなかったことを証明するものではありません。
防御の強化と、過去に不正な処理が行われたかの調査は、別々に完了を判断します。
出典：AWS WAFの公式案内
https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/
最初に、メインサイト、サブドメイン、予約・問い合わせフォーム、旧サイトなどの公開先を一覧にします。
同じ契約でも別のPHP環境で動くことがあるため、更新を依頼する対象をドメインと環境の単位で明確にしてください。
WordPressでは、管理画面の「ツール」から「サイトヘルス」を開き、「情報」のサーバー項目でPHPの情報を確認できます。
ただし、これは入口となる情報です。提供元の修正取り込みや別の公開環境まで確定できるとは限らないので、確認結果を保守会社へ渡して照合します。
出典：WordPress公式・サイトヘルス画面
https://wordpress.org/documentation/article/site-health-screen/
以下の表は、委託先とのやり取りで確認漏れを減らすためのものです。
単に作業を依頼するより、完了後に何を報告してもらうかまで決めると、社内でも状況を共有できます。
更新後は、表示だけでなく、ログイン、フォーム送信、ファイルのアップロード、購入など、そのサイトで必要な処理を確認します。
検証の結果と併せて、未対応の環境や調査できなかった期間があれば残してください。
すべてを確認できていない状態を、報告上だけ完了にしないためです。
「当社の公開サイトについて、PHP2Shellの2件の脆弱性に対する修正適用状況をご確認ください。
対象ドメイン、適用したパッケージと修正の根拠、対応完了日時、必要なワーカー再起動・再配備の実施状況をご共有ください。
併せて、10月23日の追加注意喚起への該当有無と対応、不審な通信やファイルを調査した期間、未対応・未確認の範囲、当社側で必要な作業をお知らせください。」
不審なファイルや不明な外向き通信が見つかった場合は、通常の更新依頼からインシデント対応へ切り替えます。
担当者と連携して証拠の保全や公開制限を判断し、不審なファイルを削除して終わりにしないことが必要です。
更新を急ぐ作業と、何が起きたかを確かめる作業の調整が求められます。
今回の報告を受けて運営者が取るべき行動は、利用環境に修正が届いているかを確かめ、調査の結果と限界を把握することです。
攻撃者の国籍やAI製品名が分からなくても、その確認は進められます。
まずは対象ドメインを添えて保守窓口へ問い合わせ、対応完了日時と修正の根拠を受け取ってください。
未対応部分がある場合は、公開を続ける条件と対応期限を決めます。
この記録を残すことが、次の警告でも判断を早める土台になります。
.png){kind=logo}
