ブラック・オクトーバー後も残るPHPセキュリティの疑問

PHPのパッチを適用すれば、セキュリティ上の欠陥は塞げます。しかし、攻撃者が先に侵入していたかどうかまでは、管理者にはわかりません。

「ブラック・オクトーバー」と呼ばれる警戒態勢の発端となったPHP2Shellの開示を受け、セキュリティチームはこの課題に直面しています。Amazonは公開前に悪用の試みを確認したと報告しました。また、別のPHPアドバイザリーでは、緊急アップデートを適用済みの組織に対しても、設定の確認を求めています。

セキュリティチームはいま、パッチ適用前に攻撃者がアクセスを得ていなかったか、何かを残していかなかったか、そして露出しているすべてのアプリケーションで修正が動作しているかを確認する必要があります。

調査対象期間はパッチ適用より前から始まる

最初の混乱では、 欧州の政府系Webサイトが予防措置としてオフラインになりました。次に問われるのは、運用者が対応の必要性に気づく前に、露出したシステムが標的にされていなかったかどうかです。

Amazon Threat Intelligenceは、公開の4日前にあたる10月17日、同社のハニーポット基盤「MadPot」に対するPHP2Shellの悪用の試みを確認したと報告しました。その後も公開の前後に複数の試みが続きましたが、実際の環境のシステムに対して成功したかどうかは不明だとAmazonは説明しています。

Amazonは、アドバイザリーの公開日ではなく、少なくとも10月17日までさかのぼって調査するよう推奨しています。パッチ適用開始後の期間だけを初期調査の対象にした組織にとって、この違いは重要です。

証拠の扱いにも慎重さが求められます。Palo Alto Networks傘下のUnit 42は、 10月25日の訂正で、欧州の政府機関に対する攻撃を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で修正されました。ディストリビューションや長期サポート（LTS）のベンダーがバックポートで修正を提供する場合もあります。そのため管理者は、アップストリームのバージョン比較だけに頼らず、利用中のベンダーのパッケージの状況を確認する必要があります。

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の展開ガイダンスも、影響を受けるすべてのワーカーを再起動するよう求めています。リロードでは不十分です。コンテナ環境では、稼働中のコンテナやPodを置き換えてください。コマンドラインのPHP設定だけで判断せず、Webリクエストを処理するアプリケーションが更新後の設定を使っていることも確認する必要があります。

セッションのアップロード進捗を無効にすれば、この別件の条件付きの問題には対処できます。ただし、当初のPHP2Shellに対するアップデートの代わりにはなりません。後から出たアドバイザリーは、それらのアップデートが当初の脆弱性の修正に失敗したことを意味するものでもありません。

CMSの更新だけでは、すべての穴は塞げない

脆弱なコンポーネントは、Webサイトのアプリケーションの下層にあります。 Wizの研究者らは、WordPress、Drupal、Joomlaの各環境に対する認証不要のリモートコード実行を実証しました。ただし、根本的な弱点はPHP自体にあるとしています。

WordPressプラグインの悪用への対応に慣れた組織にとって、これは確認作業の中身が変わることを意味します。プラグインやコンテンツ管理システムを更新しただけでは、そのPHPランタイムに修正が適用されたことの証明にはなりません。

Arcovaのサイバーセキュリティ研究者で、アドバンスト・サービス責任者のジョセフ・ペリー氏は、今回の対応を、ECサイトなどAPI主導のWebアプリケーションにとっての「重要な更新と監視の期間」だと表現しました。

「ブログやWebサイトを運営するすべての人にとって、複雑さを抑え、すべてを更新し、ベストプラクティスを守り続けるよい機会です」とペリー氏は述べています。

実践的なフォローアップとしては、ホスティング事業者やアプリケーションの所有者に対し、公開している各サイトがどのランタイムで動いているか、どのベンダーのパッケージが脆弱性を修正しているか、そして稼働中のワーカーやコンテナが実際に更新を取り込んだかを尋ねることが挙げられます。

