Japanese

ランタイムにパッチを適用した上でフットプリントを検証する

ランタイムにパッチを適用した上でフットプリントを検証する
PHP2Shellとは、CVE-2026-109618とCVE-2026-109619のことです。どちらもCVSS v4.0で9.2(Critical)と評価されています。PHPセキュリティチームによると、どちらも認証なしのリモートコード実行につながり得ます。WordPressのプラグインやアプリケーションフレームワークを更新しても、PHPランタイムの更新の代わりにはなりません。

PHP自体に存在する2つの欠陥

1つ目の欠陥では、メモリ不足(OOM)による中断で、部分的にしか初期化されていないリクエストデータが残ることがあります。PHPは後のクリーンアップ処理でそのデータを使用します。2つ目の欠陥では、リクエストが所有する状態が、メモリ解放後も残り続けます。その状態に、同じワーカーが処理する後続のリクエストがアクセスします。

PHPのアドバイザリには、Apache mod_phpに対するリモートコード実行が確認されたことが記載されています。また、2つ目の欠陥については、検証済みのPHP-FPMセッションライフサイクル経路も記載されています。適用可否は、SAPI、設定、リクエスト経路によって異なります。詳細は、上流(PHPプロジェクト)のアドバイザリをご覧ください。

図:CVE-2026-109618と109619に関するPHPプロジェクトのアドバイザリに基づく概念図。攻撃手順ではありません。

271万のIPが、修正前のPHPビルドを公開していた

同じ30日間の期間内に、Driftnetは、観測された少なくとも1つのサービスで、上流で脆弱とされるPHPバージョン文字列を持つIPを、重複なしで2,705,148件特定しました。このうち2,022,485件は、上流でサポート対象外のブランチを公開していました。別の完全一致ビルドのクエリでは、上流の修正済み4リリースのいずれかを公開しているIPが、重複なしで3,674件見つかりました。

バージョン判定には、PHPの修正済みしきい値である8.2.35、8.3.36、8.4.27、8.5.12を使用しています。これより古いリリース済みブランチには、上流のアップデートがありません。この判定により、対応担当者は、バージョンに基づく優先対応グループを把握できます。パッチの適用状況を確定するには、ベンダーのバックポートも含め、実際に稼働しているパッケージやプロバイダーのアドバイザリを確認してください。

出典:Driftnetのバージョンステータスクエリ結果と、PHPの修正済みリリースに関するアドバイザリ。これらは独立した重複なしIPのグループであり、円グラフの各部分ではありません。1つのIPが複数のPHPサービスをホストしていたり、期間中に修正前ビルドと修正済みビルドの両方が見られたりする場合があります。

767万IPのPHPフットプリント

Driftnetでproduct-tag:phpを完全一致で検索すると、30日間で重複なしの7,669,724件のIPが確認されます。これとは独立したPHPのCPEクエリでは、重複なしで7,664,924件のIPが返されます。汎用のPHP CPEや、Apache/PHPのServerバナーも、ランタイムとデプロイ状況を確認する際の有用な入り口になります。

出典:認証済みDriftnetの30日間クエリ結果。各クエリは固定期間内でIPの重複を除外しています。クエリ間で対象が重複する場合があります。

このグローバルな出発点から、アナリストは、バージョン、デプロイ状況、ネットワーク、確認済みの所有者情報へと絞り込み、修復の方向性を決められます。

複数のシグナルが、数百万の手がかりになる

同じ30日間に、Driftnetは、HTTPヘッダーにPHPが含まれるIPを重複なしで2,818,686件、PHPSESSIDヘッダーのマーカーを持つIPを1,539,338件、ServerバナーにPHPが含まれるIPを851,447件確認しました。これらの検出チャネルは、アナリストが技術を裏付け、特定のサービスに絞り込むのに役立ちます。

裏付けとなるPHPシグナル
シグナルごとの重複なしIP数・30日間固定

出典:Driftnetの重複なしIPクエリ結果。1つのサービスが複数のシグナルのグループに含まれる場合があります。

