WatchGuard AuthPoint Gatewayの認証関連4件を修正 7.6.0への更新と確認手順

WatchGuardは2026年11月4日、AuthPoint Authentication Gatewayの脆弱性4件を公表しました。修正版は7.6.0です。LDAPまたはActive Directoryを設定した環境では、Gatewayホストにネットワークで到達できる第三者が、認証を経ずに認証サービスを妨害し、ディレクトリ同期の設定を削除できる可能性があります。運用者は対象となるGatewayを更新し、認証できることと同期設定が残っていることを別々に確認してください。

対象版は1.0以上7.6.0未満です。WatchGuardのGatewayリリースノートでは7.6.0の配布日は10月29日とされており、11月4日の脆弱性公表日とは異なります。すでに修正版が入った環境でも、待機系や別拠点に旧版が残っていないかを確認します。WatchGuardは個別勧告で、実環境での悪用は把握していないと説明しています。以下の点検や検証は本サイトの運用提案で、個別環境の実測結果ではありません。

LDAPやActive Directoryを使う構成では同期設定も点検

主題のWatchGuard勧告 CVE-2026-121639はCVSS 4.0で9.2です。LDAPまたはActive Directoryのプロバイダーが設定された構成において、Gatewayホストへネットワークで到達できる攻撃者が、認証を受けずに認証サービスを妨害し、ローカルディレクトリの同期設定を削除できるおそれがあります。「リモート」はGatewayホストへ通信が届くことを前提としています。インターネット公開がない場合も、社内のどのネットワークや接続先から到達できるかは確認が必要です。

サービスの妨害と同期設定の削除は別の症状です。既に登録されている利用者のテストログインが通っても、次回の同期で追加や変更が反映されることまでは確認できません。逆に同期エラーが出たことだけで、攻撃があったと判断することもできません。同期先、同期対象、直近の正常時刻など、運用で把握できる情報を記録し、意図した設定との差と障害が出た時刻を確認します。とくに入退社や異動で利用者を日々更新する組織では、ログインと同期を別々の監視対象にすると異常を切り分けやすくなります。

例えば外部公開の業務アプリから認証を求める環境では、ブラウザーでログイン画面が表示されることと、認証基盤がディレクトリに到達できることは異なります。ログインできないときはアプリケーションだけを再起動せず、認証を依頼する側、Gateway、ディレクトリ側を分けます。一部の利用者だけが失敗するなら、利用者の所属グループや対象プロバイダーが共通していないかを調べます。こうした確認は運用障害とセキュリティ調査の両方に使えますが、原因を一つに絞るには当時の設定やログが必要です。

残り3件は通信位置と取得した情報が異なる

WatchGuard勧告 CVE-2026-121638は、RADIUS、LDAP、ADFSのいずれかのリソースを設定している構成で、証明書検証の不備により、通信経路上にいる攻撃者がGatewayとローカル認証プロバイダーの通信を傍受・改変できる可能性を示しています。ホストへネットワークで到達できるだけの攻撃と、通信経路上に位置する必要がある攻撃を区別します。この項目を点検する場合は、利用している認証先だけでなく、実際にどの経路を通るかや、途中に中継する機器があるかも把握しておきます。

WatchGuard勧告 CVE-2026-121640は、Gatewayの構成要素間で正規の要求を観測した攻撃者が、その要求を再送して、許可されていない管理操作を行える可能性を示しています。認証サービスの妨害も起こり得ます。認証を経ずに同期設定を削除できる主題の問題とは前提が異なり、正規の要求を観測できることが条件です。すでに許可された通信だから再び到着しても安全だと判断できない点が、この問題の特徴です。

WatchGuard勧告 CVE-2026-121637はLDAP構成での問題です。ネットワーク上の攻撃者が有効なヘッダー署名を入手した場合に、認証結果とトランザクション識別子を要求本文で偽造できるおそれがあります。LDAPを使う環境では、同期だけでなく認証結果が適切に扱われたかも点検します。LDAPを使っていない環境では、この条件が当てはまらないことを確かめたうえで、残りの勧告を別に照合します。四つの勧告で修正版は同じですが、どの業務経路を試験するかは構成によって異なります。

稼働中のGatewayを列挙して更新順を決める

最初に管理画面と配備台帳を照合し、Gatewayのホスト名、稼働版、設置場所、担当する認証先を一覧にします。LDAP、Active Directory、RADIUS、ADFSのうち使っているものを付記し、主系だけでなく補助のGatewayにも対象版がないか調べます。新規導入用イメージや復旧時に使うインストーラーが古い場合は、今回の更新後も旧版を再導入する原因になります。稼働中のホストと今後の配備元を別々に確認しておくと、更新結果を維持しやすくなります。

