CVE-2026-26035｜FortiWeb 認証バイパスの影響条件と対処

はじめに

2026 年 8 月 12 日、Fortinet が FortiWeb の認証に関する脆弱性 CVE-2026-26035（Advisory ID: FG-IR-26-158）を公開しました。条件が成立すると、リモートかつ未認証の攻撃者がランダムなユーザー名とパスワードで FortiWeb の GUI / CLI にログインできる可能性がある、という内容です。

影響を受けるバージョンの範囲は 8.0 系から 7.0 系まで広く、対象バージョン表だけを見ると「自社の FortiWeb もすぐに危険な状態にある」と読めてしまいます。しかし Advisory は、この脆弱性が FortiWeb の Remote RADIUS Type Admin Authentication が特定の非デフォルト設定で構成されている場合に影響すると説明しています。つまり、バージョンが該当することは必要条件にすぎず、それだけでは自環境が対象かどうかを判断できません。

結論を先に述べます。影響判定で最初に確認したいのは、FortiWeb の管理者アカウントにリモート認証（RADIUS）を使っており、かつ Wildcard 設定を有効にしているかどうかです。Fortinet が提示している回避策がこの Wildcard の無効化であることから、ここが影響判定の中心的な確認点になります。加えて、8.0 / 7.6 / 7.4 系はすでに修正版が提供されている一方、7.2 系と 7.0 系は本記事執筆時点で修正版の公開が確認できません。該当ブランチを運用している場合は、更新ではなく設定側の対処を先に検討することになります。

CVE-2026-26035 の概要と評価情報の読み方

まず、脆弱性そのものの内容と、公表されている評価値の読み方を整理します。CVSS スコアが情報源によって異なって見えるため、どちらが誤りというわけではないことを先に押さえておくと、社内での説明がしやすくなります。

何が起きる脆弱性か

CVE レコードでは、不適切な認証（CWE-287）に分類されています。影響としては、リモートの未認証攻撃者が FortiWeb の GUI または CLI に、任意のユーザー名とパスワードでログインできる可能性がある、と記載されています。

参考: CVE Record – CVE-2026-26035
“may allow a remote unauthenticated attacker to login into the Fortiweb GUI/CLI”
（リモートの未認証攻撃者が FortiWeb の GUI / CLI にログインできる可能性があります）
https://www.cve.org/CVERecord?id=CVE-2026-26035

ここで注意したい点があります。CVE レコードの説明文には RADIUS という語が含まれていません。 RADIUS 管理者認証という条件が示されているのは Fortinet の Advisory 側です。自環境の判断には、CVE レコードの説明文だけでなく Advisory 側の記述もあわせて参照することをおすすめします。

なお本記事では、認証バイパスを再現する手順や PoC は扱いません。運用担当者が判断と対処に必要な情報に絞ります。

CVSS 8.8 と 9.8 の差はどこから生じるか

Fortinet および CVE の CNA レコードでは、CVSS v3.1 で 8.8 / High と評価されています。一方、一部の脆弱性データベースやニュース記事では 9.8 / Critical と表示されています。

CNA レコードに記載されているベクター文字列は次のとおりです。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C

このベクターには、Base 指標（AV から A まで）に加えて、Temporal 指標（E:P / RL:O / RC:C）が含まれています。CVSS v3.1 の計算式に従って Base 指標のみを計算すると 9.8 となり、そこに Temporal 指標を反映すると 8.8 になります。9.8 は Base スコア、8.8 は Temporal を含めたスコアという関係で、値の内訳としては整合します。

ただし、Fortinet が 8.8 を掲示している理由そのものは公表されていません。上記はベクター文字列と CVSS v3.1 仕様から確認できる範囲の説明であり、それ以上の推測はしていません。社内報告では「情報源によって Base か Temporal かの違いで表示が異なる」という事実として扱うのが安全です。CVSS v3.1 における Base と Temporal の関係は、FIRST の仕様書（https://www.first.org/cvss/v3.1/specification-document ）で確認できます。

対応優先度を判断するための材料

対応の緊急度を決めるうえで、現時点で確認できる情報は次のとおりです（いずれも 2026 年 8 月 13 日時点）

CISA KEV

CVE-2026-26035 は登録されていません。

SSVC（CISA-ADP）

Exploitation は none、Automatable は yes、Technical Impact は total と評価されています。

Advisory の Acknowledgement

Fortinet の内部監査で発見されたと記載されています。外部研究者の関与や公開 PoC への言及はありません。