ブランチ別に見える「ロングテール」

個別のブランチで最大のグループは、PHP 7.4の551,860件の重複なしIPです。PHP 8.3と8.2はそれぞれ25万件を超えており、古いPHP 5.xや7.xのブランチも目立ちます。このブランチ別の見方により、各チームは、PHPプロジェクトの修正済みリリース一覧と照らし合わせて、ランタイムの調査に優先順位を付けられます。

PHPブランチ別のフットプリント
PHP CPEブランチ別クエリごとの重複なしIP数・30日間固定

出典:Driftnetのブランチ別クエリ結果。各ブランチは独立して重複を除外しています。複数のPHPサービスをホストするIPは、複数の行に現れる場合があります。

バナーデータで際立つApache/PHP

30日間に、ServerバナーにApacheとPHPの両方を表示していたIPは、重複なしで792,932件ありました。これは、ServerバナーにPHPが含まれる851,447件のIPのうち93.1%にあたります。SAPIやアプリケーション経路を検証するうえで、絞り込みやすい対象グループになります。

デプロイのシグナル
Serverバナーのクエリごとの重複なしIP数・30日間固定

出典:Driftnetの30日間の重複なしIPクエリ結果。バナーの証拠は、的を絞ったデプロイ検証の指針になります。

PHPタグ付きIPが集中している場所

Driftnetの30日間のproduct-tag:phpクエリは、世界全体で重複なしの7,669,724件のIPを返しました。国別の一意IPクエリでは、最大のグループは米国(169万)、フランス(120万)、ドイツ(82万8,600)の順です。同じ検索から、ルーティングネットワークに絞り込み、プロバイダー単位のフォローアップを行うこともできます。

国別のPHPタグ付き一意なIP
国別クエリごとの重複なしIP数・2026年9月21日〜10月21日

地図上の各国の色は、その国の30日間クエリにおける重複なしIP数を表します。国別のグループは個別に重複を除外しており、期間内で重複する場合があります。

出典:Driftnetの国別カーディナリティ、Natural Earthのジオメトリ、地図データ結果。

最大の国別グループ
国別のPHPタグ付き重複なしIP

出典:30日間の国別IPカーディナリティ。

選択したルーティングネットワーク
ASNクエリごとのPHPタグ付き重複なしIP

出典:30日間のASN別IPカーディナリティ。ASNはルーティングネットワークを識別します。

グローバルなシグナルから、実行可能なポートフォリオへ

インターネットインテリジェンスは、レイヤーを重ねるほど有用になります。コンポーネント、バージョン、デプロイ状況、ネットワークの情報を組み合わせることで、パッケージ検証やベンダーへの問い合わせの対象を、正確なキューとして組み立てられます。

ポートフォリオ規模では、観測した各ホスト、IP、ポート、フィンガープリント、スキャン時刻、帰属のリンクを保存してください。得られたサービスは、直接のベンダーと、検証済みの第四者関係ごとにグループ化します。その結果、サービス固有のパッチ適用依頼と、グローバルなシグナルから修復の証拠までをたどれる、確認可能な記録が得られます。

修正はすでに提供されています

PHPプロジェクトは、メンテナンス中の4つのブランチすべてに修正ビルドをリリースしました。運用者は、自分のブランチの修正ビルド、または、これらのCVEの修正が含まれることが明記されているディストリビューションやLTSベンダーのパッケージを使用してください。PHP 8.1以前には、上流プロジェクトからのアップデートはありませんが、一部のベンダーは古いパッケージ系統向けにバックポートを提供しています。

上流の修正済みリリース
以下の各リリースで、両方のCVEが修正されています。

出典:PHPセキュリティアドバイザリとリリース通知。Ubuntuも、バックポートを含む修正済みディストリビューションパッケージを掲載しています。

30日間における修正済みビルドのフィンガープリント
上流CPEの完全一致クエリごとの重複なしIP数

出典:Driftnetの完全一致ビルドのIPカーディナリティ。バックポートを含むパッチの適用状況は、パッケージやプロバイダーの証明によって確定します。

