ゼロデイ攻撃・Nデイ攻撃とは？脆弱性公表後に危険が増す理由とパッチマネジメント実務

2026.07.29

この記事のまとめ

脆弱性を突く攻撃は、公表の前後で性質が大きく変わります。ゼロデイ攻撃とNデイ攻撃の違いを押さえ、公表後に危険が高まる理由を理解することが、被害を防ぐ第一歩です。

ゼロデイ攻撃は修正プログラムが未提供の段階で行われる攻撃で、Nデイ攻撃は公表済みの脆弱性を対策前に突く攻撃です。
実証コードの公開から悪用までの時間は短く、公表初日から悪用される事例が確認されています。
パッチマネジメントは資産把握、優先度付け、適用と記録の三段階で回すことが実務の要です。
修正プログラムがない前提の多層防御とSBOM活用が、ゼロデイ耐性を高めます。

ゼロデイ攻撃・Nデイ攻撃の定義

ゼロデイ脆弱性とゼロデイ攻撃

ゼロデイ攻撃とは、修正手段が世に出る前の脆弱性を突く攻撃を指します。

脆弱性対策情報が公表される前の脆弱性をゼロデイ脆弱性と呼び、それを悪用する攻撃がゼロデイ攻撃です。ソフトウェアの脆弱性管理が不適切な場合、未対策の期間が長引き、被害に遭うリスクが大きくなります（参照*1）。

利用者側から見ると、ゼロデイ攻撃は「知らないうちに攻撃を受ける」性質を持ちます。修正プログラムが存在しないため、パッチを当てるという通常の防御手段が使えません。そのため、後述する検知や緩和策との組み合わせで守る発想が必要になります。

Nデイ脆弱性とNデイ攻撃

Nデイ攻撃は、修正プログラムや回避策が出た後、利用者が対策を終える前の期間を狙います。

IPAは、パッチや回避策が公開されてから利用者が対策を講じるまでの期間の脆弱性をNデイ脆弱性と呼び、その期間に行われる攻撃をNデイ攻撃としています（参照*1）。

Nは任意の日数を意味し、公表から適用完了までの日数が長引くほど、Nデイ攻撃の窓が広がります。攻撃者は公開された修正内容や解析情報を手がかりに、未対策の組織を効率的に狙います。

言い換えると、公表後の遅い対応そのものがリスク要因になります。利用者にとっては、脆弱性の公表は「情報を得た瞬間」であると同時に「攻撃されやすさが高まる瞬間」でもある点が重要です。

CVE・CVSS・CWEの基礎

脆弱性情報を扱うには、識別と評価の共通語彙を押さえる必要があります。

IPAの資料は、個別製品中の脆弱性に一意の識別番号を付ける仕組みをCVEと説明し、これにより異なる組織の脆弱性対策情報を相互参照や関連付けに利用できるとしています。深刻度の評価には共通脆弱性評価システム（CVSS）があり、ベンダーに依存しない共通の評価方法を提供する枠組みだと記しています（参照*2）。

JVN iPediaに2026年に登録された脆弱性対策情報の深刻度別割合は、緊急が15.7%、重要が40.6%、警告が41.7%、注意が2.0%でした（参照*3）。

実務ではCVE番号で対象を特定し、CVSSの基本値で深刻度の目安をつかむ流れが基本です。数値だけで判断せず、自組織の利用状況と合わせて解釈することが、後段の優先順位付けにつながります。

脆弱性公表後に危険が増す理由

PoC公開から攻撃ツール化までの短期化

公表と同時に、攻撃者側の準備も一気に進みます。

米国CISAの資料によると、公に悪用が確認されたCVEは全体の4%にとどまるとした上で、その悪用のうち42%が公表初日に、50%が2日以内、75%が28日以内に行われています（参照*4）。

IPAの技術レポートは、ある脆弱性について3月7日に実証コードが公開されたことをきっかけに攻撃が多発し、国内でも複数の組織が攻撃を受け、数十万件単位のクレジットカード情報やメールアドレスといった個人情報が窃取される被害が出たと記しています。同レポートは、脆弱性の発見から攻撃に使われるまでの時間が短くなっており、影響度の大きい脆弱性情報を早期に把握して対策を実施することの重要性が高まっています（参照*2）。

つまり、公表から数日という短い時間軸で対応方針を決めることが求められます。

KEVカタログと実悪用の実態

実際に悪用されている脆弱性を絞り込む仕組みが、既知の悪用脆弱性カタログ（Known Exploited Vulnerabilities、KEV）です。

