FortiOS の LDAP 認証バイパス｜CVE-2026-22153 の影響と対処の手順

はじめに

FortiOS が LDAP サーバー（Active Directory 等）と連携してユーザー認証を行う構成は、多くの現場で採用されています。2026 年 2 月、この LDAP 認証をすり抜ける脆弱性 CVE-2026-22153（FG-IR-25-1052）が Fortinet から公表されました。認証情報を持たない攻撃者が、特定の LDAP サーバー設定下で Agentless VPN や FSSO ポリシーの認証をバイパスできるというものです。

この脆弱性の特徴は、原因が FortiOS 側のバグと LDAP サーバー側の設定の組み合わせで成立する点にあります。そのため、FortiOS のアップグレードだけでなく、LDAP／AD 側の設定を見直すことで、より確実な緩和につながります。

本脆弱性の影響を受けるのは FortiOS 7.6.0 から 7.6.4 で、7.6.5 以降へのアップグレードが恒久対応となります。成立条件は LDAP サーバー側で unauthenticated bind（ユーザー名あり・パスワード空のバインド）が許可されていることであり、AD 側で unauthenticated bind を無効化することでも成立条件そのものを取り除けます。以降では、脆弱性の概要から根本原因、確認方法、対処手順までを順に扱います。

CVE-2026-22153 の概要

CVE-2026-22153 は、FortiOS の認証デーモン fnbamd に存在する認証バイパスの脆弱性です。脆弱性タイプは CWE-305（Authentication Bypass by Primary Weakness、主要な弱点による認証バイパス）に分類されます。認証情報を持たない攻撃者が、特定の LDAP サーバー設定下で Agentless VPN または FSSO ポリシーの LDAP 認証をバイパスできる可能性があります。

主な諸元は次のとおりです。

CVSSv3 のベクトルは AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H で、NVD および GitHub Advisory ではベーススコア 8.1 とされています。一方、FortiGuard PSIRT が公表している CVSSv3 スコアは 7.5 です。この差は、公式修正が提供済みであることなどを反映した Temporal スコアによるものです。

攻撃複雑度が High（AC:H）とされているのは、悪用の成立に「LDAP サーバー側で unauthenticated bind が許可されている」という特定の設定条件が必要になるためです。裏を返せば、この条件を満たす環境では認証情報なしでバイパスが成立し得ます。この条件の詳細は、後述の「根本原因」で扱います。

本脆弱性は Actemium Cyber Security Team の Jort Geurts 氏による責任ある開示（responsible disclosure）を通じて報告されたもので、公表時点で悪用は確認されていません（Known Exploited: No）。ただし公表済みの脆弱性であるため、対象バージョンを利用している場合は早めの対応が推奨されます。

参考: FortiGuard PSIRT「FG-IR-25-1052」
“an unauthenticated attacker to bypass LDAP authentication of Agentless VPN or FSSO policy”
（認証情報を持たない攻撃者が Agentless VPN や FSSO ポリシーの LDAP 認証をバイパスする）
https://www.fortiguard.com/psirt/FG-IR-25-1052

影響を受けるバージョンと成立条件

本脆弱性の影響を受けるのは FortiOS 7.6 系の一部に限られます。まず対象バージョンを確認し、続いて悪用が成立する条件を整理します。

対象バージョン一覧

FortiGuard PSIRT が公表している影響範囲は次のとおりです。影響を受けるのは FortiOS 7.6.0 から 7.6.4 のみで、その他のブランチは影響を受けません。

自環境が 7.6.0 から 7.6.4 に該当する場合、恒久対応は 7.6.5 以降へのアップグレードとなります。アップグレードの計画にあたっては、対応バージョンの確認と HA 構成での検証を含めた進め方を、関連記事『FortiGate アップグレードパスの確認手順』で扱っています。

参考: FortiGuard PSIRT「FG-IR-25-1052」
“7.6.0 through 7.6.4 […] Upgrade to 7.6.5 or above”
（7.6.0 から 7.6.4 が対象。7.6.5 以降へアップグレードする）
https://www.fortiguard.com/psirt/FG-IR-25-1052

「特定の LDAP サーバー設定」とは何か

Advisory では、悪用が成立する条件として「特定の LDAP サーバー設定（under specific LDAP server configuration）」という表現が使われています。この条件が、CVSS の攻撃複雑度を High（AC:H）に押し上げている要素です。

具体的には、LDAP サーバー側で unauthenticated bind（ユーザー名あり・パスワード空のバインド）が許可されている状態が成立条件にあたります。Advisory の回避策が「LDAP サーバーの unauthenticated bind を無効化する」ことである点からも、この設定が引き金になっていると読み取れます。この unauthenticated bind が何を指すのか、次のセクションで詳しく扱います。

根本原因: LDAP の unauthenticated bind

