WatchGuard AuthPointの脆弱性4件とは?対象バージョンと7.6.0への更新手順

広告

WatchGuard AuthPointで公表された4件の脆弱性は、AuthPoint Authentication Gateway 1.0以上7.6.0未満が対象です。

Gatewayは自動更新されないため、該当環境では管理者による7.6.0以上への更新が必要です。

この記事では、情シス・ネットワーク・セキュリティ担当者向けに、自社が対象かを判定する方法、4件のCVEとLDAP・AD・RADIUS・ADFSとの関係、更新前の確認、公式手順に沿った更新、更新後の実認証テストまで順番に整理します。

Installerの完了だけで対応済みにせず、利用者が正常に認証できるところまで確認してください。

楽天上半期ランキング公開中
Amazonと楽天で価格を比較してみる

楽天で人気の商品をランキングからチェックできます。
気になる商品はAmazonの価格や在庫とも比べてみてください。 <PR>

※価格・ポイント・在庫状況は変更される場合があります。
※最新の情報は各販売ページでご確認ください。

WatchGuard AuthPointの脆弱性はGateway 7.6.0未満が対象

今回のWatchGuard AuthPointの脆弱性で確認すべき対象は、AuthPoint Authentication Gateway 1.0以上7.6.0未満です。

Gatewayを利用していて該当バージョンが残っている場合は、管理者が7.6.0以上へ更新する必要があります。

「AuthPointを使っているから全部対象なのか」と慌てる前に、まずGatewayの利用有無と現在のバージョンを確認してください。

自社が更新対象かをGatewayの有無とバージョンで判定する

対象かどうかは、AuthPoint Authentication Gatewayを使っているか、そのバージョンが7.6.0未満かの2点で判定できます。

自社環境 今回の対応
Gatewayを利用していない 今回公表されたGatewayソフトウェア4件の直接的な更新対象ではない
Gateway 1.0以上7.6.0未満 更新対象
Gateway 7.6.0以上 今回の4件については影響対象外

WatchGuard PSIRTによると、4件はいずれもAuthPoint Authentication Gateway 1.0以上7.6.0未満が影響を受け、7.6.0で修正されています。

月曜の朝に脆弱性情報が届き、「うちはAuthPointを使っている。すぐ全社へ影響を知らせるべきか」と迷う場面もあるはずです。

そのときは製品名だけで判断せず、まず管理対象のGatewayを洗い出すのが近道です。

今回の「7.6.0」はAuthPoint Authentication Gatewayのバージョンであり、FireboxやFirewareのバージョンを指していません。

AuthPoint全体やWatchGuard製品全体をまとめて更新対象と扱うと、変更計画を誤る原因になります。

Gatewayは自動更新されないため7.6.0以上へ手動更新する

AuthPoint Gatewayは、待っていれば自動的に最新版へ切り替わる仕組みではありません。

WatchGuardの更新手順では、新しいGateway Installerを管理者が取得し、既存Gatewayへ適用する流れになっています。

7.6.0未満を確認した時点で、手動更新が必要な環境として扱ってください。

7.6.0は2026年10月29日に公開され、4件のCVEは2026年11月4日に公表されました。

つまり、公表前から修正版は提供されていましたが、Gateway側が自動で更新されるわけではありません。

「クラウドサービスだから裏側で修正済みだろう」と判断すると、古いGatewayがそのまま残るおそれがあります。

複数拠点やSecondary Gatewayを運用している場合は、1台だけではなく全Gatewayのバージョンを確認することが欠かせません。

更新対象を把握したら、次に自社のLDAP、Active Directory、RADIUS、ADFS構成と4件のCVEを照らし合わせます。

4件の脆弱性をCVE別・認証構成別に確認する

今回公表された4件は、重大度だけでなく攻撃が成立する条件も異なります。

すべてを「同じ条件で外部から即座に悪用できる脆弱性」と捉えず、自社の認証構成と成立条件を分けて確認することが大切です。

特にLDAP、Active Directory、RADIUS、ADFSのどれを使っているかで、優先して見るべきCVEが変わります。