Advisory の Timeline

2026 年 8 月 12 日の初版のみで、更新はありません。

優先度は、これらの情報だけで決まるものではありません。構成条件に該当する機器があるか、その GUI / CLI が信頼できないネットワークから到達可能か、修正版が提供されているブランチかを組み合わせて判断する必要があります。SSVC の Technical Impact が total である点は、条件に該当した場合の影響が管理権限の掌握に直結することを示しています。条件に該当し、かつ管理面が広く到達可能な機器が見つかった場合は、悪用が確認されていない段階であっても早期の対処を検討する価値があります。

KEV の登録状況を踏まえた優先度の考え方や、SSVC・BOD 26-04 との関係については、関連記事『BOD 26-04 が示す脆弱性対応の優先度判断』で整理しています。

なお、KEV の登録状況と Advisory の更新は今後変わる可能性があります。対応を判断する際は、本記事の値ではなく Fortinet PSIRT と CISA KEV の最新表示を確認することをおすすめします。

影響を受けるのはどの構成か

このセクションでは、対象バージョンの確認から構成条件の確認までを順に整理します。結論として、バージョンが該当するだけでは影響の有無は決まらず、FortiWeb の管理者認証に RADIUS を使っているか、その管理者アカウントで Wildcard が有効かまで確認する必要があります。

Advisory の Summary は、影響条件を次のように説明しています。

参考: Fortinet PSIRT FG-IR-26-158 – Broken access control in the RADIUS type admin group
“configured with specific, non-default settings may allow a remote unauthenticated attacker to login”
（特定の非デフォルト設定で構成されている場合、リモートの未認証攻撃者がログインできる可能性があります）
https://fortiguard.fortinet.com/psirt/FG-IR-26-158

対象バージョンと修正版の対応

Advisory と CVE レコードに記載されている対象範囲、および本記事執筆時点（2026 年 8 月 13 日）で Fortinet Document Library に公開が確認できる最新版は次のとおりです。

この表には、情報源による差異が 1 点あります。Advisory の Affected / Solution 表には FortiWeb 7.0 の行が存在しません。 一方、Fortinet が CNA として登録している CVE レコードには 7.0.0 〜 7.0.12 が影響範囲として記載され、Solution にも 7.0.13 以降への更新が挙げられています。どちらも Fortinet 発の一次情報であり、どちらかが誤りと断定できる材料は現時点でありません。7.0 系を運用している場合は、対象である前提で確認を進めるのが安全側の判断になります。

また「公開が確認できる最新版」は Document Library の掲載状況に基づく値です。実際のファームウェア入手可否は Fortinet のサポートサイトで確認することをおすすめします。Advisory や修正版の一次情報をたどる手順は、関連記事『Fortinet 公式情報の探し方』にまとめています。

7.2 系と 7.0 系は修正版の公開が確認できません

上の表のとおり、8.0 / 7.6 / 7.4 の各系統では修正版がすでに提供されており、いずれも修正版よりさらに新しいバージョンが公開されています。一方、7.2 系は 7.2.12、7.0 系は 7.0.12 が最新であり、Advisory と CVE レコードが指す 7.2.13 / 7.0.13 の公開は確認できません。 CVE レコードの Solution 欄でも、この 2 つのバージョンには「upcoming」と付記されています。

つまり、7.2 系と 7.0 系を運用している場合、同一ブランチ内の更新による対処は現時点では選択できません。取り得る選択肢は、Advisory が提示する Workaround の適用、上位ブランチへのアップグレード、またはその両方の組み合わせになります。具体的な手順は後半のセクションで扱います。

条件は Remote type 管理者アカウントの Wildcard 設定

Advisory の Summary は「Remote RADIUS Type Admin Authentication が特定の非デフォルト設定で構成されている場合」とだけ述べており、その非デフォルト設定が何かを Summary 内では明示していません。

手がかりになるのは Workaround の記述です。Fortinet は回避策として、Remote type の管理者アカウントで有効になっている Wildcard 設定を無効化するよう案内しています。あわせて「有効になっている場合（非デフォルト）」という注記が置かれており、Wildcard の既定値が無効であることも示されています。

ここから、Wildcard を有効にした Remote type の管理者アカウントが存在することが、影響条件に含まれると読み取れます。ただし Advisory は Wildcard が唯一の条件であるとは述べていません。本記事では、Wildcard を「影響判定で最初に確認したい設定」として扱い、これ以外の条件が存在しないと断定はしません。Wildcard が無効であっても、修正版が利用できるブランチでは更新を計画することをおすすめします。