米国CISAは、KEVカタログの脆弱性の是正を優先することを全組織に強く推奨し、連邦民間行政機関に対しては拘束的運用指令BOD 22-01に基づき、定められた期限内に是正することを求めています（参照*5）。

CISAは2021年11月3日にBOD 22-01を発出し、特定のCVSSスコアだけに注目する従来の方針を改め、既知の悪用手段があり、悪意ある攻撃者に実際に悪用されている脆弱性を是正対象とする方針に転換しました（参照*4）。

この考え方は、深刻度の高さだけで判断するのではなく、実際の悪用有無を加味する視点を与えます。自組織のパッチ運用でも、KEV掲載の有無を優先度の重要な判断材料に加えることで、限られた工数を実際の脅威に振り向けられます。

最近の代表的な攻撃事例

Microsoft Defenderの権限昇格脆弱性

セキュリティ製品自体が狙われる事例もあります。

JVN iPediaは、Microsoft Malware Protection Engineにおけるリンク解釈に関する脆弱性を掲載し、Microsoft Defenderのファイルアクセス前の不適切なリンク解決により、認可された攻撃者がローカルで権限を昇格させる可能性があると指摘しています（参照*6）。

マイクロソフトは2026年6月9日(米国時間)に、マイクロソフト製品に影響する脆弱性を修正するためのセキュリティ更新プログラムを公開し、今月の更新で修正した脆弱性のうち一部について、更新プログラム公開前に悪用が行われていることや、詳細が一般に公開されていることを確認したと発表しました。同社は利用者に更新プログラムの早急な適用を求めました（参照*7）。

この事例からは、セキュリティ製品も脆弱性対応の対象であり、更新運用が重要だとわかります。

React Server ComponentsとMOVEit Transfer

広く使われる部品やソフトウェアの脆弱性は、被害が広範に及びます。

IPAによると、2025年12月3日にReact Server Componentsの脆弱性が公表され、その翌日にはPoCが公開されています。同資料は、CVSSの深刻度が緊急(基本値10.0)で、世界中で普及している製品であるため、国内外で攻撃が多数確認され、IPAやJPCERT/CCから早急な対策を促す注意喚起が発出されたとしています（参照*1）。

また、2023年5月にファイル転送ソフトウェアMOVEit Transferの脆弱性CVE-2023-34362が公開されたと記録しています。この脆弱性はSQLインジェクションで、認証されていないリモート攻撃者が悪用するとMOVEit Transferに不正アクセスされ、データの窃取や改ざん、権限の昇格を実行される恐れがあります（参照*8）。

両事例に共通するのは、利用範囲の広さと深刻度の高さが被害を増幅させる構図です。自組織が直接開発していない部品にも、こうしたリスクが潜んでいる前提で情報収集を組み立てる必要があります。

パッチマネジメントの実務手順

情報収集と資産把握

パッチマネジメントの起点は、守るべき対象と得るべき情報を揃えることにあります。

IPAの技術レポートは、効果的な脆弱性対策として、全ての脆弱性に闇雲に対応するのではなく、攻撃の容易さや影響などのリスクを考慮して行うことがポイントだとし、多数の情報から自組織に関連する脆弱性情報を収集し、組織への影響度を考慮した上で早期に対応を判断することが重要だと記しています（参照*2）。

JVN iPediaのガイドは、大量の脆弱性情報から自組織に関連する情報を抽出する作業には多くの手間がかかるとし、自組織で利用するソフトウェアの情報をフィルタリング収集できるMyJVN 脆弱性対策情報フィルタリング収集ツールを公開しているとしています。このツールを利用することで必要な情報だけを確認でき、より迅速な情報収集が可能になります（参照*9）。

実務では、資産台帳の整備と、その資産に対応する情報源の登録を先に行うことが起点です。ここが曖昧だと、以降の優先順位付けも精度が下がります。

優先度付けと適用判断

収集した情報は、優先度を付けて処理する必要があります。

JVN iPediaのガイドは、脆弱性は日々公開されており、時間の経過とともに攻撃による被害リスクが増大していくとし、被害回避のためにはリスクを考慮し優先度を付けて対策すること、迅速な対応を実施することが重要だと記しています。同ガイドは、危険度や緊急度が高いセキュリティ上の問題と対策を重要なセキュリティ情報として公開しており、危険度の高い脆弱性に絞って対策することで被害リスクを大幅に低減できます（参照*9）。

CISAは、2021年11月3日にBOD 22-01を発出し、特定のCVSSスコアに絞る従来の方針から、既知の悪用手段があり、悪意ある攻撃者に実際に悪用されている脆弱性を是正対象とする方針に転換したと説明しました（参照*4）。