4件のCVEを深刻度・成立条件・影響で比較する

4件の内訳はCriticalが3件、Highが1件で、CVSS v4.0は8.9から9.2です。

CVE 深刻度 主な成立条件 主な影響
CVE-2026-121639 Critical
CVSS 9.2
LDAPまたはActive Directory providerを設定し、攻撃者がGatewayホストへネットワークアクセスできる 認証サービスの妨害やローカルのディレクトリ同期設定削除
CVE-2026-121638 Critical
CVSS 9.1
RADIUS、LDAP、ADFS resourceを利用し、攻撃者が通信経路上にいる Gatewayとローカル認証プロバイダー間の通信傍受や改ざん
CVE-2026-121640 Critical
CVSS 9.1
Gatewayコンポーネント間の正規リクエストを攻撃者が観測・取得している 正規要求の再送による不正な管理操作や認証サービス妨害
CVE-2026-121637 High
CVSS 8.9
LDAP providerを設定し、攻撃者が有効なheader signatureを取得している 認証結果やtransaction identifierの偽造

CVE-2026-121639は、4件の中で最も高いCVSS 9.2が付いた問題です。

LDAPまたはActive Directory providerを利用する構成が関係し、ネットワークアクセス可能な未認証攻撃者によって認証サービスを妨害されるおそれがあります。

CVE-2026-121638は証明書検証に関する問題で、攻撃者が通信経路上に位置することが前提です。

CVE-2026-121640はcapture-replayに関する問題で、攻撃者があらかじめ正規リクエストを観測・取得している必要があります。

CVE-2026-121637ではLDAP認証コールバックの整合性検証に問題があり、有効なheader signatureを取得した攻撃者による認証結果の偽造につながります。

成立条件はCVEごとに違うため、CVSSだけを見て自社での攻撃可能性まで同じと判断しないでください。

LDAP・AD・RADIUS・ADFS別に確認すべきCVEを整理する

自社環境でどのCVEを優先して確認するかは、利用中の認証方式から絞り込めます。

利用構成 特に確認するCVE 確認理由
LDAP CVE-2026-121637、121638、121639、121640 LDAP固有の問題を含み、4件すべてが確認対象になる
Active Directory CVE-2026-121639、121640 121639ではActive Directory providerが条件として明記されている
RADIUS CVE-2026-121638、121640 121638はRADIUS resourceが対象で、121640もGateway利用環境で確認が必要
ADFS CVE-2026-121638、121640 121638はADFS resourceが対象で、121640も確認対象になる

LDAPを利用している環境は、今回の4件すべてを確認対象として扱うのが分かりやすい整理です。

一方で、「LDAPを使っていないから今回は関係ない」とは限りません。

RADIUSやADFSを利用する環境ではCVE-2026-121638が関係し、CVE-2026-121640も特定のproviderだけに限定された問題ではありません。

たとえばVPN認証でRADIUSを使っている情シス担当者なら、「LDAPはないから大丈夫」と判断する前にRADIUS経路を確認する必要があります。

認証方式ごとの違いは更新の要否をなくすものではなく、影響の見方と作業後の確認項目を決める材料です。

2026年11月7日時点で、WatchGuardは4件とも実際の悪用を把握していません。

ただし、悪用未確認は安全を意味しないため、Critical 3件を含む対象Gatewayを残す理由にはなりません。

自社が7.6.0未満なら、次はGatewayの台数やPrimaryとSecondaryの構成を整理し、安全に更新できる状態を作ります。

AuthPoint Gateway 7.6.0へ更新する前に確認すること

更新前に確認すべきなのは、対象Gatewayのバージョンだけではありません。

Gatewayの台数、PrimaryとSecondaryの役割、現在の認証経路まで把握してから作業に入ると、更新による認証停止を避けやすくなります。

特に古いGatewayでは更新方法そのものが変わるため、現在のバージョン確認を省略しないでください。

Gatewayのバージョン・台数・PrimaryとSecondaryを確認する

