Fortinet製品のヒープバッファオーバーフローCVE-2025-25249がKEV入りした経緯と対応

2026年9月9日、CISAのKnown Exploited Vulnerabilities Catalog(KEVカタログ)に4件の脆弱性が追加されました。そのうちの1件が、Fortinet製品のヒープバッファオーバーフローであるCVE-2025-25249です。CVE識別子の年号は2025で、予約されたのは2025年2月、CVEとして公開されたのは2026年1月でした。悪用が確認された脆弱性として登録されたのは、そこからさらに約8か月後です。

この記事は、FortiGateやFortiSwitchManagerを運用するネットワーク担当と情報システム担当に向けて、CISAのKEVカタログとアラート、NVDとcve.orgに登録されたCVEレコード、MITREのCWE定義、Siemens ProductCERTのアドバイザリ、FIRSTのEPSSとCVSS仕様書という、その場で確認できる資料だけを土台に整理します。攻撃コードや再現手順は扱いません。記述は執筆時点(2026年9月12日)に確認できた範囲に限ります。

KEVカタログに記録された事実の確認#

まず、CISAが配布しているKEVカタログのJSONフィードから機械的に読み取れる内容を並べます。同じ内容はWeb版のカタログでも参照できます。

CISAのKEVカタログのJSONフィード(執筆時点で確認したカタログバージョンは2026.09.11、収載件数は1709件)には、CVE-2025-25249のエントリとして上表の値が記録されています。shortDescriptionは「Fortinet FortiOS, FortiSwitchManager, and FortiSASE contain a heap-based buffer overflow vulnerability that allows an attacker to execute unauthorized code or commands via specially crafted packets.」です。notes欄にはFortinetのアドバイザリFG-IR-25-084、BOD 26-04とその実装ガイダンス、NVDの該当ページのURLが並んでいます。同じdateAdded 2026-09-09のエントリは、ほかにCVE-2026-19490(Citrix NetScaler)、CVE-2026-87491(Google Chromium V8)、CVE-2026-20079(Cisco Secure Firewall Management Center)の3件です。

読み取るべき点は3つあります。1つ目は、productが個別の型番ではなく「Multiple Products」である点です。KEVのエントリだけでは自社のどの機器が該当するのか判断できないため、CVEレコードとベンダーのアドバイザリに戻る必要があります。2つ目は、dueDateがdateAddedの3日後という短さです。3つ目は、forensicTriageがYesであることです。この項目は、パッチを当てて終わりにするのではなく、すでに侵害されている前提で調べる作業まで視野に入る脆弱性であることを示します。ただしBOD 26-04が実際に3日の期限とフォレンジックトリアージを義務づける範囲は、CVE単位ではなく資産ごとに決まります。対象は米国連邦政府の行政機関であり、その資産が外部へ公開されているか、悪用が自動化可能か、技術的影響が全面的かという組み合わせで、期限とトリアージの要否が表から導かれます。日本の民間組織にとっては義務ではなく、優先度を測るための材料として読むのが妥当です。

同じ日に追加された残る3件のうち、Citrix NetScalerとCisco Secure Firewall Management Centerは境界に置かれる製品で、Google Chromium V8は利用者の端末で動くブラウザのエンジンです。境界の機器と端末のブラウザが同じ日に並ぶこの3件は、当サイトで個別に扱っています。

あわせて読みたい

CVE-2026-19490でNetScaler Gateway/AAA構成の認証が回避される条件と対応の順序

2025年採番のCVEが2026年9月にKEV入りするまでの時系列#

この脆弱性を追いかける価値があるのは、時系列が一般的な感覚とずれているからです。確認できる日付を並べます。

識別子の予約からKEV入りまで約1年7か月、CVEの公開からでも約8か月が経っています。「2025年のCVEだから古い」「もう手当て済みのはず」という判断が、そのまま取りこぼしになる形です。