このセクションが本記事の中心です。認証バイパスの背景には、LDAP の simple bind に含まれる unauthenticated bind という、あまり知られていない仕様上の挙動があります。まず似た用語である anonymous bind との違いを整理し、続いてなぜ認証バイパスにつながるのかを説明します。

anonymous bind と unauthenticated bind の違い

LDAP の simple bind（パスワードによる認証）には、RFC 4513 で 3 つのメカニズムが定義されています。混同されやすいのが anonymous bind と unauthenticated bind の 2 つです。両者はどちらも結果的に匿名の認可状態（anonymous authorization state）になりますが、リクエストの中身が異なります。

anonymous bind はユーザー名もパスワードも空であるのに対し、unauthenticated bind はユーザー名（DN）を伴いながらパスワードだけが空という点が決定的な違いです。RFC 4513 では、unauthenticated bind で渡される DN は認証やアクセス制御の判断には使わず、ログ等のトレース目的にのみ用いるべきものと規定されています。つまり、名前があっても認証されているわけではありません。

なぜ認証バイパスにつながるのか

問題は、パスワードが空でも LDAP サーバーが「成功」を返し得るという点にあります。RFC 4513 の 6.3.1 節は、この挙動を明確に指摘しています。

参考: RFC 4513 6.3.1 節「Unauthenticated Mechanism Security Considerations」
“LDAP server implementations may return a success response to an unauthenticated Bind request.”
（LDAP サーバー実装は、unauthenticated bind リクエストに対して成功応答を返すことがある）
https://www.rfc-editor.org/rfc/rfc4513.html

RFC は続けて、この成功応答をクライアントが「認証成功」と誤解する危険を挙げています。ユーザーが Name/Password 認証のつもりで誤って空パスワードを送ると、実装の甘いクライアントは unauthenticated bind として扱われ、サーバーの成功応答をそのまま認証成功とみなしてしまう、という流れです。

CVE-2026-22153 はこの構図に該当します。認証情報を持たない攻撃者が、有効なユーザー名（DN）と空のパスワードを用いて認証を試みたとき、LDAP サーバー側で unauthenticated bind が許可されていると、サーバーは成功応答を返します。この応答を FortiOS の fnbamd が認証成功として扱うことで、Agentless VPN や FSSO ポリシーの LDAP 認証がバイパスされる、と整理できます。FortiOS 側の修正（7.6.5 以降）と LDAP サーバー側の設定（unauthenticated bind の無効化）は、この「空パスワードで成功が返る」経路を、それぞれ別の層で塞ぐ対策にあたります。

なお、Fortinet は fnbamd の内部挙動の詳細までは公開していません。ここでの説明は、Advisory の回避策と RFC 4513 の仕様に基づく整理であり、unauthenticated bind に起因する認証バイパスという既知のクラスに位置づけられるものです。

自環境が影響を受けるかの確認

対処に入る前に、自環境が本脆弱性の条件に該当するかを 2 つの観点で確認します。1 つは FortiOS のバージョン、もう 1 つは LDAP サーバー（Active Directory）側の unauthenticated bind の設定状態です。両方が揃ったときに悪用が成立し得るため、どちらか一方でも条件から外せば緩和につながります。

FortiOS のバージョン確認

稼働中の FortiOS のバージョンは、CLI の get system status で確認できます。出力の Version 行にブランチとビルドが表示されます。

get system status

Version が 7.6.0 から 7.6.4 のいずれかであれば影響を受けるため、対処の対象となります。7.6.5 以降、または 7.4／7.2／6.4／8.0 系であれば、本脆弱性の影響は受けません。

Active Directory 側の unauthenticated bind の状態確認

LDAP サーバーが Active Directory の場合、unauthenticated bind を拒否する設定 DenyUnauthenticatedBind は、ディレクトリサービスオブジェクトの msDS-Other-Settings 属性に格納されます。この属性は明示的に指定しない限り既定値が 0（拒否しない）であり、Windows Server 2019 以降でも unauthenticated bind は既定で許可されています。現在の状態は、次の PowerShell で確認できます。

$configDN = (Get-ADRootDSE).configurationNamingContext
$dirSvcDN = "CN=Directory Service,CN=Windows NT,CN=Services,$configDN"
Get-ADObject -Identity $dirSvcDN -Properties 'msDS-Other-Settings' |
    Select-Object -ExpandProperty 'msDS-Other-Settings'

出力に DenyUnauthenticatedBind=1 が含まれていれば、unauthenticated bind は拒否される設定になっています。含まれていない場合は既定値の 0 が適用され、unauthenticated bind が許可されている状態です。

参考: Microsoft Learn「[MS-ADTS]: LDAP Configurable Settings」
“AD LDS will reject […] an LDAP simple bind request that specifies a zero-length password”
（AD LDS は、長さ 0 のパスワードを指定した LDAP simple bind リクエストを拒否する）
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/41cbdb2c-eab1-45b0-8236-ae777b1c5406