WatchGuardのGateway構成ガイドでは、複数のGatewayがあるとき、LDAP同期に使う主系を切り替えられる一方、主系の変更がRADIUSサーバーとRADIUSクライアント間の認証プロセスには影響しないと説明しています。LDAP同期を引き継げたことは、各RADIUSクライアントの接続が試験済みであることを意味しません。複数台の環境で段階的に更新するなら、どのノードに各クライアントが接続し、更新中にどこへ切り替わるかを事前に確認します。単一台なら、変更中にログインできない可能性を業務側に知らせ、別の管理経路から復旧できることを確認します。

更新はWatchGuardの配布資料に従い、7.6.0以降を使います。適用前に同期先や設定の記録を取り、復旧に必要な手順と実行できる担当者を確認します。適用後は各ホストの稼働版を読み直し、実際の認証や同期に使われるノードが更新されたことを確かめます。配備ツールの成功だけでは、サービスの起動、外部認証先との接続、切り替え先の稼働まで分かりません。段階的に更新する場合は、旧版の残存台数と、どの業務がまだそこを利用するかを残します。

更新を待つ間は、Gatewayホストに到達できる経路を棚卸しし、業務に不要な経路を絞る方法が考えられます。ただし、今回の四つの問題に対する修正として扱わないでください。通信経路上での傍受や正規要求の再送は、単純に公開入口を閉じるだけでは評価できません。また、必要な認証クライアントや同期先の通信まで遮断すると業務停止につながります。変更の前に許可する通信元と宛先を把握し、正常な接続が通ることを検証します。

たとえば、東京と大阪にGatewayが一台ずつあり、東京側をLDAP同期の主系、大阪側を拠点内のRADIUSクライアントの接続先として使っているとします。この場合、東京側で更新後の同期に成功しても、大阪側の利用者の認証は別に試します。大阪側の更新を延期するときは、残っている旧版にどの通信元が到達できるかと、延期中の連絡先を記録します。逆に認証経路を切り替えた場合は、アプリ側で試験した接続がどのGatewayに届いたかを確認しないと、更新前のノードで成功した結果を誤って採用してしまいます。この例は構成に応じて検証表を作るためのもので、製品が任意の拠点間で自動的に引き継ぐという意味ではありません。

正常なログインと拒否されるログインを分けて確認

更新後は検証用アカウントで、利用している認証経路ごとに通常のログインを試します。正常な資格情報で通ることに加え、無効な資格情報や利用を許可しない検証アカウントが拒否されることを確認します。利用者に影響するアカウントをわざとロックする必要はありません。同期を使う環境では、検証対象の属性変更など業務に影響しない操作を用い、同期が完了し、想定した対象にだけ反映されたことを確認します。同期エラー時に既存利用者のログインがどう見えるかは別に記録します。

RADIUSやADFSを使っている場合は、その構成で通常使うアプリケーションから認証を試します。障害が出た場合は、アプリケーションの時刻、Gatewayの認証記録、認証プロバイダー側の記録を突き合わせ、どこまで要求が届いたかを調べます。待機系を使う場合は、意図した経路で引き継がれることも確認します。正常・拒否の試験は、更新による業務上の変化や構成の誤りを見つけるためのものです。脆弱性を再現する試験ではなく、試験が通ったことから過去の悪用の有無は判断できません。

以前の異常が疑われるときは記録を保全

過去に理由の分からない認証停止や同期設定の消失があった場合は、設定を戻す作業と記録の保全を分けます。Gatewayの稼働時刻、認証エラーや管理操作の記録、認証先のログが残っていれば、変更管理の記録と照合します。LDAPの結果偽造が懸念される場合には、認証を求めた側と実際に結果を返す側の記録が一致するかを確認します。公開資料はこの調査で使える固有の検知指標を列挙していないため、個々の事象を今回の脆弱性に結び付けるには追加の根拠が必要です。

作業記録では、対象版の解消、認証の正常系と拒否側、ディレクトリ同期、確認できた過去の範囲を別々に残します。これにより、アップデートは完了したが以前の異常は調査中、あるいは主系は正常だが別拠点の切り替え試験は保留といった状態を明確にできます。業務アプリ担当者と認証基盤担当者が異なる場合は、誰が各結果を確認するかを先に決めておくと、ログイン障害が出たときに調査を引き継ぎやすくなります。