CVE ServicesのAPIが返すCVE-2025-25249のレコードには、assignerShortNameとしてfortinet、dateReservedとして2025-02-05T13:31:18.866Z、datePublishedとして2026-01-13T16:32:35.662Z、dateUpdatedとして2026-09-10T03:55:15.185Zが記録されています。CNAコンテナのproviderMetadata.dateUpdatedは2026-02-23T08:51:58.404Zです。referencesにはFortinetのアドバイザリ https://fortiguard.fortinet.com/psirt/FG-IR-25-084 の1件が登録されています。

NVDのAPI 2.0が返すCVE-2025-25249のレコードには、sourceIdentifierとしてpsirt@fortinet.com、publishedとして2026-01-13T17:15:56.910、lastModifiedとして2026-09-10T12:47:59.933、vulnStatusとしてAnalyzedが記録されています。cisaExploitAddは2026-09-09、cisaActionDueは2026-09-12、cisaVulnerabilityNameは「Fortinet Multiple Products Heap-based Buffer Overflow Vulnerability」です。あわせてCISA CoordinatorによるSSVC v2.0.3の判定として、Exploitation: active、Automatable: no、Technical Impact: totalが付与されています(このSSVCレコードのtimestampは2026-01-13T00:00:00+00:00と記録されていますが、判断が行われた時点を指すのか、更新時に据え置かれた値なのかはレコードからは判別できません)。

CVEの採番年は「いつ識別子が予約されたか」を示すだけで、公開時期でも危険度でもありません。この点は運用上の落とし穴になります。脆弱性管理の台帳を「CVE番号の年で並べ替え、古いものから既知として扱う」運用にしていると、2026年に公開された2025年採番のCVEは、実際の公開日より1年古い位置に並びます。台帳の並べ替えは採番年ではなく、公開日と自社への到達日で行う必要があります。

あわせて読みたい

CVE・JVNの読み方と脆弱性情報の追い方。採番の仕組みからNVD・ベンダー情報までを整理する

CVSSが7.4と8.1と9.8に分かれる理由#

このCVEは、CVSSの値が出所によって3種類存在します。同じ脆弱性に対して1.7ポイントの開きがあり、深刻度の区分もHIGHとCRITICALに分かれます。

差を生んでいる要素は2つです。1つはAttack Complexityで、FortinetはHigh、NVDはLowとしています。CVSS v3.1の仕様書では、Attack Complexity: Highは「攻撃者の制御下にない条件が存在し、悪用を成功させるには攻撃者が標的コンポーネントに対して測定可能な量の準備を投じる必要がある」場合に選ばれます。ヒープのレイアウトを整える作業が必要なメモリ破壊の脆弱性では、ベンダーがHighを選ぶことは珍しくありません。一方でNVDはLowと判断しており、この1要素だけでスコアは8.1から9.8へ跳ね上がります。

もう1つはCNAレコードにだけ載っている時間評価(Temporal)です。E:P(Exploit Code Maturity: Proof-of-Concept)、RL:W(Remediation Level: Workaround)、RC:C(Report Confidence: Confirmed)が付いており、ベース8.1が7.4へ下がります。NVDのAPI応答はベース部分だけを取り込むため、この7.4という数字はcve.org側のレコードでしか見えません。

FIRSTのCVSS v3.1仕様書は、Attack Complexity: Highを「攻撃者の制御下にない条件が存在し、悪用の成功のために攻撃者が標的コンポーネントに対して測定可能な量の準備を投じる必要がある」場合と定義しています。Exploit Code Maturityの値Proof-of-Concept(P)は、概念実証のコードが利用可能であるか、多くの状況で実用的とはいえない攻撃の実演が可能である状態を指すと説明されています。また仕様書は、Temporal(時間評価)がBaseスコアを上回ることはなく、悪用容易性や修正の入手状況に応じてスコアを引き下げる方向にのみ働くと述べています。