FortiWeb における Wildcard は、ローカルに個別の管理者アカウントを定義せず、リモート認証サーバー側のユーザーをまとめて 1 つの管理者アカウントに一致させるための設定です。管理者を RADIUS 側で一元管理したい環境で使われます。非デフォルトだから対象外と即断せず、実際の設定を確認することをおすすめします。

RADIUS をエンドユーザー認証に使っているだけの場合

FortiWeb の RADIUS サーバー定義（user radius-user）は、公開しているアプリケーションのエンドユーザー認証と、FortiWeb 管理者の認証の両方で利用できる構成になっています。CLI Reference にも、エンドユーザーと管理者のどちらの認証にも使えるクエリとして説明されています。

一方で、管理者認証に使う場合は、管理者アカウントが RADIUS サーバー定義を直接参照するのではなく、管理者用の Admin Group（クエリセット）を経由する必要があります。この構成上の要件は Administration Guide に明記されています（詳細は次のセクションで引用します）。

このため、「RADIUS サーバーを登録している」という事実だけでは条件に該当するかどうかは判断できません。管理者認証で使われているかどうかは、次の連鎖をたどって確認します。

1. config system admin の管理者アカウントで type が remote-user になっているか
2. そのアカウントの admin-usergroup が、どの Admin Group（user admin-usergrp）を参照しているか
3. その Admin Group の User Type が RADIUS User になっているか
4. 当該管理者アカウントで wildcard が有効になっているか

RADIUS サーバー定義が認証ポリシー側でのみ参照されており、管理者アカウントからは参照されていない場合、この連鎖は 2 の時点で途切れます。

影響判定フローチャート

ここまでの内容を、運用担当者が上から順に Yes / No で答えられる形に整理したものが次の図です。

この図の使い方について、3 点補足します。

1 つ目に、B から E までは影響判定で確認する項目であり、Advisory が示す成立条件のすべてではありません。 Advisory は非デフォルト設定の内容を網羅的には示していないため、これらを満たさないことをもって安全と確定することはできません。

2 つ目に、F は攻撃面への到達可能性であり、B から E までとは性質が異なります。 F が「いいえ」であっても脆弱な設定であることに変わりはなく、内部からの攻撃や踏み台経由のアクセスまで排除できるわけではありません。到達性の制限は優先度を下げる材料になりますが、対処を不要にするものではありません。

3 つ目に、G と H の表現は本記事で整理した行動の目安であり、Fortinet や CISA が定義した優先度区分ではありません。 実際の優先度は、機器の役割や社内の運用基準とあわせて判断してください。判断に迷う構成がある場合は、FortiCare サポートに構成情報を添えて確認するのが確実です。

自環境の設定を確認する手順

前のセクションの判定フローを、実際のコマンドと画面操作に落とし込みます。確認したいのは「管理者アカウントがリモート認証を使っているか」「その参照先が RADIUS か」「Wildcard が有効か」の 3 点です。

参考: FortiWeb Administration Guide – Grouping remote authentication queries and certificates for administrators
“you must group queries or certificates for administrator accounts into a single set”
（管理者アカウント用のクエリまたは証明書を 1 つのセットにまとめる必要があります）
https://docs.fortinet.com/document/fortiweb/8.0.3/administration-guide/410257/grouping-remote-authentication-queries-and-certificates-for-administrators

つまり、RADIUS サーバー定義が存在していても、それが Admin Group に組み込まれ、さらに管理者アカウントから参照されていなければ、管理者認証の経路にはなりません。RADIUS サーバーを登録していること自体は、今回の条件に該当する根拠にはならないという点を、確認の出発点として押さえておきます。

なお、管理者用とエンドユーザー用で RADIUS クエリのオブジェクトを分けるべき、という明示的な推奨文は、本記事の調査範囲では公式ドキュメント上に見つけられませんでした。確認できたのは上記のとおり、管理者認証には専用の Admin Group が必要という構成上の要件です。運用設計としてクエリを分離しているかどうかは環境によって異なるため、実際の参照関係をたどって確認することをおすすめします。

CLI で確認する

CLI では、管理者アカウントの定義を表示して type、admin-usergroup、wildcard の 3 つを確認します。

show system admin

出力に含まれる各設定の意味は次のとおりです。いずれも FortiWeb CLI Reference の system admin に定義されています。

type が local-user のアカウントや、admin-usergroup の指定がないアカウントは、リモート認証の経路には含まれません。

