AWSがPHP脆弱性の公表前の攻撃試行を報告｜10月17日からの記録確認を推奨

Amazon Threat Intelligenceは、今回のPHP重大脆弱性を狙う攻撃試行を、一般公表より前の2026年10月17日に観測していたと報告しました。修正版が出た10月21日からだけ過去の記録を調べるのではなく、それ以前も調査対象に入れる必要性を示す続報です。

本記事は10月22日に確認したAWSのMadPot観測報告を中心に、CVE-2026-109618・CVE-2026-109619の悪用状況について、何が新たに分かったかを整理します。観測先は同社のハニーポットであり、この情報だけで特定企業の本番環境への侵害成功を認定するものではありません。

公表前の10月17日に攻撃試行を観測

AWSによると、10月17日のMadPotの記録からPHP2Shellの攻撃試行が見つかりました。送信元は商用の匿名化ネットワークに関連するIPアドレスだったとしています。協調公表の期間中に第三者がどのように攻撃情報を入手したかは不明です。

同社はさらに、10月21日02時から08時UTCにも、別の匿名化基盤からMadPotへ向かう攻撃試行を観測したと説明しています。日本時間では同日11時から17時です。ペイロードや匿名化基盤の違いは複数の主体を示唆するとしていますが、実際のシステムで各試行が成功したかは不明と明記しています。

同報告は、公開後にはPHP2Shellが実環境で広く悪用されているとも評価しています。「攻撃試行を観測した」「広い悪用を評価している」「個々の試行の成功は不明」という記述は、対象と確度を分けて読む必要があります。

AWSが示した時点	公表内容	本稿での区別
10月17日	MadPotで公表前の攻撃試行を確認	記載日をそのまま使用。詳細な時刻は補わない
10月21日02〜08時UTC	追加の攻撃試行を観測	日本時間では21日11〜17時
公表・修正公開後	実証コードが現れ、実環境で広く悪用されていると評価	特定の被害組織や成功件数は示していない

この表はAWSの観測と評価を整理したものです。PHPの修正版が各環境へ適用された時刻や、インターネット全体で最初の攻撃が起きた時刻を示すものではありません。観測できた最初の日と、実際の活動開始日は一致するとは限りません。

調査の開始日を公表日だけで決めない

AWSは、PHP2Shellの調査では少なくとも10月17日からの記録を確認するよう勧めています。公表日が、攻撃の始まりを示すとは限らないためです。今回の続報で読者の対応が変わる中心は、この遡及範囲です。

本サイトの提案は、調査記録に「公表日」「自社の露出期間」「確認したログの開始日」を別々に残す方法です。10月21日に更新したサイトでも、それ以前に未修正のPHPを公開していれば、更新前の期間は別の評価対象になります。

ただし、10月17日以前が安全だったと保証されたわけではありません。少なくともその日まで遡るという勧告を、そこより古い記録を捨ててよいという意味にはしないでください。保存できるログの範囲と、システムの公開履歴を合わせて調査担当が判断します。

また、10月17日当時に存在しなかった環境へ、機械的に同じ調査期間を割り当てる必要もありません。新規構築、旧サーバーからの移行、一時公開の履歴があるなら、どの実体をどの時点に調べるかを分けます。サイトのURLが同じでも、処理するサーバーが変わっている場合があります。

ハニーポットの観測と自社の侵害を分ける

MadPotの観測は、攻撃者の活動を知る重要な材料です。一方、読者のサイトが同じ要求を受けたか、脆弱な処理へ到達したか、コード実行に至ったかは別に確認する必要があります。この報告だけで「自社も10月17日から侵害されていた」とは結論づけられません。

PHP公式のCVE-2026-109619の勧告は、Webワーカーの権限での遠隔コード実行やメモリー開示を影響として説明しています。影響評価では、サーバー全体の管理者権限を無条件で取られたと決めつけるのではなく、実際にそのプロセスが何へアクセスできたかを確認します。

本サイトの整理では、外部の観測報告は調査の優先度と範囲を決める材料、自社のログや構成は個別の状態を判断する材料です。この二つを同じ欄へ混ぜると、未確認の被害を確定扱いしたり、逆に自社で検出がないことを理由に外部情報を無視したりするおそれがあります。

調査結果を共有する際も、「AWSが公表前の試行を報告」「自社ではこの期間の記録を確認」「この点は未確認」という順に分けると、根拠が明確になります。脆弱性への緊急対応中でも、確定した情報と調査中の事項を区別する必要があります。

匿名化基盤のIPだけで攻撃者を特定しない