NVDのCVE-2025-25249のページには、NVDが付与したPrimaryのCVSS 3.1スコア9.8(CRITICAL)と、psirt@fortinet.comをsourceとするSecondaryのスコア8.1(HIGH)の両方が掲載されています。弱点分類もNVDがPrimaryとしてCWE-787、FortinetがSecondaryとしてCWE-122を付与しており、2つの値が併記されています。参照リンクにはFortinetのアドバイザリ、Siemens ProductCERTのSSA-864900、Exploitタグの付いた第三者ブログ、KEVカタログの該当エントリが登録されています。

実務で扱うときは、どのスコアを社内基準に採用しているのかを明示しておく必要があります。「CVSS 9.0以上を最優先」というルールを敷いている組織では、NVDを見れば9.8で最優先、ベンダーのアドバイザリを見れば7.4で優先度が下がる、という食い違いが起きます。8.1と9.8の差は評価者の判断が分かれた結果で、どちらも誤りではありません。7.4はこれらと並ぶ第3の評価ではなく、ベース8.1に公開当時の時間評価を掛けた値です。悪用が確認された現在、E:P(概念実証の段階)という時間評価は実態に追いついていないため、現在の深刻度を表す数字としては扱わず、公開時点の履歴として読みます。

あわせて読みたい

CVSSスコアの読み方と脆弱性対応の優先度付け。基本値だけで判断しないために

影響範囲を判定するときの読み違いやすさ#

このCVEは、影響を受けるバージョンの情報が説明文と構造化データで一致していません。運用でバージョン判定をするときは、この差を知らないと取りこぼします。

CVEレコードの説明文が挙げている範囲は次のとおりです。

• FortiOS 7.6.0から7.6.3
• FortiOS 7.4.0から7.4.8
• FortiOS 7.2.0から7.2.11
• FortiOS 7.0.0から7.0.17
• FortiOS 6.4の全バージョン
• FortiSwitchManager 7.2.0から7.2.6
• FortiSwitchManager 7.0.0から7.0.5

一方、同じレコードのaffected配列(CPEとバージョン範囲を機械可読で持つ部分)には、FortiOSが7.6.0から7.6.2、7.4.0から7.4.7、7.2.4から7.2.11の3区間しか記録されておらず、7.0系と6.4系の記載がありません。FortiSwitchManagerも7.2.2から7.2.5の1区間だけです。KEVカタログのshortDescriptionはさらにFortiSASEを加えた3製品を挙げています。

CVEレコードのsolutions欄に載っている修正版は次のとおりです。

cve.orgのCVE-2025-25249のレコードには、CNAとしてfortinet、problemTypesとしてCWE-122(説明は「Execute unauthorized code or commands」)が記録されています。solutions欄には、FortiSwitchManager 7.2.7以降と7.0.6以降へのアップグレード、FortiSASE 25.2.cと25.1.bでの対処済み、FortiOSの8.0.0以降(upcomingと記載)、7.6.4以降、7.4.9以降、7.2.12以降、7.0.18以降へのアップグレードが列挙されています。このsolutions欄を含むCNAコンテナの最終更新は2026年2月23日です。

6.4系については、説明文が全バージョンを影響ありとする一方で、solutions欄に6.4向けの修正版が挙がっていません。SiemensのSSA-864900はこの系列を6.4.0から6.4.16の範囲として記載しており、同じCVEでも出所によって書き方が揃っていません。6.4系を使い続けている機器は、上位の系列へ移す以外の解決手段がレコードからは読み取れないことになります。判定の手順としては、説明文とsolutions欄の両方を見たうえで、自機の系列に対応する修正版に達しているかを確認するのが安全です。構造化データだけを機械的に突き合わせるスキャナを使っている場合、7.0系や6.4系の機器を「該当なし」と判定してしまう余地があります。

なお、solutions欄に「upcoming FortiOS version 8.0.0 or above」と記載されている点は、CNAコンテナが2026年2月23日で止まっていることを示します。執筆時点の最新の入手可能バージョンは、Fortinetの公式アドバイザリFG-IR-25-084とサポートサイトで確認してください。

産業用途の組み込み機器という見落としやすい経路#