参照記録:CVEDetails 109618・CVEDetails 109619。パッチバージョンは、PHPプロジェクトのリリースアドバイザリに従っています。

攻撃の試みはすでに観測されています

Cloudflareは、10月21日に顧客を狙った攻撃トラフィックがあったと報告し、攻撃者が保護を回避しようとしてペイロードを変化させていると述べました。この動きにより、パッチ適用と、的を絞ったログ確認の緊急性が高まっています。PHPプロジェクトは、特定の経路での悪用可能性を確認しています。各チームは、ランタイムとデプロイに関するインテリジェンスを使って、対応の優先順位を付けられます。

「自社のWebサービスのうち、パッチ未適用のPHPパッケージが実際に動いているのはどれか?」。これが、今日答えるべき問いです。

優先すべきは、直接到達可能なApache mod_phpのデプロイ、公開されているアップロード経路、サポート対象外のPHP系統、重要度の高いアプリケーションです。マネージドホスティング、アプライアンス、コンテナ、サードパーティのサービスも、インベントリに含めてください。プロバイダーがランタイムを運用している場合は、アプリケーションのバージョンに頼らず、CVE固有のパッチ適用証明を求めてください。

修復し、再起動し、確認する

  1. すべてのPHPランタイムを棚卸しする。
    Webホスト、イメージ、マネージドプラットフォーム、組み込み製品を検索します。
    SAPI、実際のパッケージビルド、プロバイダー、インターネットからの到達可能性、所有者を収集します。稼働中のランタイムビルドは、パッケージインベントリで確認してください。
  2. 修正済みのPHPまたはベンダーパッケージをインストールする。
    上流では、8.2.35、8.3.36、8.4.27、8.5.12のいずれかが対象です。ディストリビューションのバックポートを使う場合は、ベンダーのアドバイザリと、修正済みパッケージの完全なリリース情報を、証拠として保管してください。古いブランチについては、サポート対象バージョンへのアップグレードを計画します。
  3. 稼働中のサービスを再起動し、検証する。
    Apache、またはすべてのPHP-FPMプールを再起動し、コンテナを再作成します。再起動後、稼働中のワーカーのランタイム/パッケージの状態を確認してください。パッケージをインストールしただけでは、長時間稼働するワーカーは更新されません。
  4. パッチ適用中はエクスポージャーを減らす。
    修正をすぐに適用できない場合は、公開アクセスを制限するか、PHPサービスをオフラインにします。WAFが使える環境では、保護をブロックモードのままにしてください。PHPプロジェクトは、管理者としてsession.upload_progress.enabled=0を設定することを推奨しています。OOM経路については、memory_limit=-1に加え、控えめなリクエスト制限とcgroupによる封じ込めを推奨しています。これらは一時的なリスク低減策であり、完全な修正ではありません。運用への影響を確認し、ワーカーを再起動してください。
  5. 調査し、証明する。
    WebログとPHPログを確認し、異常なマルチパートリクエスト、繰り返し発生する致命的エラーやメモリ障害、シェルやダウンロードツールを起動するPHPワーカープロセスを探します。WAFのイベントや、予期しない子プロセスも調べてください。修復後に再スキャンし、オリジンへのアクセス制御を検証して、パッケージまたはプロバイダーの証拠がある場合に限り、各資産を完了とします。

暫定的な設定の詳細(設定を有効にすべき場所や、RLIMIT_ASとRLIMIT_DATAが適さない理由など)は、PHPのアドバイザリに記載されています。CloudflareのWAFに関する調査は、観測された攻撃の試みを記録しており、それでもパッチ適用が必要であることを改めて示しています。

このブリーフの読み方

Driftnetのすべてのグラフは、固定の30日間(2026年9月21日21:10 UTCから2026年10月21日21:10 UTC)における、重複なしIPのカーディナリティを示しています。見出しの数値には、上記のリンク先の、product-tag:phpの完全一致検索を使用しています。CPE、バナー、ヘッダーのグラフは、それぞれ記載した独立したフィルターを使用しています。国別とASN別の各行は、それぞれのクエリ内でIPの重複を除外しています。行同士は重複することがあり、世界全体の見出しの数値には合算していません。パッチの適用状況は、パッケージまたはプロバイダーの証拠で確認します。