AWSの報告には観測に関連するIP情報が含まれますが、共有の匿名化基盤も含まれ、この活動だけが使うアドレスではないと注意しています。そのため本稿は、IP一覧をそのまま攻撃者一覧として転載しません。

同じIPとの通信が記録されていても、相手の実体や目的、要求の内容を別に調べる必要があります。反対に、掲載されたIPが記録にないことも、この脆弱性を狙う通信がなかった証明にはなりません。送信元だけを調査の唯一の基準にしないことが必要です。

本サイトの提案では、送信元に加え、対象ホスト、時刻、要求の特徴、応答、PHPやWebサーバーの異常、想定外のプロセスやファイル変更を対応させます。これは特定の指標で自動的に被害を認定するルールではなく、調査担当へ渡す情報をそろえる考え方です。

記録に不審な内容があった場合は、その場で消したり本番へ再投入したりせず、保存して評価します。攻撃試行の有無を確かめるために、第三者の攻撃コードを本番へ流す必要はありません。今回の記事は攻撃手順の再現ではなく、観測が運営判断へ与える意味を扱っています。

AWSの基盤と利用者のPHPは別の確認対象

AWSのセキュリティ情報2026-143-AWSは、AWSサービス自体と、利用者がその上で動かす影響対象のPHPを区別しています。クラウド名が同じでも、修正を適用する主体や更新経路が異なるためです。

告知はWorkMailへの設定上の制御、Elastic BeanstalkのPHPプラットフォーム更新、Amazon Linuxのパッケージ更新予定などを個別に説明しています。確認時点で「予定」と記載された項目を、本稿では完了した更新へ読み替えていません。利用者が環境を更新する必要がある構成も含まれます。

本サイトがここで重視するのは、攻撃観測の報告と、各サービスの修正状況が別の資料で管理されている点です。脅威情報が新しくなったからといって、利用中の全環境へ修正が届いたことにはなりません。逆に、自分の環境を更新できたことから、公表前の調査が不要になるわけでもありません。

なお、古いPHPの扱いは、PHP公式の最新告知や利用中の配布元も併せて確認します。PHP公式は一部旧系列向けの最小限のソース修正にも言及していますが、通常サポートの再開ではありません。別の告知にある旧版の説明だけを、自分のパッケージへ一律に当てはめないでください。

Google Cloudも利用者環境の監視と修正を案内

Google Cloudの10月21日付対応報告も、基盤そのものと利用者のPHPアプリを区別しています。自動更新の条件に合うサービスと、利用者による再ビルド・再展開が必要な構成を説明し、監視や調査の案内を追加しています。

同社の案内は、修正適用に加えて、コンテナ内の脅威検出やログを使った評価を扱っています。これは、脆弱な版を探す作業と、侵入の痕跡を探す作業を並行して進める考え方です。ただし、製品に検出機能があることと、読者の環境でその機能が有効になっていることは別です。

本サイトの分析では、AWSとGoogle Cloudの公表に共通するのは、修正だけ、通信フィルターだけ、検出だけの一つで完了しない整理です。今回のAWS報告で公表前の活動が示されたことは、特に「更新前をどこまで調べるか」という判断を強める材料になります。

AIの一般論を今回の攻撃者の証拠にしない

AWSは、AIによる分析支援が、修正差分や勧告から攻撃を組み立てる時間を短くするという一般的な評価も述べています。しかし、この記述だけから、10月17日の攻撃者がAIを使った、特定モデルが攻撃を作成した、と断定することはできません。

公表前に攻撃情報を得た経路についても、AWSは不明としています。情報漏えい、独自発見、関係者からの流出などの筋書きを本稿で補いません。今回確認できたのは観測の時系列と同社の評価であり、攻撃主体や入手経路が解明されたという続報ではありません。

今回変わった判断材料

今回の新事実は、AWSが公表より前の活動を観測したと報告したことです。修正適用を急ぐ判断に加え、10月21日以前の記録も保持し、調査する根拠が加わりました。具体的な侵害の認定には、自社の構成と記録が引き続き必要です。

修正版の提供、WAFの防御、全ノードへの反映、過去の影響調査を、それぞれ別の状態として残してください。更新したから過去も安全だった、検出がないから攻撃されていない、といった短絡を避けることが、この観測報告を実務へ生かすポイントです。

関連記事

• PHP重大脆弱性2件の原因と修正版：修正版公開時点の全体像を扱います。悪用状況については本稿のAWSによる新しい報告と分けて読んでください。
• Cloudflareが観測したPHP攻撃通信とWAFの確認範囲：要求の遮断と侵害成立を分ける先行記事です。