FortiOSは、Fortinetのアプライアンスだけに載っているわけではありません。Siemens ProductCERTのアドバイザリSSA-864900は、産業用途のアプリケーションプラットフォームであるRUGGEDCOM APE1808上で動くFortigate NGFWも、このCVEの影響を受けると記載しています。

Siemens ProductCERTのSSA-864900「Multiple Vulnerabilities in Fortigate NGFW on RUGGEDCOM APE1808 Devices」は、公開日2025年5月13日、最終更新2026年8月11日、現在のバージョンV2.0として公開されています。影響を受ける製品として「RUGGEDCOM APE1808、Fortinet NGFWがV7.4.9より前のすべてのバージョン」を挙げ、その対象CVEの一覧にCVE-2025-25249を含めています。対処としてFortigate NGFWをV7.4.9以降へ更新することを案内し、MITIGATIONSの節ではCVE-2025-25249に対する緩和策として「For each interface, remove "fabric" access」を挙げ、参照先としてFG-IR-25-084を示しています。

このアドバイザリから読み取れることは2つあります。1つは、この脆弱性に対して示されている緩和策が、各インターフェースからfabricアクセスを外すという具体的な設定変更である点です。fabricはFortiOSのSecurity Fabric連携のために開けるアクセス種別で、HTTPSの管理画面やVPNのサービスとは別の設定項目です。管理画面の公開範囲を絞ることやVPN経由に限定することは一般的な多層防御として有効ですが、このCVEに対してベンダーやSiemensが示した緩和策そのものではありません。緩和策を適用するときは、インターフェースごとのallowaccessの設定からfabricを外すという範囲で行い、一般的な防御策と混同しないようにします。

もう1つは、資産台帳の粒度の問題です。「FortiGateは何台」という数え方をしていると、第三者製品に組み込まれたFortiOSは台帳から漏れます。産業用ネットワーク機器、通信事業者から提供されたCPE、クラウド上のマーケットプレイスイメージなど、FortiOSが載っている場所は自社のラックの中だけではありません。

ヒープバッファオーバーフローが機器の制御に届く機構#

ここからは、CWEの定義を土台にした一般論です。CVE-2025-25249の実装の詳細を再現したものではありません。

MITREのCWE-122はヒープバッファオーバーフローを、ヒープ上に確保されたバッファ(malloc()などで動的に確保された領域)に対して、バッファの境界を越えて書き込みが行われる欠陥と定義しています。CWE-122はCWE-787(境界外書き込み)とCWE-788(メモリ確保領域の終端より後への書き込み)の両方の子として位置づけられており、CWE-787は境界外書き込み全般を指す抽象度の高い分類の1つです。Fortinetが前者、NVDが後者を付与しているのは、粒度の違いです。

MITREのCWE-122は、ヒープバッファオーバーフローを、バッファがヒープ部分のメモリに確保されている場合の書き込み時のバッファオーバーフローと定義し、CWE-787(Out-of-bounds Write)とCWE-788の子として位置づけています。想定される結果として、メモリの改変によるサービス運用妨害(クラッシュ、終了、再起動)、任意コードやコマンドの実行、メモリ内の機微なデータの読み取りを挙げています。緩和策としては、境界チェックを自動的に行う言語やライブラリの使用、入力サイズの検証、バッファへの書き込み前後の長さ確認を挙げています。

MITREのCWE-787は、境界外書き込みを、製品が意図されたバッファの終端より後、または先頭より前にデータを書き込む欠陥と定義しています。結果として、メモリ破壊によるクラッシュのほか、破壊された領域が後続の処理で使われる場合には任意コードの実行につながりうると述べています。緩和策として、実行防止(NX)やASLRなど環境側の防御が悪用を困難にする一方、根本的な修正ではないと位置づけています。

