ハッカーが、公開されているPHP2Shellエクスプロイトスクリプトを使い、インターネットに公開されたPHP環境を片端から探索しています。2件の重大な脆弱性の公表が、世界規模の偵察キャンペーンに発展した形です。
Fastlyは、10月22日の正午までに、PHP2Shellの名を冠したツールから約25万件のリクエストを記録しました。送信元は公開IPアドレス約3,200件に及びます。ただし、この数字には防御目的のスキャナーも含まれており、サーバーへの侵害が成功したことを示すものではありません。
攻撃の標的は、PHP2Shellと総称されるCVE-2026-109618とCVE-2026-109619です。いずれもCVSSスコアは9.2です。
2件の脆弱性はともにPHPエンジンに影響し、特定の条件下で認証なしのリモートコード実行を可能にする恐れがあります。
問題はアプリケーションコードより下のレイヤーにあるため、コンテンツ管理システム（CMS）を更新するだけでは根本的な露出は解消されません。
記事公開の時点で、100件を超える送信元IPアドレスが、24種類以上の名称を持つツールを展開していました。User-AgentにCVE識別子を掲げたエクスプロイトキットも含まれます。
最も広く使われたキットは、/index.phpまたは/にPOSTリクエストを送信していました。User-Agentにはphp2shell-109618を使い、マルチパートのバウンダリにはB7kQpoc618を指定していました。
リクエストの宛先はホスト名ではなく、生のIPアドレスでした。1台のホストに対する試行は、通常1～2回にとどまります。
このパターンは、特定の組織を狙ったものではなく、アドレス空間を無差別にスキャンする日和見的な活動であることを示しています。
Fastlyは、固定または規則性のあるマルチパートのバウンダリから、10種類を超えるエクスプロイトキットの候補を特定しました。このうち5種類は、名称、ヘッダー、挙動のいずれかからPHP2Shellとの関連が直接確認されています。
記録されたトラフィックの約3分の1は、自らを防御目的のチェックと名乗っていました。ただし、こうした表示だけでは、正当な許可を得ているかどうかは証明できません。
CVE-2026-109618は、メモリ不足（OOM）の状態により、内部リクエストデータの初期化が中断される問題です。その結果、クリーンアップ処理が不整合な状態を扱うことになります。
zif_systemに渡される引数は、偽のzend_stringに含まれるコマンドです。このコマンドは、Webサーバーユーザー（通常はwww-data）の権限で実行されます。
Akatsuki Legionの技術分析によると、PHP2Shellの名を持つ最初のスキャナーは、10月21日の03:59 UTCに出現しました。予定されていたセキュリティリリースより9時間以上も前です。
PHP2Shellエクスプロイトスクリプト
CVE-2026-109619では、内部状態がそれを支えるメモリより長く残存します。その結果、同じワーカーが処理する後続のリクエストが、破損したデータにさらされる可能性があります。
こうした条件があるため、PHP2Shellは、汎用的なペイロードで確実に発動する脆弱性とは性質が異なります。Sansecが更新した評価では、公開されている概念実証（PoC）スクリプトは、デフォルトのPHPインストールに対しては機能しませんでした。
既知のパッチ適用済みリリースを除外してクエリを実行したところ、脆弱なインフラの継続的なベースラインを把握できました。期間中に記録されたイベントは、合計274件です。
多くのスクリプトは、ローカルファイルインクルージョンなどアプリケーション側の別の弱点か、意図的に脆弱にしたテスト環境を必要とします。したがって、スキャンが広範に行われていても、攻撃が広範に成功しているとは限りません。
Recorded Futureも同様に、エクスプロイト機能をうたう公開リポジトリがあっても、実際に悪用できる証拠にはならないと警告しています。
一部のツールは、すでに否定された理論に基づいています。実際に機能する攻撃チェーンと、日和見的なプローブや誤解を招くデモを切り分ける必要があります。
防御側は、無関係な攻撃トラフィックも除外しなければなりません。Fastlyによると、出回っているPHP2Shellの検知パターンのうち2件は、大半がReact2Shellの活動に一致していました。
これらのリクエストの特定には、Next-Actionヘッダーが役立ちました。一方、マルチパートのバウンダリが—-wp2shellで始まるものは、PHP2Shellではなく、別のWordPressキャンペーンによるものでした。
エッジのテレメトリーから攻撃の試行は把握できますが、実行に成功したかどうかを確実に確認することはできません。調査担当者は、不審なリクエストを、PHP-FPMのエラー、Apacheワーカーのクラッシュ、PHPプロセスからの予期しない外向き接続と突き合わせる必要があります。
バウンダリ文字列は、脅威ハンティングの有力な手がかりになります。しかし、User-Agentの値が頻繁に変わり、プロキシインフラも共有されているため、単純なシグネチャやIPブロックリストでは信頼できません。
管理者は、PHP 8.2.35、8.3.36、8.4.27、8.5.12のいずれかにアップグレードするか、ディストリビューターが提供するパッチ適用済みパッケージを導入してください。古いブランチについては、検証済みのバックポートの適用か、移行が必要です。
WAFによる保護は一時的な対策にはなります。しかし、脆弱なリクエスト処理はアプリケーションコードの実行前に発生するため、ランタイム側のパッチ適用が不可欠です。
MTTRを21分短縮し、サイバー脅威を被害の前に阻止。ANYRUNのサンドボックスをSOCに統合。
翻訳元: https://gbhackers.com/php2shell-exploit-scripts/
