Amazon、PHP2Shellの悪用をCVE-2026-109618公開の4日前の10月17日に特定

Amazon Threat Intelligenceは、2026年10月17日にPHP2Shellの悪用試行を観測したと報告しました。これは、CVE-2026-109618およびCVE-2026-109619が2026年10月21日に公開される4日前のことです。この発見は、防御側が対応期間をアドバイザリ公開日ではなく、既知の最初の悪用から測定すべきであり、インターネットに面した重要なパッチは7日や30日ではなく、時間単位の問題として扱うべきであることを意味します。

Amazonが実際に検出した内容

Amazon Threat Intelligenceは、CVE-2026-109618およびCVE-2026-109619の公開4日前の2026年10月17日に、MadPotハニーポットネットワークに対するPHP2Shellの悪用試行を特定しました。この試行は、商用匿名化ネットワークに関連するIPアドレスから発信されました。

Amazonは、当時この脆弱性はまだエンバーゴ下にあったため、匿名化されたIPアドレスからハニーポットを標的にしたことは、脅威アクターによる活動を示唆していると述べています。また、アクターが公開前にどのようにしてエクスプロイト情報を入手したかは不明であるとも述べています。同社は、観測された試行のいずれかが実環境のシステムで成功したかどうかは不明であると指摘しています。

MadPotはAmazonのハニーポットシステムです。Amazonは、毎分2000億以上のイベントを分析し、MadPotハニーポットネットワークからの脅威インテリジェンスを統合して、既知の悪用試行をリアルタイムで特定しブロックしていると述べています。

PHP2Shellの悪用タイムライン

PHPのエンバーゴは2026年10月21日14:00 UTCに解除される予定でした。悪用活動はその境界の両側に集中していました。

時刻 (UTC) イベント
2026-10-17 MadPotに対する最初のPHP2Shell悪用試行（103.216.220.92から）
2026-10-21 ~02:00 エンバーゴ解除前に、この脆弱性に対する最初の概念実証エクスプロイトが特定される
2026-10-21 02:00-08:00 追加の匿名化インフラからのMadPotに対する追加のPHP2Shell悪用試行（さまざまなペイロードを使用）
2026-10-21 14:00 エンバーゴ解除およびパッチリリース
2026-10-21 14:00以降 数時間以内にさらなる概念実証エクスプロイトが出現し、ほぼ即座にAmazonのセンサーに対して使用された

Amazonは、ペイロードと匿名化インフラの選択が多様であると説明しており、これは単一のアクターではなく複数のアクターを示唆しています。同社は、PHP2Shellが現在広く野外で悪用されていると述べています。

エンバーゴは、他の誰かが同じバグを見つけるまで防御側を保護するだけである

Amazonが最初に述べた教訓は、協調的な開示が依然として正しいモデルであるが、防御側は公開日が悪用の最も早い日付であると想定すべきではないということです。PHP2Shellの場合、侵害はアドバイザリより前に行われた可能性があります。10月17日のハニーポットへの攻撃は、その主張に対するAmazonが提供する具体的な証拠です。

パッチからエクスプロイトまでの期間は構造的な理由で短縮している

Amazonの2番目の教訓は、パッチから動作するエクスプロイトまでの時間が短縮していることです。過去には、Amazonが観測した悪用のほとんどは公開された概念実証のリリース後でした。少数の有能なアクターがエクスプロイトを構築し、他の全員がそれを待っていました。Amazonは、AI支援による分析により、パッチの差分やアドバイザリを動作するエクスプロイトに変換するコストが低くなったため、この依存関係は弱まっていると述べています。その結果、脆弱性の技術的詳細が開示されると、より多くのアクターが数時間または数分以内に行動できるようになります。

セキュリティリーダーが変更すべき点

Amazonは、このイベントが無効であると述べる3つの作業仮説を挙げています。

  1. インターネットに面したシステムの重大な脆弱性については、パッチと緩和策のタイムラインを時間単位で測定する。7日または30日のSLAは、もはや存在しない遅延を前提としています。
  2. 調査は開示日ではなく、既知の最初の悪用から開始する。PHP2Shellの場合、Amazonは少なくとも2026年10月17日から調査することを推奨しています。
  3. 特定のCVEのシグネチャに依存しない検出に投資する。最初の悪用は、これらのシグネチャが存在する前に行われることが多いためです。

PHP2Shellに対する推奨される修復策

Amazonは5つのアクションを挙げています。

  1. 修正済みのPHPバージョンに直ちにアップグレードする。Amazonは、アップグレードがCVE-2026-109618およびCVE-2026-109619の両方に対する唯一の完全な修復であり、両方の問題を完全に解決する設定のみの回避策はないと述べています。
  2. 直ちにパッチを適用できないPHPデプロイメントでは、アプリケーションへの影響を判断した上で、マルチパートファイルアップロードのブロックを検討する。
  3. フォームアップロードにPHP_SESSION_UPLOAD_PROGRESS文字列を含むPOSTリクエストを探す。
  4. Webサーバーのログで不審なアクティビティを確認する。
  5. Webアプリケーションサーバーでの予期しないプロセス実行またはファイル変更を確認する。