ネットワーク機器でこの種の欠陥が問題になる理由は、権限の分離が一般的なサーバOSほど細かくないことにあります。汎用のLinuxサーバであれば、外部からの通信を受ける常駐プロセスは専用の低権限ユーザーで動かし、さらにコンテナや名前空間で囲むという設計が普通です。対してネットワークアプライアンスは、パケット処理と管理機能と設定の保持が単一のファームウェア上で密に結び付いており、通信を受け付ける常駐プロセスが機器全体の設定に触れられる位置に置かれることがあります。境界外書き込みで制御を奪われたときに到達できる範囲が広くなるのは、この構造によるものです。

加えて、エッジ機器は復旧が難しい位置にあります。侵害されたのがWebサーバであれば切り離してイメージから作り直せますが、ファイアウォールやVPN終端装置はネットワークそのものの入口で、止めると業務が止まります。攻撃者から見ると、居座り続けやすく、かつ内部への通路を持つ拠点です。

あわせて読みたい

バッファオーバーフローの仕組みと対策。境界を越えた書き込みがコード実行に至る理由

エッジ機器のパッチ適用が遅れる構造#

エッジ機器のファームウェア更新が遅れる理由は、担当者の怠慢ではなく運用の構造にあります。整理すると次のようになります。

• 更新に再起動が伴い、通信の断が発生します。夜間や休日の作業枠を確保する必要があり、申請と承認の手続きで数週間かかります
• HA構成を組んでいても、系列をまたぐアップグレードでは設定の互換性を検証する必要があります。検証環境に同型機がないと本番で試すことになり、心理的な障壁が高くなります
• 機器がネットワークの入口にあるため、失敗したときの影響が全社に及びます。切り戻し手順の準備そのものが作業工数になります
• 保守契約が切れている機器は、そもそも更新ファイルを入手できません
• 第三者から提供された機器や、事業部門が独自に導入した機器は、情報システム部門の台帳に載っていません

この構造を前提にすると、「KEV入りしたので3日で直す」という指示は、準備がなければ実行できません。逆にいえば、KEV入りしてから動き始めるのでは間に合わないということです。あらかじめ、エッジ機器のうちどれが緊急更新の対象になりうるかを決め、作業枠と切り戻し手順を先に用意しておく必要があります。

あわせて読みたい

境界に置くエッジ機器の脆弱性が侵入口として狙われる理由

KEVとEPSSとCVSSを組み合わせた優先度づけ#

このCVEは、優先度づけの指標がどう食い違うかを示す教材になります。執筆時点の値を並べます。

FIRSTのEPSS APIは、2026年9月11日付のCVE-2025-25249のスコアとしてepss 0.024030000、percentile 0.830860000を返します。EPSSのスコアは今後30日以内に悪用が観測される確率の推定値であり、パーセンタイルはスコア付きの全CVEの中での相対位置を示します。

CISAのSSVC(Stakeholder-Specific Vulnerability Categorization)の解説ページは、SSVCが脆弱性の悪用状況(Exploitation)、技術的影響(Technical Impact)、自動化可能性(Automatable)、ミッションと福祉への影響などの判断点をもとに、Track、Track*、Attend、Actの4つの対応区分へ振り分ける決定木であると説明しています。悪用状況のactiveは、信頼できる公開報告により、当該脆弱性を悪用した攻撃が実際に行われていることを指します。

EPSSが約2.4%という低い値にとどまっているのに、KEVには収載されています。この組み合わせが意味することは明快です。EPSSは今後30日以内にデータ提供元のセンサーが悪用活動を検知し記録する確率の推定値であり、過去に悪用があったかどうかを示す値ではありません。KEVは逆に、すでに確認された悪用の記録です。予測と観測という別のものを並べているので、片方が低く片方が収載済みという状態は矛盾しません。SSVCがAutomatable: noと判断している点も、自動化された大量の悪用が観測されている状況ではないことを示すにとどまり、悪用の範囲が狭いと断定できる根拠ではありません。

したがって、優先度づけのルールを「EPSSが一定値以上のものだけ緊急扱いにする」と定めていると、この脆弱性は緊急の枠からこぼれます。KEVは予測ではなく観測の記録なので、EPSSより優先する必要があります。運用としては次の順序が扱いやすくなります。