返されたバージョンの分類方法

バージョンステータスのグラフでは、観測されたPHPのCPEを、リリース済みの3.x、4.x、5.x、7.x、8.0〜8.5のブランチごとにグループ化しています。8.2.35、8.3.36、8.4.27、8.5.12を下回るバージョンと、上流のアップデートがない古いブランチは、修正前グループに入ります。この4つの修正済みビルドに完全一致するものは、修正済みグループに入ります。各グループは、独立した30日間の重複なしIPクエリです。アップグレード後や、複数のPHPサービスをホストしている場合は、同じIPが両方に現れることがあります。また、ベンダーのバックポートにより、古い上流バージョン番号のままでも保護されているパッケージがあります。

プロバイダー全体で共有されているエクスポージャーを確認する方法

SecurityScorecardのスキャン機能は、テレメトリを用いて、露出したインフラを検出し、露出したPHPを実行しているベンダーを特定できます。Driftnetアドオンを利用しているTITAN Secureのお客様は、以下のように、php2shell対応ワークフローを作成できます。

This week’s threat is PHP2 shell, two critical flaws in PHP itself, exploited in the wild within a day of leaking. In findings, filter by finding name. Enter the first PHP2 shell CVE 20209618 and select it. Then the second 109619. Grouped by name both CVEs show up as high threat vulnerabilities each across eight vendors with more than 14,000 findings apiece. When nothing is clearly more urgent than anything else, vendors have no reason to act. The ask isn’t defensible, so it gets deprioritized or pushed back on and nobody has acted yet. All 14,085 are open with no vendor response and no remediation engagement. Group by vendor to see exactly who’s exposed. Eight vendors, rank by finding count. Now act, back in the name view, select both findings, then actions, request remediation. Two of the eight vendors don’t have contacts yet. Deselect them or continue and add contacts later. Six vendors are ready to go with their contacts already filled in. Preview the email. It tells each vendor that United Banking identified two open findings across their public facing systems and asks them to log in to review and resolve them. Review and send 28,102 findings, 16 contacts across six companies. The findings get flagged for vendor attention. The contacts get an email and they can log in free to track progress, send the request, and every exposed vendor gets one specific Finding level and CVE level targeting gets vendors to fix the specific issues that matter instead of deprioritizing a bulk request across everything. And outreach goes out from one coordinated channel instead of scattered email and tickets. So every vendor gets a unified, defensible ask. And next time, the response doesn’t have to start with a person. Under the old model, by the time a person driven response starts, the window has already closed. The team learns about a threat, then figures out who’s exposed, then reaches out, each step waiting on someone. Here, security event vendor outreach runs on a confirmed vendor breach event and sends remediation outreach if it’s warranted. Continuous monitoring sends remediation requests to vendor contacts on a schedule. You decide how much of the workflow runs on its own and how much waits for a person. It isn’t all or nothing. See every vendor, understand actual risk, prioritize what matters, remediate it automatically. This is Titan AI, the only platform that owns both the data and the workflow in one system. So a finding doesn’t just produce a score, it produces a resolved issue. That’s Titan AI end to end.

参考リンク

  • PHPセキュリティチーム:リリースアドバイザリと緩和策
  • PHPプロジェクトのアドバイザリ:CVE-2026-109618・CVE-2026-109619
  • Ubuntu:パッケージ修正の一覧と再起動に関するガイダンス
  • Cloudflare:観測された攻撃トラフィックとWAFによる保護
  • Driftnetの30日間の一意IPクエリ結果
  • バージョンステータスのクエリ結果
  • 国別ヒートマップのデータとジオメトリの結果
  • PHPの完全一致検索を確認する:https://driftnet.io/search/summary?e=product-tag%3Aphp

詳しくは、当社のお客様向けアドバイザリブログをご覧ください。