最初にAuthPointのGateway一覧を確認し、対象となるGatewayの台数と現在のバージョンを記録します。

複数拠点で運用している場合やSecondary Gatewayを構成している場合は、すべてのGatewayを一覧化しておくと更新漏れを防げます。

たとえば金曜の夕方に緊急変更を組む場面で、「本社の1台だけ上げれば終わりだろう」と進めると、別拠点に7.6.0未満が残る可能性があります。

WatchGuardでは、1台のPrimary Gatewayに対して最大5台のSecondary Gatewayを構成できます。

ただし、Secondary GatewayがあればPrimaryのすべての役割を代替できるわけではありません。

Secondary GatewayはLDAP user synchronizationには使われないため、冗長構成だから無条件にPrimaryを止めてもよいとは判断できません。

更新前には、LDAP、Active Directory、RADIUS、ADFSのどの認証経路で各Gatewayを使っているかも確認します。

RADIUSやVPN認証をGateway経由で利用している環境では、更新中の停止が利用者のログインに影響することがあります。

変更作業票には、少なくとも次の項目を残しておくと確認しやすくなります。

  • 対象Gatewayの台数
  • 各Gatewayの現在のバージョン
  • PrimaryかSecondaryか
  • 利用しているLDAP・AD・RADIUS・ADFSの経路
  • 更新後に実施する認証テスト

更新前のゴールは、どのGatewayを止めたときに、どの認証経路へ影響するかを説明できる状態にすることです。

3.1.3-83より古いGatewayは通常とは別の更新手順を使う

AuthPoint Gateway 3.1.3-83より古い環境では、通常の上書き更新と同じ手順をそのまま使いません。

WatchGuardのUpgrade Notesでは、該当する古いGatewayについて登録解除やアンインストール、新しいregistration keyを使った登録を含む別の手順が案内されています。

「とにかく最新Installerを実行すればよい」と考えていると、この分岐を見落とします。

3.1.3-83より古い場合は、通常の既存Gateway更新手順をそのまま適用しないでください。

一方、通常の既存Gateway更新では、事前にGatewayをアンインストールする必要はありません。

ここを混同すると、本来不要な登録作業を増やしたり、逆に古いGatewayへ不適切な更新方法を適用したりする原因になります。

長期間更新していない環境ほど、「今のバージョンは何だったか」を管理画面で確認してから手順を選ぶのが安全です。

7.6.0未満かどうかだけでなく、3.1.3-83より古いかどうかも更新ルートを決める分岐点です。

AuthPoint Gatewayを7.6.0以上へ更新して動作確認する手順

AuthPoint Gatewayの脆弱性対応は、Installerを実行して終わりではありません。

更新後にGatewayがgreenで稼働し、7.6.0以上になり、外部ID接続と実際の認証まで成功して初めて作業完了と判断できます。

更新作業と動作確認を一続きの手順として実施してください。

Gateway Installerを取得して対象Gatewayを更新する

通常の既存Gateway更新では、AuthPoint management UIから新しいGateway Installerを取得して実行します。

WatchGuard公式手順では、Downloadsを開き、Gateway Installerから利用中のOSに合うInstallerをダウンロードします。

取得したInstallerを対象Gateway上で実行し、更新を進めます。

通常の既存Gatewayであれば、事前アンインストールや新しいregistration keyの発行は不要です。

作業の流れは次のように整理できます。

  1. AuthPoint management UIのDownloadsを開く
  2. OSに合うGateway Installerを取得する
  3. 対象GatewayでInstallerを実行する
  4. Gateway画面で状態とバージョンを確認する
  5. 外部ID接続と実認証を確認する

深夜のメンテナンスでInstallerが正常終了すると、そこで「終わった」と判断したくなるところです。

ですが、インストール処理が完了しても、GatewayがWatchGuard Cloudへ正常に接続できているとは限りません。

Installerの終了画面ではなく、管理画面と実際の認証結果を成功条件にしてください。

すぐに更新できない環境でアクセス制限を強化することは、多層防御の一つにはなります。