次に、参照されている Admin Group の中身を確認します。

show user admin-usergrp

ここで User Type として RADIUS User が選択されているかどうかを見ます。LDAP User、TACACS+、PKI User のみで構成されている場合、今回の Advisory が示す RADIUS 管理者認証には該当しません。

参照先の RADIUS サーバー定義そのものを確認する場合は、次のコマンドを使用します。

show user radius-user

show の出力に set wildcard enable の行がないことだけをもって、Wildcard が無効と結論づけるのは避けてください。 Wildcard の既定値は無効ですが、show の出力に既定値のままの設定が含まれるかどうかは表示仕様に依存します。確実に判断するには、次項の GUI 画面で Wildcard の状態を直接確認することをおすすめします。

ADOM を有効にしている環境では、CLI の操作コンテキストが変わる場合があります。管理者アカウントそのものは config system admin で定義され、set domains で割り当て先の ADOM を限定する構成です。ADOM 有効時の CLI の扱いは、CLI Reference の ADOMs の項（https://docs.fortinet.com/document/fortiweb/8.0.2/cli-reference/585332/adoms ）を参照してください。

参照: FortiWeb CLI Reference – system admin
https://docs.fortinet.com/document/fortiweb/8.0.2/cli-reference/810797/system-admin

GUI で確認する

GUI では、次の 2 か所を順に確認します。

メニューの表記には情報源による差があります。FortiWeb 8.0 系の Administration Guide では System > Admin > Administrators と記載されている一方、Advisory の Workaround では System > Administrators と表記されています。手元の環境で見当たらない場合は、該当バージョンの Administration Guide の Administrators の項を参照してください。

確認結果の分類

確認した内容は、次の 3 つに分類しておくと、その後の対応判断と社内報告がしやすくなります。

対象

対象バージョンで、RADIUS を参照する Admin Group を持つ管理者アカウントがあり、その Wildcard が有効

非対象の可能性が高い

対象バージョンだが、リモート認証の管理者アカウントがない、参照先が RADIUS ではない、または Wildcard が無効

追加確認が必要

管理者アカウントや Admin Group の参照関係が複雑で、経路をたどりきれない。ADOM を有効にしている環境や、設定変更の履歴が追えない機器が該当しやすい

「非対象の可能性が高い」に分類した場合も、Advisory が非デフォルト設定の内容を網羅的に列挙していない以上、対象外と確定したわけではありません。修正版が提供されているブランチでは、分類にかかわらず更新を計画することをおすすめします。

対象だった場合の対応

対応の選択肢は、修正版への更新と、Fortinet が提示する Workaround の適用の 2 つです。どちらを先に実施するかは、運用しているブランチによって変わります。

修正版が提供されているブランチ

8.0 / 7.6 / 7.4 の各系統では、それぞれ 8.0.3 / 7.6.7 / 7.4.12 以降で修正されています。適用先のバージョンは、リリースノートでアップグレードパスと機能の互換性、ハードウェアや VM のサポート状況を確認したうえで、修正版以降から環境に適したものを選ぶ形になります。

更新前には、以下を確認しておくと復旧の選択肢が残ります。

• 設定のバックアップ取得
• 現在のバージョンとビルド番号の記録（get system status）
• 該当期間の管理者ログイン関連ログのエクスポート

CLI から設定をバックアップする場合、TFTP サーバーへ保存する構文は次のとおりです。

execute backup full-config tftp <filename_str> <tftp_ipv4> [<password_str>]

backup config が設定ファイルのみを対象とするのに対し、backup full-config はエラーページや証明書ファイルを含む構成一式を対象とします。機械学習のデータもあわせて保持したい場合は、別途 execute backup full-config-with-ML-data が用意されています。取得先は TFTP のほか FTP や USB なども選択できるため、利用可能な転送方式は CLI Reference の該当項目で確認してください。GUI から取得する場合は、Administration Guide の Backup & restore の項に手順がまとめられています。

FortiWeb はアプライアンス、VM、コンテナと提供形態が複数あり、更新の実施方法や事前準備が異なります。提供形態ごとの違いは、関連記事『FortiWeb とは｜提供形態と機械学習による防御の仕組み』で整理しています。

7.2 系・7.0 系の場合

前のセクションのとおり、7.2.13 と 7.0.13 は本記事執筆時点で公開が確認できません。この 2 つのブランチでは、まず Workaround を適用し、修正版の公開を待つという順序が現実的です。

