2026年2月は、2月10日のMicrosoft月例更新で悪用確認済み（Exploited:Yes）の脆弱性が6件並んだ後、2月13日にGoogle Chrome、2月17日にDell RecoverPoint for Virtual Machines（RP4VMs）でも野生利用中の脆弱性が明示された月となった。防御側にとって重要なのは、個別CVEの深刻度だけではなく、「エッジ公開面」「管理プレーン」「クライアント実行環境」で同時に攻撃面が開く構造である。

本稿は、CVE-2026-2441（Chrome）とCVE-2026-22769（Dell RP4VMs）を比較し、CISA KEV追加が意味する運用優先度、ならびにエンタープライズ向けの「ゼロデイ前提」実装を整理する。

2026年2月の時系列: ゼロデイが複数レイヤーで同時進行した

Microsoftの2026年2月CVRF（2026-Feb）では、Exploit Statusに「Exploited:Yes」を持つ脆弱性が6件確認できる。ここに、2月13日のChrome安定版更新（CVE-2026-2441）と、2月17日のDell DSA-2026-079（CVE-2026-22769）が重なったことで、攻撃者にとっては初期侵入経路と横展開経路の選択肢が増えた。

CISA KEVカタログでは、CVE-2026-2441が2026年2月17日、CVE-2026-22769が2026年2月18日に追加されている。期限はそれぞれ2026年3月10日、2026年2月21日であり、後者は運用上ほぼ即応を要求する設定である。これは、同じ「ゼロデイ」でも資産種別により是正猶予が異なることを示す。

Chrome CVE-2026-2441: CSS use-after-freeが示すクライアント側リスク

Googleは2026年2月13日のStable Channel Updateで、Windows/Mac向け145.0.7632.75/76（Linuxは144.0.7559.75）を公開し、CVE-2026-2441（CSSにおけるuse-after-free）を修正した。Chrome Releasesは同日、「当該CVEのexploitが野生で存在する」と明記している。

NVDの記述では、この欠陥は細工されたHTMLページを介してサンドボックス内で任意コード実行を許し得る（CVSS 8.8）。実運用での含意は、単独でドメイン全体侵害に直結するとは限らないが、ブラウザ起点の足場形成として十分に危険という点である。特に、ブラウザ更新遅延、未管理端末、拡張機能の過剰権限が重なる環境では、フィッシング到達後の滞在確率が上がる。

防御設計上は、端末管理（バージョン強制・期限付き更新）とWebアクセス層（URL/コンテンツ隔離）を別チームに分離せず、同一SLOで運用することが有効である。Chrome系ゼロデイは「閲覧行為」そのものがトリガーになり得るため、メール防御やSWGだけで閉じない。

Dell RecoverPoint CVE-2026-22769: ハードコード認証情報からroot持続化まで

Dell DSA-2026-079（2026年2月17日公開）は、RP4VMsの6.0.3.1 HF1未満にハードコード認証情報（CWE-798）が存在し、認証なしの遠隔攻撃者が基盤OSへ不正アクセスし、rootレベル持続化に至り得ると説明する（CVSS 10.0）。DellはGoogle/Mandiantから限定的な実攻撃報告を受けたことも明記した。

Mandiant/GTIGは2026年2月18日の技術公開で、Tomcat Managerへの不正デプロイ（`/manager/text/deploy`）により悪性WARが投入され、SLAYSTYLE/BRICKSTORM/GRIMBOLT運用へ接続されたと述べる。加えて、活動は少なくとも2024年半ばから観測されていたとされ、修正公開時点で既に長期間の潜伏・横展開が進行していた可能性が高い。

この系統の本質は、アプライアンスを「信頼された内部機器」とみなす運用慣行である。Dell自身もRP4VMsを信頼済み・アクセス制御済み内部ネットワークに配置すべきと勧告しており、インターネット到達性や広い管理ネットワーク許可を残す設計は、ゼロデイ時に即座に破綻する。

CISA KEV追加の意味と、ゼロデイ前提パッチ管理の実装戦略

KEV追加は「理論上危険」ではなく「既に悪用確認済み」を意味する。したがって、CVSS中心の月次優先度ではなく、KEV dateAddedとdueDateを起点にした週次運用に切り替える必要がある。特にアプライアンス系CVSS 10.0は、変更管理プロセスを短縮する例外フローを事前定義しなければ実効性が出ない。

実務では以下の4層が有効である。第一に、ブラウザとエッジ機器を「72時間是正対象」として別キュー化する。第二に、管理プレーンの露出最小化（到達元IP制限、ジャンプホスト化、外向き通信制限）を平時から固定する。第三に、機器ログからの検知観点をテンプレート化し、Tomcat Managerの`/manager`アクセスやWAR展開痕跡を定常監視する。第四に、侵害前提で認証情報ローテーションとセグメント再分離を同時実施する。

結論として、2026年2月の事例は「ゼロデイを防げるか」ではなく、ゼロデイが出た瞬間にどの経路を切断できる運用設計になっているかを問うている。ChromeとRP4VMsは対象資産が異なるが、運用上の答えは同じである。到達性の最小化、更新の即応化、そして侵害後を含む多層防御である。

FAQ

Q1. CVE-2026-2441はChrome更新だけで十分か？

更新は必須だが十分条件ではない。ブラウザ起点の攻撃はフィッシング導線と組み合わさるため、URL防御、添付ファイル隔離、権限最小化、端末EDRの相関運用が必要である。

Q2. CVE-2026-22769はパッチ適用前に何を優先すべきか？

最優先は管理プレーン露出の削減である。外部公開の遮断、管理ネットワークのアクセス制御、監査ログ保全、疑わしい`/manager`アクセスの調査を先行し、その上で6.0.3.1 HF1またはDell提供の緩和スクリプトを適用する。

Q3. KEV追加をSOC運用にどう組み込むべきか？

KEVの`dateAdded`と`dueDate`をチケット自動生成のトリガーにし、対象資産台帳と突合して期限逆算の修正計画を自動化する。月次レビューではなく、週次または日次での追跡が望ましい。

参考文献