ただし、証明書検証やcapture-replayなど今回の問題自体を修正するものではありません。

公式な解決策はAuthPoint Authentication Gatewayを7.6.0以上へ更新することです。

green表示・バージョン・外部ID接続・実認証まで確認する

更新後は、まずGatewayページでstatus iconがgreenになっているかを確認します。

greenはGatewayがWatchGuard Cloudと通信できていることを示します。

同じ画面でcurrent versionを確認し、7.6.0以上が表示されていることも確かめてください。

Gatewayが複数台ある場合は、一部だけでなく全台を確認します。

確認項目 成功の目安 見落としやすい点
Gateway状態 status iconがgreen Installer終了だけでは正常稼働を保証しない
Gatewayバージョン 7.6.0以上 Primaryだけでなく全Gatewayを確認する
External Identity 必要な接続確認が成功 Check Connectionだけでは同期全体を確認できない
実認証 業務で使う認証経路でログイン成功 LDAP・RADIUS・ADFS・VPNなど実利用経路を確認する

LDAPやActive Directoryを利用している環境では、External IdentitiesからCheck Connectionを実行できます。

ただし、この確認はIP、port、System Accountのusernameやpasswordなどを中心とした接続テストです。

Check Connectionが成功しても、LDAP user synchronizationや実際のユーザー認証まで正常とは限りません。

そのため、更新後は同期状態を確認し、最後に実際に業務で使っている認証経路でテストします。

RADIUSならRADIUS経由、ADFSならADFS経由、VPNでGatewayを利用しているならVPNログインまで確認します。

「管理画面はgreenなのにユーザーがログインできない」という状態を残さないための最後の確認です。

異常がある場合は、WatchGuard Cloudのaudit logやGateway local logsを確認します。

エラーコードやrequest ID、Gateway側のログを追うと、接続や認証処理のどこで問題が起きているかを切り分けやすくなります。

脆弱性対応の完了条件は「更新したこと」ではなく、「7.6.0以上で利用者が正常に認証できること」です。

WatchGuard AuthPointの脆弱性対応は全Gatewayの認証確認まで行う

今回のWatchGuard AuthPointの脆弱性対応では、AuthPoint Authentication Gateway 1.0以上7.6.0未満を残さず、更新後の実認証まで確認することが完了条件です。

バージョンアップだけで作業を閉じず、Gatewayの状態、外部IDとの接続、実際の認証経路まで順番に確認してください。

変更管理の記録には、次の項目をそのまま完了チェックとして使えます。

  • すべてのAuthPoint Authentication Gatewayを洗い出した
  • すべてのGatewayが7.6.0以上になっている
  • 各Gatewayのstatus iconがgreenになっている
  • LDAPやActive Directoryなど必要な外部IDとの接続を確認した
  • LDAP user synchronizationなど運用中の同期処理を確認した
  • RADIUS、ADFS、VPNなど実際に使う認証経路でテストした
  • 異常がある場合はaudit logやGateway local logsを確認した

「Installerは正常終了したし、これで対応済みにしてよいだろう」と作業票を閉じたくなるところですが、そこではまだ利用者側の認証成功を確認できていません。

PrimaryとSecondaryを含む全Gatewayを対象に確認し、古いバージョンの取り残しがない状態にします。

特に3.1.3-83より古いGatewayがある場合は、通常の上書き更新とは異なる公式手順を使う点も忘れないでください。

Check Connectionの成功だけでLDAP同期や実認証まで正常と判断せず、利用者が実際に通る認証経路を最後にテストしてください。

2026年11月7日時点でWatchGuardは4件の実際の悪用を把握していませんが、今回の脆弱性にはCriticalが3件含まれます。

「悪用報告がないから待つ」のではなく、対象Gatewayを特定し、7.6.0以上への更新と認証確認まで進めるのが今回の対応の要点です。

自社環境のGateway、認証方式、更新経路を一つずつ確認すれば、必要以上に影響範囲を広く捉えずに対応できます。

タイトルとURLをコピーしました