上位ブランチへの移行も選択肢にはなりますが、これは緊急対処として即座に実行できる作業ではありません。FortiWeb にはブランチをまたぐ際の推奨アップグレードパスが定められており、途中バージョンを経由する必要がある場合があります。

参考: FortiWeb 8.0.3 Release Notes – Upgrading from previous releases
“you will need to upgrade to version 7.6.2 before proceeding with subsequent updates”
（後続の更新に進む前に、バージョン 7.6.2 へアップグレードする必要があります）
https://docs.fortinet.com/document/fortiweb/8.0.3/release-notes/81434/upgrading-from-previous-releases

上位ブランチへ移行する場合は、対象バージョンのリリースノートで推奨アップグレードパス、機能の非互換、ハードウェアや VM のサポート状況、ライセンスの適用範囲を確認したうえで計画することをおすすめします。Fortinet が提供する Upgrade Path Tool も判断材料になります。

公式 Workaround: Wildcard の無効化

Advisory は回避策として、Wildcard が有効になっている Remote type の管理者アカウントで、この設定を無効化する方法を示しています。

GUI の場合は、Administrators の画面で該当する Remote Type の管理者アカウントを編集し、Wildcard オプションを無効にします。

CLI の場合は次のとおりです。

config system admin
    edit <Remote type administrator account>
        set wildcard disable
    next
end

参照: Fortinet PSIRT FG-IR-26-158（Workaround の項）
https://fortiguard.fortinet.com/psirt/FG-IR-26-158

Wildcard 無効化に伴う運用上の影響

Wildcard は、リモート認証サーバー側のユーザーをまとめて 1 つの管理者アカウントに一致させるための設定です。無効化すると、この一括の一致が働かなくなります。

Administration Guide には、Admin Group の Group Name によるユーザーの照合を行う場合に Wildcard を有効にしておく必要がある、という趣旨の記載があります。Group Name によるグループ照合で管理者を運用している環境では、Wildcard を無効化した時点で、これまで一括の一致でログインしていた管理者はログインできなくなります。 これは回避策の副作用ではなく、想定される動作です。無効化する場合は、必要な管理者について個別の管理者アカウントを用意するなど、管理経路を作り直す前提で計画することをおすすめします。

適用前には、次の点を確認しておくことをおすすめします。

• ローカル（type local-user）の管理者アカウントで、パスワードが判明しているものが少なくとも 1 つ存在するか
• 現在 Wildcard 経由でログインしている管理者が誰か、変更後にどの経路で管理するか
• コンソール接続など、GUI / CLI 以外の復旧経路を確保できているか

管理インターフェースの到達性はリスク低減策として扱う

FortiWeb には、管理者アカウント単位で接続元を制限する trusthosts / ip6trusthosts や、管理アクセス用のファイアウォールポリシー（system firewall admin-policy）といった機能があります。GUI / CLI が信頼できないネットワークから到達可能な状態であれば、これらによる制限は攻撃面の縮小につながります。

ただし、Advisory の Workaround に記載されているのは Wildcard の無効化のみです。 管理インターフェースのアクセス制限は Fortinet が今回の脆弱性に対して提示した回避策ではないため、公式 Workaround とは区別し、リスク低減策として位置づけます。到達性を制限しただけでは脆弱な設定は残るため、更新または Wildcard 無効化とあわせて実施することをおすすめします。

更新後と管理アクセスの確認

更新または Workaround を適用したあと、意図した状態になっているかを確認します。あわせて、対処前の期間に管理アクセスの異常がなかったかを、実際に参照できるログの範囲で見ておきます。

前提として、Fortinet は CVE-2026-26035 に関する侵害指標（IoC）や、この脆弱性の悪用を特定するための検知条件を公開していません。 Advisory の Timeline も初版のみで、悪用の観測に関する記載はありません。したがって、このセクションで挙げるのは「この脆弱性で侵害されたかどうかを判定する手順」ではなく、管理アクセスの異常に気づくための一般的な観点です。ログの内容だけで侵害の有無を確定することはできない点を前提に読み進めてください。

更新後に確認する項目

更新後は、次の 4 点を順に確認します。

get system status

show system admin

HA 構成での確認

FortiWeb の HA クラスターは、ハートビートリンクを介して設定の大部分を自動的に同期します。同期の対象には、CLI 形式のコア設定ファイル（FortiWeb_system.conf）や証明書などが含まれます。一方で、同期されない設定とデータは Administration Guide に一覧として示されています。管理者アカウントの設定が同期対象に含まれるかどうかは、本記事では公式資料上で明示的な記載を確認できていないため、適用後に同期状態と両系の設定を実際に確認するという進め方をおすすめします。