対処: 恒久対応と AD 側の緩和

対処は、FortiOS 側の恒久対応と LDAP サーバー側の緩和という 2 つの層で考えると整理しやすくなります。加えて、すぐにアップグレードできない場合の暫定緩和として仮想パッチの選択肢があります。

恒久対応: FortiOS 7.6.5 以降へのアップグレード

本脆弱性の恒久対応は、修正が含まれる FortiOS 7.6.5 以降へのアップグレードです。アップグレードにあたっては、対応バージョンへの推奨パスの確認や HA 構成での検証、メンテナンスウィンドウの確保をおすすめします。手順の詳細は、関連記事『FortiGate アップグレードパスの確認手順』を参照してください。

Fortinet は推奨アップグレードパスを確認するツールも提供しています。

参考: FortiGuard PSIRT「FG-IR-25-1052」Solution
“Upgrade to 7.6.5 or above”
（7.6.5 以降へアップグレードする）
https://www.fortiguard.com/psirt/FG-IR-25-1052

AD 側の緩和: DenyUnauthenticatedBind の設定

LDAP サーバーが Active Directory の場合、unauthenticated bind を拒否することで、本脆弱性の成立条件そのものを取り除けます。Fortinet の Advisory では、Windows Server 2019 以降で次の PowerShell により unauthenticated bind を無効化する方法が案内されています。

$configDN = (Get-ADRootDSE).configurationNamingContext
$dirSvcDN = "CN=Directory Service,CN=Windows NT,CN=Services,$configDN"
Set-ADObject -Identity $dirSvcDN -Add @{'msDS-Other-Settings'='DenyUnauthenticatedBind=1'}

この設定はフォレスト内のディレクトリサービスオブジェクトに対する変更で、レプリケーションを通じて各ドメインコントローラーに反映されます。適用にあたっては、いくつか留意点があります。

• 設定変更前に、前掲の確認コマンドで現在の msDS-Other-Settings の内容を控えておくことをおすすめします。既存の値がある場合、-Add は追記として動作します。
• ごく一部に、空パスワードでの bind に依存した実装のアプリケーションが存在する可能性があります。影響範囲を見極めるため、メンテナンスウィンドウでの適用と、認証系アプリケーションの動作確認をおすすめします。
• この緩和は本 CVE への対処にとどまらず、unauthenticated bind に起因する認証バイパス全般に効く多層防御になります。FortiOS 以外に LDAP／AD 認証を利用するアプリケーションがある環境では、ディレクトリ側での恒久的なハードニングとして検討する価値があります。

なお、FortiOS のアップグレードがすぐに実施できない場合でも、AD 側で unauthenticated bind を無効化すれば、悪用の成立条件を先に断てます。恒久対応と並行して、ディレクトリ側の緩和を進める運用が現実的です。

暫定緩和: 仮想パッチ

アップグレードも AD 側の設定変更もすぐには難しい場合の暫定策として、FortiGate の仮想パッチ（virtual patch）があります。仮想パッチは IPS エンジンと FMWP データベースを使い、FortiGate 自身宛の既知脆弱性の悪用通信を緩和する仕組みで、Agentless VPN と web GUI のサービスがスキャン対象に含まれます。本脆弱性についても、Fortinet は仮想パッチ用のシグネチャを提供しています（FMWP データベースの更新 26.063 に収録）。

仮想パッチはコードそのものを修正するものではなく、悪用にあたる通信を入口で遮断する暫定策です。設定手順やライセンス要件、確認方法は、関連記事『FortiGate 仮想パッチの設定手順｜FortiOS 脆弱性の暫定緩和』を参照してください。

まとめ

CVE-2026-22153 は、FortiOS 7.6.0 から 7.6.4 の fnbamd に存在する認証バイパスの脆弱性で、LDAP サーバー側で unauthenticated bind が許可されている場合に成立します。恒久対応は FortiOS 7.6.5 以降へのアップグレードですが、Active Directory 側で unauthenticated bind を無効化することでも、悪用の成立条件そのものを取り除けます。二層での対処と、暫定的な仮想パッチの活用を組み合わせることで、対応完了までのリスクを抑えられます。

• FortiOS 7.6.0 から 7.6.4 に影響する認証バイパスの脆弱性
• 原因は LDAP サーバー側の unauthenticated bind の許可
• 恒久対応は FortiOS 7.6.5 以降へのアップグレード
• AD 側で DenyUnauthenticatedBind を設定すれば緩和につながる
• 二層の対処で悪用の成立条件そのものを取り除ける
• アップグレードまでの暫定策として仮想パッチも選択肢
• 自環境のバージョンと LDAP 設定の確認が対応の第一歩

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