PHPの2件がCISAの悪用済み脆弱性一覧に、修正の反映時点も確認を

脆弱性はプログラムの弱点で、パッチはその弱点を直したプログラムです。KEV掲載は、弱点があり得るという説明から進んで、実際の悪用根拠があるという運用上の合図です。すべての攻撃方法や被害組織が一覧に公開されるわけではありません。

2件は、リクエスト処理中のメモリや、前のリクエストが残した内部状態を誤って扱う問題です。攻撃者の影響するリクエストが問題の経路に届くと、PHPのサーバープロセスの権限でコードが実行され得ます。到達条件は構成と処理経路で変わります。メモリ不足時の処理・残った内部状態の問題

例えば、架空のホスティング会社Aで脆弱なPHPを使うサイトを考えます。攻撃者のウェブ要求が欠陥を引き起こす条件に届くと、運営者が意図しない命令がPHPの権限で実行される可能性があります。その権限で読んだり変更したりできるファイルは情報流出・改ざんの危険にさらされ、サイトが止まる場合もあります。遠隔コード実行の被害を説明する架空の例で、あらゆるサーバーの全ファイル・全アカウントを支配したという意味ではありません。

PHPはWordPressなどのサーバー側処理を担います。リクエストを受けて働く実行単位をワーカーと呼びます。パッケージを取得しても、既存ワーカーが古いプログラムを動かしていれば、取得した事実だけで反映済みとは言えません。

図は修正の反映を確かめるためにつなぐ記録です。特定の提供元やサイトの現在の完了状態を示すものではありません。

%% 修正反映の確認経路・PHP開発元と運用担当者の役割
flowchart TD
  A["開発元：修正版公開"] --> B["提供元：パッケージ提供"]
  B --> C["運用者：Web PHPへ反映"]
  C --> D["バージョンと時刻を記録"]

今回の2件の最初の公式修正版は次のとおりです。後続版や提供元のバックポートを使う場合は、両方の修正を含むという配布元の根拠を照合します。PHP公式変更履歴

バックポートは修正を既存系列のパッケージへ移す作業です。表示上の番号が同じでもパッケージの改訂が違う場合があるため、提供元の修正履歴とWeb実行環境への反映を一緒に見ます。WordPress本体やプラグインの更新は、サーバーのPHPパッケージを置き換えません。 実際の交換は、バックアップ確保、テーマ・プラグインの互換性と試験環境での点検、反映後のログイン・主要機能確認を担当者と計画します。 WordPressのサーバーPHP更新案内

パッチ適用は同じ弱点を使う以後の攻撃を防ぐ助けになります。その前に何が起きたかは、過去の運用記録で調べる必要があります。CISAは外部公開システムを優先して修正し、PHPプロセスのシェル起動やツール取得などの不審な動きを見るよう勧めています。

担当者は、サイトを外部に公開していた期間と、修正済みのWeb PHPが実際に要求を処理し始めた時点を記録でつなぎます。図の基準点は修正版の発表やファイル取得の時刻ではなく、そのサイトでの反映を確認した時刻です。各区間で見る記録も併記しました。

異常のないログでも、収集していない経路や期間までは調べられません。開発元も、エラーログがないことを安全の根拠にしないよう説明しています。不審な兆候があれば記録を保全し、セキュリティ担当やホスティング支援窓口と調査範囲を決める必要があります。