参照: FortiWeb Administration Guide – Synchronization
https://docs.fortinet.com/document/fortiweb/7.6.0/administration-guide/435480/synchronization

ファームウェア更新の手順そのものは、対象バージョンのリリースノートに Upgrading an HA cluster の項として記載されています。更新前にこの項を確認し、ノードの更新順序や、更新中のフェイルオーバーに関する注意点を把握しておくことをおすすめします。

Workaround の適用や更新のあとは、次のコマンドでクラスターの状態と同期状況を確認できます。

参照: FortiWeb CLI Reference – diagnose
https://docs.fortinet.com/document/fortiweb/8.0.2/cli-reference/415500/diagnose

Administration Guide によると、同期が想定どおり行われていない場合はプライマリー機の Web UI 右上に「Not sync」のアイコンが表示され、プライマリーとセカンダリーの設定差分を比較する HA Diff ツールも用意されています。設定変更後は、同期の完了を確認したうえで、両系で show system admin の出力が一致していることを見ておくと確実です。

管理アクセスの異常に気づくための観点

ここで挙げるのは、今回の CVE に固有の検知条件ではなく、管理アクセスの異常を確認するための一般的な観点です。FortiWeb のイベントログには、管理者のログイン・ログアウトや設定操作が記録されます。

参考: FortiWeb Administration Guide – How to check event logs in FortiWeb
“Event logs display administrative events such as admin login/logout, system bootup and version upgrade”
（イベントログには、管理者のログインとログアウト、システム起動、バージョン更新といった管理系の事象が記録されます）
https://docs.fortinet.com/document/fortiweb/7.0.0/administration-guide/985375/how-to-check-event-logs-in-fortiweb

GUI では Log&Report > Log Access > Event から参照できます。確認する観点としては、次のようなものが挙げられます。いずれも、今回の脆弱性の悪用に限らず、管理アクセスの棚卸しとして有効なものです。

見覚えのないユーザー名でのログイン成功

運用している管理者名簿にないユーザー名でのログイン成功は、原因を問わず確認する価値があります。

想定外の接続元 IP アドレスからのログイン

運用端末や踏み台サーバー以外からのログインが記録されていないかを確認します。

業務時間外や休日のログイン

通常の運用パターンから外れた時間帯のアクセスを洗い出します。

管理者アカウントやアクセスプロファイルの追加・変更

意図しない管理者の追加は、永続化の手口として知られています。設定操作のログとあわせて確認します。

設定のバックアップ取得やファームウェア関連の操作

実施した覚えのない操作が記録されていないかを見ます。

確認にあたって、いくつか制約があります。ローカルディスクに保存されるログは保存期間や容量の上限があり、遡れる範囲は環境によって異なります。 Syslog サーバーや FortiAnalyzer へ転送している場合は、そちらの方が長期間の確認に向きます。また、ログの時刻が正しくない環境では時系列の判断ができないため、NTP による時刻同期の状態もあわせて確認しておくことをおすすめします。

これらの観点で気になる記録が見つかった場合でも、それが今回の脆弱性によるものかを機器上のログだけで特定することはできません。判断に迷う記録がある場合は、機器上で追加の調査を進める前に、ログの保全と Fortinet サポートまたはインシデント対応の窓口への相談を検討することをおすすめします。

まとめ

CVE-2026-26035 は、FortiWeb の管理者認証に関する脆弱性です。影響を受けるバージョンの範囲は広いものの、Fortinet は特定の非デフォルト設定で構成されている場合に影響すると説明しており、バージョンの該当だけで対象と判断することはできません。運用担当者としては、自環境の管理者認証設定を確認したうえで、更新と回避策のどちらを先に選ぶかを決めることになります。

• FortiWeb の管理者認証に関する認証バイパスの脆弱性
• 影響判定で最初に確認したい RADIUS 管理者アカウントの Wildcard 設定
• 対象バージョンへの該当だけでは影響の有無を判断できない。
• 8.0 / 7.6 / 7.4 系では修正版が提供済み
• 7.2 系は修正版の公開が確認できず、公式の回避策が現実的な選択肢
• 7.0 系は Advisory と CVE レコードで記載が異なる。
• 管理インターフェースの到達性は公式の回避策と区別したリスク低減策

以上、最後までお読みいただきありがとうございました。