加えて、NVDのAPIには、CISAのKEVカタログに掲載されたCVEのみを返すhasKevパラメータや、KEV掲載期間を指定するkevStartDateおよびkevEndDateパラメータが用意されています（参照*10）。深刻度と実悪用の両方を軸に、自組織向けの判断基準を明文化することがポイントです。

適用・検証・記録の運用

決めた優先度に沿って、適用と検証、記録を回す段階に入ります。

JVN iPediaの資料は、2026年に登録した脆弱性対策情報の深刻度別割合を、緊急15.7%、重要40.6%、警告41.7%、注意2.0%と示し、既知の脆弱性による脅威を回避するため、製品開発者に対して常日頃から新たに報告される脆弱性対策情報に注意を払い、脆弱性が解消されている製品へのバージョンアップやアップデートを速やかに行うよう求めています（参照*3）。

マイクロソフトは、2026年6月の更新で修正した脆弱性のうち一部について、更新プログラム公開前の悪用や詳細の一般公開を確認したとし、利用者に早急な適用を促しました（参照*7）。

運用面では、適用前のバックアップ、影響範囲の確認、適用後の動作検証、そして誰がいつ何を適用したかの記録を一体で扱うことが実務の柱になります。記録を残す運用は、次のNデイ対応の速度も高めます。

ゼロデイを前提とした多層防御

検知と緩和策の組み合わせ

修正プログラムがない前提の備えが、ゼロデイ耐性を左右します。

IPAの資料は、ゼロデイ攻撃への対策として、修正パッチが無いことを前提とした多層防御と、異常を検知する仕組みや体制の構築を挙げています。被害の早期検知の観点から、PCやサーバー、ネットワーク機器、Webサイトなどに適切なセキュリティ対策を行うことも求めています（参照*1）。

IPAの別資料は、米国では業種や企業規模に依存しないサイバーセキュリティ対策のフレームワーク（Cyber Security Framework、CSF）が定められており、そのVersion 2.0が2024年2月に公開されたとしています。CSFは、識別、防御、検知、対応、復旧、統治の六つのカテゴリーで構成されると記しています（参照*8）。

ゼロデイ対策は防御だけでなく、検知と対応、復旧までを設計する視点が要になります。日常の運用の中で、異常兆候をいかに素早く拾えるかが被害の分かれ目となります。

SBOMとサプライチェーン対策

利用ソフトウェアの中身を可視化することが、素早い判断につながります。

IPAの資料は、ソフトウェアの把握や管理においてはソフトウェア部品表（SBOM）の導入を検討するよう挙げています（参照*1）。SBOMは、自組織が使う製品にどの部品が含まれているかを一覧化する仕組みです。

React Server Componentsのように広く使われる部品に緊急の脆弱性が出た場合、自組織のどのシステムが影響を受けるかを短時間で見極める必要があります。部品表があれば、公表直後に影響資産を洗い出し、優先度付けと適用計画に直結できます。

供給元の情報だけに頼らず、自組織側でも構成情報を保持しておく姿勢が、Nデイ攻撃の窓を狭める土台になります。

おわりに

ゼロデイ攻撃とNデイ攻撃は、脆弱性の公表時点を境に姿を変える一連の脅威です。公表前は修正手段が無いことを前提とした多層防御と検知で備え、公表後は情報収集、優先度付け、適用と記録という手順を速く回すことが要となります。

パッチマネジメントは単なる更新作業ではなく、資産把握、リスク判断、運用記録が結びついた運用です。KEVカタログやSBOMの活用も含め、自組織の実情に合わせた仕組みを整えることがポイントです。

お知らせ

ゼロデイ攻撃・Nデイ攻撃・パッチマネジメントはリスク評価と迅速な対応が鍵です。攻撃ツール化までの時間が短縮されている現在、継続的な資産把握と優先度付けに基づくパッチ適用の仕組みを構築することは、組織全体のセキュリティ態勢を左右する重要な仕事です。インフラエンジニアのスキルの需要は高まっています。

cyseekではフリーランスのITエンジニア向けの案件をご紹介しています。案件に関する新着情報は、以下のリンクからご覧いただけます。

参照

cyseekはサイバーセキュリティ人材向けの案件紹介サービスサイトです。

サイバーセキュリティ業界に精通したエージェントが求人紹介、年収交渉、キャリアアップの実現など、採用課題の整理から稼働後のフォローまでトータルにサポートするほか、保有するノウハウを活かしフリーランスやサイバーセキュリティ人材に向けたコラムを発信しています。