SonicOSのSAML認証回避で悪用確認 SSL-VPNの更新先と別認証経路を点検

SonicWallのSonicOSで、SSL-VPNに設定したSAML認証を別の認証方式から回避できる脆弱性CVE-2026-19868が公表されました。SAML側で多要素認証（MFA）を必須にしていても、その制御を迂回される可能性があります。CISAは2026年11月6日に既知の悪用がある脆弱性のKEVカタログへ追加しました。該当するSSL-VPNをWebサービスの保守接続や管理用ネットワークへの入口にしている組織は、露出と認証設定を確認し、修正版への更新を優先してください。

修正先はGen7がSonicOS 7.3.4-7013以降、Gen8が8.2.3-8015以降です。開発元は回避策を「None」としています。更新前の到達制限と、更新後の認証試験、更新前の接続記録の調査を分けて進めます。本記事は11月8日に開発元告知、公式CVEレコード、KEVの内容を確認した対応解説です。以下の運用手順は本サイトの提案であり、特定環境での動作を実測したものではありません。

SAMLを有効にしたSSL-VPNが今回の対象

SonicWallの告知SNWLID-2026-0014は、CVE-2026-19868の条件を、SSL-VPNログインでSAMLが有効なインターフェースまたはサービスに限ると明記しています。攻撃の説明には、別の認証方式で有効な資格情報を持つ利用者という前提があります。誰でも資格情報なしにすべてのSonicWall機器へ入れる問題として扱うのは不正確です。

ここで問題になるのは、SAMLで認証するつもりの入口に、別方式による受付経路があることです。SAMLを使うIDプロバイダーでMFAを強制しても、そこを通らずに接続できれば、その認証ポリシーだけでは入口を保護できません。SAMLの暗号やMFA製品そのものが破られたという意味ではなく、SonicOSが認証を強制する境界の問題です。

Web担当者が機器を直接管理していない場合も、保守用VPNの先に何があるかは確認できます。管理画面、踏み台、CIの管理機能、データベースなどへの到達がVPNの接続後に許可される構成なら、アプリ担当とネットワーク担当で入口と許可範囲を対応付けます。VPNへ接続できたことだけで、各アプリの認可まで自動的に突破されると断定する必要はありません。

悪用確認と評価値は出典を分けて読む

開発元は、悪用の可能性を示す報告を調査したと説明し、速やかな最新版への更新を強く求めています。これに対し、CISAのKEV登録は既知の悪用があるという優先判断に使えます。CISAの公式KEV JSONでは登録日が11月6日、ランサムウェアでの利用状況はUnknownです。登録を根拠に、ランサムウェアでの利用や自組織の侵害まで確定してはいけません。

このCVEについてSonicWallが示すCVSS 3.1基本値は7.1で、ベクトルはAV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:Nです。同じ告知の冒頭には8.8も表示されますが、告知に含まれる別の脆弱性の評価を今回の認証回避へ流用しません。公式CVEレコードのCISA ADPには7.5という別評価があります。本記事では開発元の7.1を主題CVEの値として使い、更新優先度は評価値に加えて悪用確認と自社の露出から決めます。

Gen7とGen8の更新先を取り違えない

系列	告知の影響版	告知の修正版
Gen7ハードウェア・Gen7 NSv	7.3.3-7015およびそれ以前	7.3.4-7013以降
Gen8ハードウェア・Gen8 NSv	8.2.2-8015およびそれ以前	8.2.3-8015以降

Gen7にはTZ 270、NSa 2700、NSsp各系列など、Gen8にはTZ 80、TZ 280、NSa 2800各系列などが挙げられています。NSvにはESX、KVM、Hyper-Vに加えAWSとAzure上の構成も含まれます。物理機器のラック台帳だけで確認を終わらせず、仮想ファイアウォールの配備一覧も照合してください。個々の機種は告知のAffected PlatformsとFixed Platformsで確認します。

特にGen8の8.2.2-8015は影響版側にあります。末尾のビルド番号だけを見ると8.2.3-8015と混同しやすいため、系列を含む完全なバージョン文字列を記録します。別系列のファームウェアを数字の大小だけで選ぶのではなく、機種に合う更新先と供給元の導入手順を使います。ダウンロードしたファイルと、稼働中の機器へ反映した版も区別してください。

担当者への依頼票には「SonicWallを更新してください」だけでなく、SSL-VPNの公開先、SAMLを使うログインの有無、機種と完全な版、修正後の稼働版を並べます。クラウド上のNSvを他社へ運用委託している場合は、クラウド事業者が管理するサービスの更新と、自社が配備した仮想アプライアンスの更新責任を分けて確認します。AWSやAzure上にあるという理由だけで、自動修正を期待しないようにします。

更新前は認証経路と管理到達範囲を整理する

