セキュリティ SonicWallのVPNで多要素認証が素通り。CVE-2026-19868は悪用が報告済み、回避策はなし SonicWallは2026年11月6日、SonicOSの脆弱性7件をまとめた勧告SNWLID-2026-0014を公表。このうちSSL-VPNの認証回避CVE-2026-19868(CVSS 7.1、CWE-308)は、別の認証方式の正しい資格情報を持つ利用者がSAML認証の制御を回避でき、SAMLで強制される多要素認証まで回避され得る欠陥で、同社のPSIRTが悪用の可能性を示す報告を調査したと明記。対象はSAMLをSSL-VPNログインに有効化した場合のみで、Gen7は7.3.3-7015以前、Gen8は8.2.2-8015以前、修正版は7.3.4-7013と8.2.3-8015。回避策はなく、CISAは同日に悪用確認済みリスト(KEV)へ追加し連邦機関へ11月20日までの対応を求めた
まず初めに
多要素認証は「パスワードが漏れても、もう1関門あるから大丈夫」という保険である。その保険の受付を、別の窓口の鍵で素通りできるなら、保険は掛けたことにならない。今回の欠陥は派手な突破ではなく、その「別の窓口」が開いていたという、地味で一番困る種類の話だ。
※個人の感想です
欠陥の中身——「認証なしで入れる」ではない
SonicWallの製品セキュリティ対応チーム(PSIRT)の勧告によると、CVE-2026-19868はSonicOSのSSL-VPNサービスにおける認証実施(authentication enforcement)の脆弱性です。別の認証方式(alternate authentication method)の正しい資格情報を持つ利用者が、SAML認証の制御を回避できる可能性があり、悪用が成功すればSAMLで強制される多要素認証も回避され得る、と説明されています。
前提を正確に押さえる必要があります。この欠陥は、資格情報なしでログインできる欠陥ではありません。攻撃側には、対象アカウントで使える別の認証方式の正しい資格情報が要ります。怖さはその先で、本来は盗まれたパスワードだけでは突破できないはずのSAML+MFAの関門が、そのパスワード側の経路から入ると適用されなくなる点にあります。
分類はCWE-308(単一要素認証の使用)で、CVSS基本値はSonicWallの評価で7.1(ベクトルは CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N)です。勧告にはっきり書かれているとおり、この脆弱性が影響するのは、SSL-VPNのログインにSAMLが有効化されている場合のみです。SAMLを使っていないSSL-VPNは、この欠陥自体の対象ではありません。
勧告には、もう1つ重要な一文があります。SonicWall PSIRTは、この脆弱性の悪用の可能性を示す報告を調査した(investigated a report indicating potential exploitation)とし、利用者へ最新リリースへできるだけ早く更新するよう強く求めています。攻撃の詳細、攻撃者、被害件数は公表されていません。
SonicWallの勧告(2026年11月6日)に基づく図解です。 IT Post編集部
対象と修正版、回避策はなし
報道(BleepingComputer)が勧告内容として伝えた対象と修正版は、次のとおりです。
対象
影響を受ける版
修正版
SonicOS Gen7
7.3.3-7015以前
7.3.4-7013
SonicOS Gen8
8.2.2-8015以前
8.2.3-8015
SonicWallは回避策(ワークアラウンド)を示していません。つまり、設定の切り替えで一時的にしのぐ方法は公表されておらず、修正版への更新自体が対策です。CISAは2026年11月6日にCVE-2026-19868を悪用確認済み脆弱性リスト(KEV)へ追加し、連邦の文民機関へ11月20日までの対応を求めました。KEVへの追加は「悪用が確認されている」という当局側の判断を示しますが、被害の規模や攻撃者の情報が公開されたという意味ではありません。ランサムウェアへの利用は、CISAの記録では不明(Unknown)とされています。
同じ勧告の残り6件も、同じ更新で直る
SNWLID-2026-0014は合計7件の脆弱性をまとめた勧告です。CVE-2026-19868以外では、管理インターフェースの2件(許可の緩いクロスドメイン政策と、セッション検証の問題、いずれもCVSS 8.8で、特定の条件で未認証の攻撃者が許可されていない操作を行える可能性)、SSL-VPNとTACACS+の認証前バッファオーバーフロー(サービス妨害の可能性)、仮想アプライアンスの弱いパスワードハッシュなどが含まれます。
スコアだけ見れば管理画面側の8.8の方が高いのですが、悪用の報告とKEV追加の対象になったのは7.1の認証回避の方です。実務上は切り分けに意味はなく、同じファームウェア更新で7件まとめて直ります。更新のついでに、SSL-VPNのログイン記録で、SAMLを経由しない認証方式による不自然なログインがなかったかを確認しておくことも、勧告の内容から読み取れる初動です。これは一般的な点検の考え方であり、SonicWallが侵害の発生を認めたという意味ではありません。
管理者が確認する順番
対象かどうかと、やるべきことは、順番に切り分けられます。
自組織のファイアウォールがGen7かGen8かと、稼働中のSonicOSの版を確認する。Gen7で7.3.3-7015以前、Gen8で8.2.2-8015以前なら、版の条件には当てはまります。
SSL-VPNのログインにSAMLを有効化しているかを確認する。有効化していなければ、CVE-2026-19868そのものの対象ではありません。ただし同じ勧告の残り6件は別途当てはまる場合があるため、更新自体の要否は残ります。
両方に当てはまる場合は、回避策がないため修正版(Gen7は7.3.4-7013、Gen8は8.2.3-8015)への更新を計画する。CISAが連邦機関に求めた期限は11月20日です。
更新までの間と更新後に、SSL-VPNの認証記録で、SAMLを経由しない方式による想定外のログインがなかったかを確認する。
IT Postの見方
IT Postでは、今回の本質は「MFAを入れたのに効かなかった」ではなく「MFAが掛かる経路と掛からない経路が同居していた」ことだと考えます。認証方式を複数残すこと自体は移行期には避けられませんが、弱い方の経路が残っている限り、全体の強さは一番弱い経路で決まります。SAML化した組織ほど「もう大丈夫」と思い込みやすい分、この欠陥の刺さり方は深い。
ベンダーの公表の仕方は率直な部類です。悪用の可能性を示す報告を調査したこと、対象がSAML有効時だけであること、回避策がないこと。その3つが勧告の中で読み取れます。利用者側に残された判断は単純で、対象版を使っているなら11月20日という当局の期限を自組織の期限として扱い、更新を前倒すかどうかだけです。
今後どうなりそうか
今後の確認点は、悪用の詳細や侵害指標(IoC)が追加で公表されるか、同じ勧告の他の6件について悪用の確認が広がるかです。対象機器を使う組織では、修正版への更新の進み具合がそのままリスクの残り具合になります。
IT Postでは、新しい公式情報が確認できれば続報として整理します。