米国家安全保障局（NSA）のアドバイザリーは、ログの強化に加え、互換性のあるパッチを適用できないサポート終了（EOL）のPHPサービスを置き換えることも推奨しています。すぐに更新できない場合は、完全に緩和できるまでシステムをオフラインにするよう勧めています。管理者にとっては、サポート対象の環境で更新を確認するだけでなく、サポート対象外のシステムを洗い出すことも対応の一部になります。

一時的な対策も精査が必要です。 AWSの緩和ガイダンスは、WAF（Webアプリケーションファイアウォール）のルールを防御を補助するものと位置づけ、完全な修正はパッチ適用のみだと強調しています。リクエストがブロックされた事実を、修復チケットを閉じる根拠にしてはいけません。

Cloudflareは、攻撃者がペイロードを改変して同社の防御を回避しようとしており、同社のアナリストが検知ルールの更新を続けていると報告しました。こうした動きがあるため、防御側は一時的な対策を初期導入で完了とせず、修復作業の全期間を通じて見直す必要があります。

AIが変える「労力に見合う攻撃コード」の範囲

ペリー氏がより広く懸念しているのは、攻撃コード開発の経済性です。

「今回は、AIが攻撃を可能にしたというより、現実的なものにした興味深いケースです」と同氏は語ります。「この種の攻撃コードを開発する際の障壁は、プラットフォームごと、バージョンごとに、徹底したデバッグを絶えず重ねる必要があることです」

Wizの調査結果もこの見方と一致します。研究者らは、PHPのバージョン、設定、メモリレイアウトをまたいで検証と調整を繰り返したと説明し、AIによって専門家に必要な労力が減ったとしています。

「AIへの防御とは、人間には想像もつかないような未来的な攻撃を防ぐことではありません。人間なら使う手間をかけないような攻撃を防ぐことなのです」とペリー氏は述べています。

これは、確認されたすべての攻撃にAIが使われたことを裏付けるものではありません。ただ、複雑なメモリ破壊の脆弱性は多数の標的に対して悪用するにはコストが高すぎる、という前提には疑問を投げかけています。

「AIが何を可能にするかよりも、何を現実的にするかにはるかに重点を置くべきだということです」とペリー氏は語りました。

その後に起こりうる問題は、見慣れたものです。以前に報じた WP-SHELLSTORMによるWebサイトへのバックドア設置の攻撃活動は、攻撃者が既知の脆弱性を使って永続的なアクセスを確立する手口を示しました。これは別のキャンペーンですが、攻撃者が何を残していく可能性があるかを修復時に考慮すべき理由を物語っています。

対応を終える前にセキュリティチームが確認すべきこと

ブラック・オクトーバー後に最も有益なのは、次の3つの問いに対する答えを文書化することです。どのシステムが露出していたのか、保護はいつ有効になったのか、そしてそれらが引き続き信頼できると確信できる根拠は何か、という問いです。

セキュリティチームは、インターネットに公開している各アプリケーションについて、実際のPHPランタイムと責任を負う担当者を結び付けるべきです。ホスティングサービスは事業者への確認が必要で、コンテナは更新後のイメージが稼働中のワークロードに届いたことの確認が必要です。変更依頼が完了したという事実は、展開された修正を検証した場合に比べて弱い証拠にとどまります。

調査は修復と並行して進める必要があります。保存しているWeb、アプリケーション、エンドポイントのテレメトリを、少なくとも標的化が確認された最も早い日付から確認し、証拠があればさらにさかのぼってください。Webワーカーが起動した想定外のプロセス、無許可のファイル変更、不審な外部への接続は、単独ではPHP2Shellの悪用を証明するものではないものの、調査に値します。ログが欠落している場合は、確信度の限界として記録しておくべきです。

侵害をうかがわせる証拠がある場合は、パッチ適用をインシデント対応の一部として扱ってください。影響範囲を特定し、永続化の仕組みを除去し、アクセス可能だった認証情報やトークンの交換が必要かどうかを評価したうえで、復旧完了を宣言します。

関連記事： NextcloudサーバーのCollaboraの脆弱性を突く攻撃は、パッチ適用後にWebシェルや過去の侵害の確認が必要な理由を示しています。