CISAのBOD 26-04「Prioritizing Security Updates Based on Risk」は2026年6月10日に発行され、連邦民間行政機関(Federal Civilian Executive Branch)の各機関に適用されます(国家安全保障システムなどは除外)。同指令はBOD 19-02とBOD 22-01を置き換えて失効させると明記しています。是正期限は一律ではなく、資産の露出状況、KEVへの収載、悪用の自動化可能性、技術的影響という変数の組み合わせで決まる表に基づきます。あわせて、公開到達可能な資産の識別とタグ付け、CDMフェデラルダッシュボードへの報告、緩和策が利用できない場合の製品使用の中止が求められています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

資産棚卸しと露出面の絞り込み#

KEV入りしてから慌てないための備えは、資産台帳と露出面の管理に集約されます。エッジ機器に限った最小限の項目を挙げます。

台帳に持つべき項目は、機器の型番、ファームウェアの系列と版番号、設置場所と管理主体、保守契約の期限、インターネットから到達可能かどうか、管理系サービスをどのインターフェースで受けているか、設定のバックアップ取得日です。版番号を持っていないと、CVEが出るたびに現地確認から始めることになります。

露出面の絞り込みでは、管理系サービスを外部に出さないことが最初の一歩です。Siemens ProductCERTのアドバイザリが緩和策として挙げているように、インターフェースごとに許可するアクセス種別を見直し、必要のないものを外します。管理アクセスは専用の管理セグメントか、VPN経由に限定します。接続元IPアドレスの制限も併用します。

外部から見た自社の露出は、内部の設定確認だけでは把握しきれません。外部スキャンで、自社の割り当てIPアドレス範囲に開いているポートを定期的に確認します。事業部門が独自に契約した回線や、クラウド上に残った検証用の機器が見つかることがあります。

あわせて読みたい

ネットワークセグメンテーションで侵入後の被害を広げない設計

ログの外部保存も、露出面の話と同じくらい効いてきます。ネットワーク機器のログは機器内の限られた領域にしか残らず、再起動や設定変更で失われることがあります。管理者のログイン履歴と設定変更の記録を外部のsyslogサーバへ転送しておかないと、侵害が疑われたときに何も確かめられません。KEVのエントリにforensicTriageがYesと記録されていても、調べる材料がなければ判定できません。

侵害済みを前提にした確認手順#

KEVに収載された脆弱性は、悪用が確認されています。自社の機器が該当バージョンで、かつ露出していた期間があるなら、パッチを当てる前に確認と保全を行う順序が要ります。

CISAのBOD 26-04実装ガイダンスは、フォレンジックトリアージを6段階で示しています。特徴的なのは、揮発性データの取得(Evidence Collection)がパッチ適用(Critical Patching)より前に置かれている点です。再起動を伴う更新は、メモリ上の痕跡と一部のログを消します。

CISAのBOD 26-04実装ガイダンスは、フォレンジックトリアージの手順を6段階で示しています。Step 1 Scoping(2時間以内)で、当該脆弱性が3日未満の是正期限に該当し、システムやネットワーク基盤が影響を受けたかを判定するためのフォレンジックトリアージを要するかを見極めます。Step 2 Evidence Collection(2時間から24時間)では揮発性データの即時取得を優先し、収集の記録を残します。Step 3 Critical Patching(2時間から24時間)は証拠収集の後にパッチを適用します。Step 4 Containment(6時間から24時間)で影響を受けたシステムを隔離し、Step 5 Analysis(24時間から48時間)で侵害の指標を分析し、Step 6 Escalation Decision(48時間から72時間)でフォレンジック報告書を作成しインシデント対応へ移行するかを判断します。

エッジ機器で確認する対象を整理すると次のようになります。いずれも、正常時の状態を記録しておかないと差分が取れません。