AWSはまた、パッチ適用中にAWS WAFを使用してPHP2Shell RCE脆弱性の緩和策を適用する方法に関する補足記事も公開しました。

Amazonが観測したIPアドレス

Amazonは、このアクティビティに関連する6つのIPアドレスを公開しました。これらのアドレスには共有匿名化インフラが含まれており、この脅威アクティビティに限定されるものではなく、組織はこれらのアドレスを完全にブロックするのではなく、関連する観測を調査すべきであると明示的に述べています。

IPアドレス 観測日
103.216.220.92 2026年10月17日
31.223.184.166 2026年10月21日
37.19.200.5 2026年10月21日
134.209.159.64 2026年10月21日
103.114.163.188 2026年10月21日
95.217.98.37 2026年10月21日

Hacker Newsの議論が追加する内容

このレポートに関するHacker Newsのスレッド（197ポイント、55コメント）は、主に2つの質問に焦点が当てられました。Amazonが説明する悪用が実際に成功したかどうか、そしてAmazon自身のLinuxパッチが、同社が宣伝していた開示に遅れを取った理由です。

観測されたアクティビティは実際の侵害でしたか？

コメント投稿者は、Amazonが悪用の試行と成功した侵入を区別しているかどうかを尋ねました。あるコメント投稿者は、動作するエクスプロイトではなく、プローブのみを見たと説明しました。

サーバーログでプロービングは見ましたが、実際の悪用は見ていません。ボットネットが脆弱性スキャナーに追加したと思いますが、実際に動作するエクスプロイトの例はまだ見ていません。GitHubには何百ものvibe codedの試みがありますが、私の知る限りどれも機能しません。

別のコメント投稿者は、エクスプロイトがそもそも使いやすいかどうかを尋ね、別の記事がエクスプロイトは簡単ではなく、ローカルファイルインクルージョン（LFI）が必要であると主張していると指摘しました。Amazon自身も、試行のいずれかが実環境のシステムで成功したかどうかは不明であると述べており、ソース資料はこの質問を解決していません。

Amazon自身のパッチタイムラインが批判を浴びた

複数のコメント投稿者は、Amazon Linuxパッケージがパッチリリースに遅れたため、ブログ投稿が自身のメッセージを弱体化させていると主張しました。あるコメント投稿者は、amazonlinux/amazon-linux-2023リポジトリのGitHub issueを指摘しました。

つまり、Amazonはこのエクスプロイトを知っていて、パッチのリリースの数日前に積極的に使用されていたことを知っていた。それにもかかわらず、パッチのリリース後18時間も経ってからAmazon Linuxパッケージの更新版を提供したのか？

別のコメント投稿者は、AmazonのAmazon Linuxパッチが10月22日に予定されていたと述べ、その点でこの投稿は恥ずかしいと述べました。これらはAmazon Linuxのリリースタイミングに関するコメント投稿者の主張であり、AWSのブログ投稿自体はAmazon Linuxパッケージの可用性については言及していません。

他のベンダーのテレメトリとの重複

あるコメント投稿者は、Matthew Princeのツイートを引用し、Cloudflareが発表前に数千件の試行、発表後に数万件、ツイートの時点で数百万件を確認したと述べました。同じコメント投稿者は、タイムラインのあいまいさを指摘しました。発表が14:00 UTCを指す場合、それはChainguardがイメージを公開してから数時間後であり、正確なタイムラインは、アクターがこれらのビルドからエクスプロイトを導出したかどうかを確立するのに役立つでしょう。

PHPプロジェクトの開示処理への批判

スレッドの一部では、研究者やPHP内部関係者への非公開通知の直後に悪用がどのように始まったのかが疑問視されました。あるコメント投稿者は次のように書いています。

研究者が脆弱性を発見し、PHP内部関係者に通知された後に攻撃が始まったことは、かなり示唆的です。悪意のあるエンティティがまったく同じエクスプロイトチェーンを同時に完全に独立して発見したと誰が本当に信じるでしょうか？

別のコメント投稿者は、PHPチームの公開コミュニケーションについてより厳しく、Chainguardと資金問題に責任を転嫁していると説明しました。3人目のコメント投稿者は、この批判を、ベンダーが顧客に修正を提供するのではなく、誰が最初に脆弱性を検出したかを競っているというより広範な不満に一般化しました。

未解決のまま残っている点

ソース資料はいくつかの質問を未解決のままにしています。Amazonは、開示前のアクターがどのようにしてエクスプロイトの詳細を入手したか、試行が成功したかどうか、またはさまざまなペイロードの背後にいた特定のアクターが誰であるかを述べていません。コメントスレッドは、10月17日のアクティビティが開示前の武器化であった可能性を提起していますが、Amazonもコメント投稿者もその連鎖を確立する証拠を提供していません。ただし、Amazonの運用ガイダンスはこれらの回答に依存していません。インターネットに面したPHPデプロイメントに数時間以内にパッチを適用し、フォレンジックのタイムラインを既知の最初の悪用日から開始し、CVE固有のシグネチャではなく行動検出に依存します。

Sources