最初の棚卸しでは、機器名、機種、稼働版、SSL-VPNの有効状態、SAMLログインの有効状態、接続を許すネットワーク、保守対象のサービスを一行にまとめます。SAML設定の存在だけで対象と決めず、SSL-VPNのログインへ実際に使っているかを確認します。予備の機器や障害時の切替先にも同じ設定が残っていないか点検します。

次に、SAML以外の認証方式と利用者の割り当てを確認します。通常利用者、保守委託先、緊急時用アカウントなどについて、どの認証経路を使う設計かを運用担当者と照合します。攻撃の再現を本番へ試す代わりに、設定と試験用アカウントで許可すべき経路を明らかにします。公表文だけから、ある方式を無効にすれば完全に修正できると決めつけないでください。

すぐ更新できない場合、SSL-VPNへの到達元を必要な範囲へ絞る、不要な公開や利用を一時停止するといった露出低減を検討します。これは本サイトが提案する暫定的な運用判断であり、SonicWallが保証した回避策ではありません。停止によって保守担当が締め出されないよう、更新作業に使う正規の管理経路と切り戻し条件を先に確認します。MFAを外して接続を復旧する方法は対策にしません。

更新は実際に接続を受ける機器まで確認する

更新作業では構成の控えと現在の稼働版を保全し、接続停止の影響を把握したうえで、対象機種の公式手順に従います。作業記録には取得したファームウェア、対象機器、作業前後の版、反映時刻を残します。管理用の一覧で更新予定となったことと、機器が修正版で動いていることを混同しないようにします。

冗長構成では、利用者の接続を受ける機器だけでなく、待機側や障害時の切替先も確認します。今回の告知はすべての冗長構成に共通の作業順を保証するものではないため、製品の運用手順へ合わせて進めます。更新後に古い側へ切り替わる可能性が残るなら、接続試験に成功しても対応完了とはしません。

同じ告知には管理インターフェース、SSL-VPN、TACACS+などに関わる複数の修正が含まれます。今回のSAML条件に当てはまらないことだけを理由に、告知全体の更新を不要と判断しないでください。一方、別CVEのサービス妨害や管理操作の説明を混ぜて、CVE-2026-19868が任意コード実行まで許すと表現することも避けます。

成功するログインと拒否するログインを分けて試す

更新後は、試験用の利用者が正規のSAML経路でIDプロバイダーへ移動し、予定どおり認証され、必要なサービスだけへ接続できることを確認します。既存セッションや認証済みブラウザーでは追加のMFA画面が省略される場合もあるため、画面が出た回数だけで判断せず、IDプロバイダーのポリシーと記録を照合します。

続いて、設計上許可しない別方式のログインが通らないことと、失効した試験用アカウントが拒否されることを確認します。正規のSAMLログインが成功しただけでは、他の入口が閉じた証拠になりません。逆に全員がログインできなくなった状態を防御成功と扱わず、許可と拒否の双方を記録します。試験は管理下の環境とアカウントに限定し、公開機器へ攻撃用入力を送る必要はありません。

更新前の接続記録も調査対象に残す

更新は今後の悪用を防ぐための措置であり、過去の接続が正当だったことを証明しません。影響版とSAMLの設定が重なった期間を特定し、VPN側のログイン・セッション記録とIDプロバイダー側の認証記録を照合することを提案します。利用者、接続元、認証方式、時刻、到達先を追える範囲でまとめ、保守担当の予定作業とも比較します。

VPN側に成功記録があるのにIDプロバイダー側で対応が見つからない場合も、直ちに悪用と断定しません。ログの保存期間、時刻のずれ、既存セッションの再利用、アカウントの対応付けを確認します。そのうえで説明できない接続や想定外の到達先があれば、記録を保全して調査担当へ引き継ぎます。追加調査に必要なログを、通常のローテーションで失わないようにします。

侵害が疑われる場合は、該当セッションや資格情報の扱い、接続先サービスの監査、必要な封じ込めを組織の手順で判断します。全利用者のパスワード変更だけで脆弱な受付処理が直るわけではありません。完了条件は、該当する稼働機器すべてへの修正反映、認証経路の許可・拒否の確認、過去の記録の調査範囲が引き継がれていることです。

ログの照合結果は、確認できた接続と、資料不足で判定できない接続を分けます。たとえばVPNの記録が一週間分しかないなら、それ以前も安全だったとは報告できません。調査票には各ログの最古・最新時刻、タイムゾーン、収集元の機器を残すと、担当交代後も不足期間が分かります。告知には個別組織に適用できる万能な侵害判定ルールは示されていないため、一つの検索語が見つからないことを侵害なしの根拠にはしません。

関連記事

KeycloakのSAML署名検証回避と更新手順は、別製品のSAML連携を扱う記事です。Keycloakも運用している場合はそれぞれ独立した更新対象として確認してください。今回のSonicOS更新でKeycloak側の修正が済むわけではありません。