• 管理者アカウントの一覧と、それぞれの作成時期。心当たりのないアカウントや、管理者権限を持つプロファイルが増えていないか
• 管理者プロファイル(権限セット)の定義。既存アカウントの権限が広がっていないか
• ローカル証明書とCA証明書の登録内容。攻撃者が自分の証明書を持ち込んでいないか
• リモートアクセスの設定とユーザー、グループ、認証サーバの定義。VPNのローカルユーザーが追加されていないか
• 有効なVPNセッションと、直近のセッション履歴。想定外の接続元や時間帯がないか
• 自動化の設定(スクリプト実行やイベント連動の仕組み)。設置した覚えのない自動処理がないか
• 静的ルート、ポリシールート、DNSサーバの指定、外部連携の設定。通信の宛先が書き換えられていないか
• ファイアウォールポリシーとアドレスオブジェクト。特定の宛先だけを通す例外が増えていないか
• 管理インターフェースへのログイン履歴。送信元IPアドレスと時刻の分布に説明のつかないものがないか

手順としては、設定全体をエクスポートしてハッシュを取り、直近の正常時のバックアップと差分を比較するのが確実です。差分の量が多くて読めない場合は、上記の項目に絞って抜き出します。

CISAのKnown Exploited Vulnerabilities Catalogは、悪用が確認された脆弱性を収載するカタログです。CISAは同カタログについて、すべての組織に対し、カタログを脆弱性管理の優先度づけの入力として用い、収載された脆弱性の是正を行うことを強く推奨しています。収載の基準は、CVE識別子が採番されていること、悪用が確実に確認されていること、明確な是正策が存在することの3点です。

あわせて読みたい

アラート待ちから抜け出す脅威ハンティングの始め方

異常が見つかった場合は、設定を修正して終わりにせず、インシデントとして扱います。エッジ機器が侵害されていた場合、その機器を通過した認証情報や内部への横展開の可能性まで調査範囲に入ります。機器の設定を初期化して再構築し、その機器に保存されていた認証情報(管理者パスワード、VPNの共有鍵、証明書の秘密鍵、連携先サービスのAPIキー)をすべて更新する判断が必要になることがあります。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

日本の組織が参照できる情報と、その限界#

このCVEについて、日本語の一次情報は執筆時点では見つかりませんでした。IPAが運用するJVN iPediaのMyJVN APIでCVE-2025-25249を検索しても、該当する脆弱性対策情報は返りません(2026年9月12日に確認)。JPCERT/CCの2026年の注意喚起にも、このCVEを単独で扱ったものは確認できていません。

日本語の解説が出るのを待つと、KEVの是正期限をはるかに過ぎます。エッジ機器を運用する組織は、CISAのKEVカタログとNVD、ベンダーのPSIRTを直接見る運用を組む必要があります。KEVカタログはJSONで配布されているため、資産台帳との突き合わせを自動化できます。日次で取得し、自社のベンダー名と製品名に一致する新規エントリが出たら通知する、という程度の仕組みでも効果があります。

なお、BOD 26-04は米国の連邦民間行政機関に対する拘束力を持つ指令であり、日本の民間企業に法的な義務を課すものではありません。ただし、悪用が確認された脆弱性への対応期限を資産の露出状況で決めるという考え方は、そのまま自社の基準に写せます。

あわせて読みたい

FortiOS SSL-VPNのシンボリックリンク永続化パッチをすり抜けるCVE-2025-68686

まとめ#

CVE-2025-25249は、2025年2月に識別子が予約され、2026年1月にCVEとして公開され、2026年9月9日にKEVカタログへ追加されたFortinet製品のヒープバッファオーバーフローです。CVEの採番年と実際の危険度は連動しません。台帳の整理を採番年で行っている組織ほど、この種の脆弱性を取りこぼします。

対応の順序を整理します。

EPSSが2.4%という数字だけを見て後回しにしていたら、この脆弱性は緊急対応の枠に入りませんでした。予測の指標と観測の記録は用途が違います。予測は限られた時間をどう配分するかの材料であり、観測は配分を考える前に着手する理由です。KEVカタログの意味はそこにあります。