PHPのパッチをインストールすれば、セキュリティ上の脆弱性を塞ぐことはできる。しかし、攻撃者が先に侵入していないかどうかまでは管理者に伝えられない。
これは、「ブラックオクトーバー」騒動の中心となったPHP2Shellの公表後に、セキュリティチームが直面している課題だ。Amazonは一般公開前に悪用の試みを報告しており、別のPHPアドバイザリでは、緊急アップデートをすでにインストールした組織に対しても設定の確認を求めている。
セキュリティチームは今や、パッチ適用前に攻撃者がアクセスを獲得していなかったか、何かを残していないか、そして露出したすべてのアプリケーションが修正済みの状態で動作しているかを確認しなければならない。
調査の対象期間はパッチ適用前から始まる
初動対応には 予防措置としてオフラインにされた欧州政府のウェブサイトが含まれていた。次に問われるのは、運用担当者が対応の必要性を知る前に、露出したシステムが標的になっていなかったかどうかだ。
Amazon Threat Intelligenceが報告したPHP2Shellの悪用試行は、一般公開の4日前にあたる10月17日、同社のMadPotハニーポット基盤に対して行われたものだった。公開前後にもさらなる試みが確認されたが、Amazonは、それらが実際のシステムに対して成功したかどうかは不明だとしている。
Amazonは、アドバイザリの日付を調査開始時点にするのではなく、少なくとも10月17日から調査するよう推奨した。この違いは、初期確認の対象がパッチ適用開始後の期間だけだった組織にとって重要だ。
その証拠の解釈にも注意が必要だ。 10月25日の訂正で、Palo Alto NetworksのUnit 42は、欧州の政府機関に対する攻撃をPHP2Shellによるものとした以前の帰属を撤回した。研究者は脆弱なPHPアプリケーションが関与する侵害を確認したものの、これら特定のCVEが初期アクセスを提供したとは確認できなかった。
この訂正によって、パッチ適用の必要性が低下するわけではない。ただし、報告されたインシデントだけでは、PHP2Shellの悪用が成功したことを立証できないという意味だ。
別のアドバイザリで設定確認の重要性が浮き彫りに
元の脆弱性であるCVE-2026-109618とCVE-2026-109619は、10月21日にPHP 8.5.12、8.4.27、8.3.36、8.2.35で修正された。ディストリビューションや長期サポートのベンダーがバックポート版の修正を提供する場合もあるため、管理者は上流版とのバージョン比較だけに頼らず、利用しているベンダーのパッケージ状況を確認すべきだ。
10月23日、 PHPプロジェクトは情報提供のアドバイザリを公開した。これは、セッションのアップロード進捗に関する別の問題、CVE-2026-115560を扱ったものだ。この問題には、設定とアプリケーションの動作が通常とは異なる形で組み合わさる必要があり、PHPは通常のリリースサイクルで対処すると説明している。
具体的には、アプリケーションがsession.serialize_handlerをphp_binaryまたはphp_serializeに設定したうえで、session_start()を呼び出す前にini_set()でphpへ切り替えなければならない。さらに、セッションのアップロード進捗機能も有効なままでなければならない。
PHPは、次回の通常のバグ修正リリースまでsession.upload_progress.enabled=0に設定するよう推奨している。これによりPHP標準のセッション・アップロード進捗レポート機能が無効になるため、管理者はアプリケーションがこの機能に依存しているか確認すべきだ。この別の問題について、PHPは、実行時にシリアライゼーションハンドラーを変更しないアプリケーションでは機能を有効なままにできるとしている。ただし、元のPHP2Shell脆弱性に対処するアップデートは必要だ。
この緩和策を適用する管理者は、リクエスト解析より前に反映される設定を使わなければならない。たとえばphp.ini、PHP-FPMプール、Apacheサーバー設定などだ。PHPは、この変更についてアプリケーションレベルのini_set()やPHP-FPMの.user.iniファイルに依存しないよう警告している。
Red Hatの導入ガイダンスも、影響を受けるすべてのワーカーを再起動するよう求めている。リロードでは不十分だ。コンテナ化された環境では、稼働中のコンテナまたはポッドを置き換えること。コマンドラインPHPの設定だけに頼らず、ウェブリクエストを処理するアプリケーションが更新済みの設定を使用していることを確認する必要がある。
セッションのアップロード進捗機能を無効にすれば、条件付きで発生する別の問題には対処できるが、元のPHP2Shellアップデートの代わりにはならない。後発のアドバイザリは、それらのアップデートが元の脆弱性の修正に失敗したことを意味するものでもない。
CMSを更新しても、すべての隙間が塞がるわけではない
脆弱なコンポーネントは、ウェブサイトのアプリケーションより下層に存在する。 Wizの研究者はWordPress、Drupal、Joomlaの環境に対する未認証のリモートコード実行を実証したが、根本的な弱点はPHP自体にあると説明している。
従来から WordPressプラグインの悪用に対応してきた組織にとって、それは検証作業を変える。プラグインやコンテンツ管理システムを更新しただけでは、PHPランタイムに修正が適用されたことの証明にはならない。
Arcovaのサイバーセキュリティ研究者兼アドバンストサービス責任者であるJoseph Perry氏は、ECサイトやその他のAPI駆動型ウェブアプリケーションについて、今回の対応を「重要なアップデートと監視の期間」と表現した。
「ブログやウェブサイトを運営している人にとって、複雑さを減らし、すべてを更新し、ベストプラクティスを常に実践するよいきっかけになる」とPerry氏は語った。
実務上のフォローアップとしては、ホスティング事業者やアプリケーションの所有者に対し、露出した各サイトをどのランタイムが処理しているのか、どのベンダーパッケージが脆弱性を修正するのか、そして稼働中のワーカーやコンテナが実際にアップデートを取り込んだのかを確認するとよい。
また、 National Security Agencyのアドバイザリでは、詳細なロギングと、互換性のあるパッチを受け取れないサポート終了PHPサービスの置き換えも推奨している。直ちにアップデートできない場合は、完全に緩和できるまでシステムをオフラインにするよう勧めている。管理者にとってこれは、サポート対象の環境でアップデートを確認するだけでなく、サポートされていないシステムを特定することも対応の一部になるということだ。
一時的な対策も精査が必要だ。 AWSの緩和策ガイダンスは、ウェブアプリケーションファイアウォールのルールを補助的な防御策と位置づけ、パッチ適用だけが完全な修正だと強調している。リクエストをブロックできたことを、修正チケットを完了するための証拠にしてはならない。
Cloudflareは報告したところによると、攻撃者は同社の防御を回避しようとペイロードを変更し、同社のアナリストは検知ルールの更新を続けていた。この活動は、防御側が初回導入を作業の終わりとみなすのではなく、修正対応中も一時的な対策を見直すべき理由をもう1つ示している。
AIによって、手間をかける価値のあるエクスプロイトが変わる
Perry氏がより広い観点で懸念しているのは、エクスプロイト開発の経済性だ。
「これは、AIがエクスプロイトを可能にしたというより、実用的なものにした興味深い事例でもある」と同氏は語った。「このようなエクスプロイトの開発を妨げているのは、プラットフォーム間、バージョン間で絶え間なく徹底的なデバッグを行う必要があることだ」
Wizの調査結果は、この評価と一致する。研究者は、PHPのバージョン、設定、メモリレイアウトをまたいでテストと適応を繰り返したと説明し、AIによって必要な専門家の作業量が減ったとしている。
「AIから守るというのは、人間には到底想像できない未来的なエクスプロイトから守ることではない。人間ならわざわざ使おうとは思わない種類のエクスプロイトから守るということだ」とPerry氏は語った。
これは、確認された攻撃のすべてがAIを使っていたことを示すものではない。ただし、複雑なメモリ破壊の脆弱性は、多数の標的に対して悪用するにはコストが高すぎるという前提には疑問を投げかける。
「AIによって何が可能になるかではなく、AIによって何が実用的になるかに、もっと、もっと注目すべきだということだ」とPerry氏は語った。
その後に起こり得る問題は、よく知られている。 WP-SHELLSTORMによるウェブサイトへのバックドア設置作戦についての以前の報道では、攻撃者が既知の脆弱性を使って永続的なアクセスを確立したことが示されていた。これは別のキャンペーンだが、修正対応では攻撃者が何を残していく可能性があるかを考慮しなければならない理由を示している。
対応を終える前にセキュリティチームが確認すべきこと
ブラックオクトーバー後に得られる最も有益な成果は、3つの問いに対する記録された回答だ。どのシステムが露出していたのか、保護が有効になったのはいつか、そして現在も信頼できる状態にあると確信する根拠は何か。
セキュリティチームは、外部公開されている各アプリケーションを、実際のPHPランタイムと責任を負う担当者に結び付けるべきだ。ホスティングサービスについてはプロバイダーから確認を取り、コンテナについては更新済みイメージが稼働中のワークロードに到達したことを確認する必要がある。変更リクエストが完了したという記録は、導入済みの修正を検証した証拠より弱い。
調査は修正対応と並行して進めるべきだ。少なくとも最初に攻撃が確認された日付以降の、保存されたウェブ、アプリケーション、エンドポイントのテレメトリーを確認し、証拠が必要とする場合はさらに遡る。ウェブワーカーが起動した予期しないプロセス、不正なファイル変更、疑わしい外向き接続については調査が必要だが、いずれも単独でPHP2Shellの悪用を証明するものではない。ログが欠落している場合は、確信度を制限する要因として記録すべきだ。
証拠が侵害を示している場合、パッチ適用をインシデント対応の一部として扱う。復旧完了を宣言する前に、影響範囲を特定し、永続化の仕組みを排除し、アクセス可能だった認証情報やトークンを交換する必要があるか評価する。
さらに読む NextcloudサーバーのCollaboraの脆弱性を悪用した攻撃は、パッチをインストールした後にウェブシェルや過去の侵害を確認しなければならない理由を示している。