SonicWallのSSLVPNは、SAMLで掛けた多要素認証を別の方式の資格情報で回避されうるとして、11月6日に悪用確認リストへ載った。期限は11月20日 ── 担当サイトのログインの「入口」を1つずつ数え、全部にMFAが掛かるかを確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — SonicWallのSSLVPNの1件が11月6日に悪用確認リストへ載った。SAMLで掛けた多要素認証を、別の方式の資格情報で回避されうる
   1. 一覧の行を読む
   2. 告知が書いたこと
   3. 点数を、出典ごとに並べる
2. 02 なぜ・背景 — 「MFAを入れた」ことと、「すべての入口にMFAが掛かる」ことは、別である
   1. 一覧の名前が指す弱点
   2. MFAの「まわりの道」について、OWASPが書くこと
   3. MFAを外す理由には、ならない
   4. 期限の欄は、米国の連邦機関向けの日付
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 「別の認証方式」とは何か
   2. 「悪用の可能性」と「悪用の確認」は別
4. 04 型別 — 適用範囲、書かれていないこと、手順
   1. 🅰 どのサイトが当てはまるか
   2. 🅱 告知と一覧が書いていないこと
   3. 🅲 手順1 — SonicWallを使っているかを、顧客と委託先に聞く
   4. 🅲 手順2 — SSLVPNのログイン方式を、全部書き出す
   5. 🅲 手順3 — 担当サイトの入口を、1つずつ書き出す
   6. 🅲 手順3の補足 — 入口の種類ごとに、見るところを比べる
   7. 🅲 手順3の補足 — 台帳の1行の例（架空）
   8. 🅲 手順4 — 入口ごとに、ログイン直前まで進める
   9. 🅲 手順5 — 掛かっていない入口を、止める・掛ける・理由を書く
   10. 🅲 手順6 — 更新した後に、同じ確認をもう一度する
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 更新までの間と、入口が多いサイトでできること
   1. 状況ごとに、表で並べる
   2. 入口の候補を調べる道具
7. 07 当サイトで確かめたこと — SonicWallは使っていない。ログインの入口の棚卸しは、まだしていない
   1. この製品は、使っていない
   2. 当サイトのログインの入口は、まだ数えていない
   3. 確かめていないこと
8. 08 このテーマは、ここまで — 悪用確認リストを追った記事から、ログインの入口へ
   1. これまでの記事
   2. 今回の記事の位置
   3. 2026年11月7日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — SonicWallのSSLVPNの1件が11月6日に悪用確認リストへ載った。SAMLで掛けた多要素認証を、別の方式の資格情報で回避されうる

2026年11月6日（金曜日）、CISAの悪用確認リスト（KEV）に、SonicWall SonicOSのSSLVPN（社外から社内の仕組みへつなぐ入口のサービス）の脆弱性が1件加わった。CVE-2026-19868である。一覧の説明は、別の認証方式の有効な資格情報を持つ利用者が、SAMLの認証の制御を回避できると書き、成功すると、SAMLで強制した多要素認証（MFA）も回避されうる、と続ける。この記事は、機器の技術的な解説ではなく、「MFAを入れたのに、別の入口が残っていると、MFAを通らない」という形を、担当サイトのログインの入口に当てはめて確かめる方法に絞る（この言い方は、告知の「別の認証方式の有効な資格情報」という書き方からの、筆者の読みである。告知は、入口が別に残っているとは書いていない）。VPN機器の台帳・アカウント・ログを数える方法は、同じ種類の機器を扱った「VPN機器のIvanti Connect Secureの2件が悪用確認リストに載り、期限の欄は11月2日と13日に分かれた ── 担当サイトへの入口の機器の台帳・アカウント・ログを確かめる13項目（2026年11月時点）」で書いたので、ここでは繰り返さない。

一覧の行を読む

11月7日に読んだ一覧のデータには、この行が、次のように書かれていた。

• 一覧の名称は、"SonicWall SonicOS SSLVPN Use of Single-factor Authentication Vulnerability"（訳: SonicWall SonicOS SSLVPNの、単一要素の認証を使う脆弱性）である。
• 追加日は2026年11月6日、期限の欄は2026年11月20日である。追加日から期限の欄まで、筆者が数えると14日になる。
• 「侵害の調査（フォレンジック・トリアージ）」の欄は「なし」、ランサムウェアでの利用の欄は「不明」である。
• 弱点の種類の欄は、CWE-308である。

「必要な対応」の欄は、提供元の手順どおりに緩和策を当て、BOD 26-04の指針に従うよう求める。続けて、"Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable."（訳: クラウドサービスには該当するBOD 26-04の指針に従うか、緩和策が使えないなら製品の利用をやめる。）と書き、さらに"Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines."（訳: 関係者は、各資産がインターネットにどれだけ露出しているかを評価し、BOD 26-04の更新の指針を守る責任を負う。）と書く。書き方の趣旨は、上の記事で読んだIvantiの行と同じである。

告知が書いたこと

SonicWallの告知は、2026年11月6日に初版が出ている。題は"SonicWall SonicOS Affected By Multiple Vulnerabilities"（訳: SonicWall SonicOSは、複数の脆弱性の影響を受ける）で、7件のCVEを挙げ、CVE-2026-19868は、その4番目の項である。項の題は、"SSLVPN Authentication Enforcement Vulnerability via Alternate Authentication Methods"（訳: 別の認証方式を通した、SSLVPNの認証の強制の脆弱性）である。告知は、この項に、2つの注意書きを付けている。1つ目は、悪用の可能性についての文で、2文に分かれている。

"SonicWall PSIRT has investigated a report indicating potential exploitation of this vulnerability."（訳: SonicWallのPSIRT（製品の安全の担当部署）は、この脆弱性が悪用された可能性を示す報告を調べた。）"Customers are strongly urged to upgrade to the latest release as soon as possible to mitigate the associated risks."（訳: 顧客には、関連する危険を減らすため、できるだけ早く最新のリリースへ更新することを強く勧める。）

2つ目は、影響の条件である。"This vulnerability ONLY impacts the SonicOS SSLVPN interface or service if SAML is enabled for SSLVPN logins."（訳: この脆弱性が影響するのは、SSLVPNのログインでSAMLが有効になっている場合の、SonicOSのSSLVPNの画面またはサービスだけである。）告知の「回避策」の欄は、「None」（なし）と書かれていた。更新が、告知の示す対策である。

系統	影響を受ける版	修正版	告知が挙げる機器の範囲
Gen7	7.3.3-7015 以前（"7.3.3-7015 and older versions"）	7.3.4-7013 以降（"7.3.4-7013 and higher versions"）	ハードウェアのファイアウォール（TZ・NSa・NSspの各シリーズ）と、仮想のNSv（270・470・870）
Gen8	8.2.2-8015 以前（"8.2.2-8015 and older versions"）	8.2.3-8015 以降（"8.2.3-8015 and higher versions"）	ハードウェアのファイアウォール（TZ・NSaの各シリーズ）と、仮想のNSv（XS・S・M・L）

機種ごとの細かい一覧は、告知のページにある。同じ告知は、ほかに6件のCVEを挙げ、修正版の表は1つだった。KEVに載っているのは、7件のうち、この1件だけである（11月7日に読んだデータの範囲）。

点数を、出典ごとに並べる

この脆弱性には、見る出典によって、違う点数が付いている。1つにまとめず、出典ごとに並べる。

出典	点数	権限の欄（PR）	補足
告知の冒頭の欄	8.8（CVSS 3.1）	N	7件のうち、いちばん高い点。本文では、別の2件（CVE-2026-107155とCVE-2026-107154）に8.8が付く
告知のこの脆弱性の項	7.1（CVSS 3.1）	L	攻撃の複雑さの欄は「高」（H）
NVDの記録	7.5（CVSS 3.1）	N	種別は「Secondary」。採点した組織は、識別子で書かれ、名前は書かれていない。同じ識別子の欄に、悪用は「active」、自動化は「no」、技術的な影響は「partial」の判定がある（役割の欄は「CISA Coordinator」）
KEVの行	点数の欄なし	—	悪用の事実と、期限の欄を示す一覧で、点数は載せない

FIRSTの仕様書は、権限の欄（PR）のNを「攻撃者が攻撃の前に認可されておらず、攻撃のために、脆弱なシステムの設定やファイルへの権限を必要としない」状態、Lを「利用者の基本的な機能を提供する権限が必要」な状態と説明している（要旨）。告知の文は、別の方式の有効な資格情報を持つ利用者を前提にしている。このため、権限の欄がLの7.1が、文と合うというのが、筆者の読みである。NVDの記録の7.5（N）の理由は、記録に書かれていない。どちらが正しいかは、この記事では決めない。3つの点数は、どれも「High」の区分（7.0〜8.9）に入る。

02 なぜ・背景 — 「MFAを入れた」ことと、「すべての入口にMFAが掛かる」ことは、別である

一覧の名前が指す弱点

一覧の名称にある"Use of Single-factor Authentication"（訳: 単一要素の認証の使用）は、CWE-308の名前である。CWEの説明は、"The product uses an authentication algorithm that uses a single factor (e.g., a password) in a security context that should require more than one factor."（訳: その製品は、複数の要素が要る場面で、単一の要素（たとえばパスワード）だけを使う認証の方式を使っている。）と書く。告知の題は、同じことを別の言葉で言っている。「認証の強制」が、別の認証方式を通ったときに、効かない。つまり、MFAを要る入口として設定していても、その設定が掛からない道が、別にあるということである。どの方式かは、告知にも一覧にも書かれていない。

MFAの「まわりの道」について、OWASPが書くこと

OWASPの多要素認証の手引きは、MFAの課題として、再設定を挙げている。"In order to prevent users from being locked out of the application, there needs to be a mechanism for them to regain access to their account if they can't use their existing MFA; however it is also crucial that this doesn't provide an attacker with a way to bypass MFA and hijack their account."（訳: 利用者がアプリケーションから締め出されないよう、いまのMFAが使えないときに、アカウントへ戻る仕組みが要る。しかし、その仕組みが、攻撃者にMFAを回避してアカウントを乗っ取る道を与えないことも、決定的に大切である。）同じ手引きは、アカウントの回復について、"Account recovery is just an alternate way to authenticate so it should be no weaker than regular authentication."（訳: アカウントの回復は、認証の別の方法にすぎないので、ふだんの認証より弱くあってはならない。）とも書く。

さらに、手引きは、危険な信号に応じて追加の確認を出す方式について、"However, developers must ensure that risk signals cannot be spoofed and that fallback mechanisms are not weaker than the primary MFA methods."（訳: ただし、開発者は、危険の信号が偽装できないこと、そして代わりの仕組みが、主なMFAの方式より弱くないことを、確かめなければならない。）と書く。いずれも、SonicWallの件を書いた文ではない。MFAを置くだけでなく、MFAの代わりになる道を、同じ強さに保つという一般の考え方が、いずれも同じ方向を向いている、というのが筆者の読みである。

MFAを外す理由には、ならない

入口が複数あって回避されうるなら、MFAは役に立たない、とは読めない。OWASPの認証の手引きは、"Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including brute-force attacks, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises."（訳: 多要素認証は、総当たり攻撃を含む、パスワードに関する攻撃の大半に対する、飛び抜けて良い防御で、Microsoftの分析は、アカウントの乗っ取りの99.9%を止めただろうと示唆している。）と書く。99.9%の元の分析は、開いていない。この記事で言いたいのは、MFAは入れたまま、掛かっていない入口を数えることである。

期限の欄は、米国の連邦機関向けの日付

一覧の期限の欄は、BOD 26-04の下で、米国の連邦機関が対応を終える日として置かれている。対象は"Federal Civilian Executive Branch"（訳: 連邦政府の行政機関）の機器である。日本の会社に更新の義務はないが、優先順位の目安には使える。この読み替えは、「CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）」にまとめてある。

03 用語 — 出てくる言葉を、先にそろえる

「別の認証方式」とは何か

告知は、"alternate authentication method"（訳: 別の認証方式）と書き、どの方式かを書いていない。この記事は、方式の名前を推測しない。担当サイトの話をするときは、入口ごとに、何でログインできるかを、自分で書き出す。

「悪用の可能性」と「悪用の確認」は別

告知は、「悪用された可能性を示す報告を調べた」と書く。一方、KEVは、一覧に加える条件の1つとして、"Has reliable evidence of active exploitation in the wild."（訳: 野外で実際に悪用されている、信頼できる証拠がある。）を挙げる（BOD 26-04の実施の手引きの、よくある質問の節）。この行も、一覧に載った。NVDの記録にある、CISAの調整役の判定の欄は、悪用を「active」としている。悪用の規模と、被害の数は、読んだ範囲に書かれていない。

04 型別 — 適用範囲、書かれていないこと、手順

🅰 どのサイトが当てはまるか

告知の条件に当てはまるのは、SonicOSのGen7またはGen8で、修正版より前の版を使い、SSLVPNのログインにSAMLを有効にしている機器である。担当サイトの運用で、この機器を直接持つことは少ないが、顧客の会社や、運用を委託している先が、管理画面への入口としてSSLVPNを使っている場合がある。使っていないと分かったら、台帳に「対象外・確認日・誰に聞いたか」を書いて終える。

この記事の後半（手順3以降）は、SonicWallを使っていなくても、MFAを使っているすべてのログインに当てはめられる、というのが筆者の読みである。

🅱 告知と一覧が書いていないこと

• 「別の認証方式」が、具体的に何か。
• 悪用の件数、悪用した者、国内の被害の有無。
• 修正版が、どう直したか。リリースノートは開いていない。
• 侵害されたかを、機器の記録から見つける方法。一覧の「侵害の調査」の欄は「なし」だった。
• 同じ告知のほかの6件の、細かい条件（この記事は、CVE-2026-19868だけを扱う）。

したがって、どの入口が、どの条件で回避されたかは、この記事では言えない。言えるのは、告知が挙げる版の境目と、影響の条件と、一覧の日付である。

🅲 手順1 — SonicWallを使っているかを、顧客と委託先に聞く

担当サイトごとに、「管理画面や社内ツールを開くとき、SonicWallのファイアウォールのSSLVPNを使いますか」と、1通のメッセージで聞く。返事は、「使っている」「使っていない」「分からない」の3つに分けて、台帳に書く。台帳の作り方は、01章の初めに挙げた、Ivantiの記事の手順2に書いた。

🅲 手順2 — SSLVPNのログイン方式を、全部書き出す

使っている場合は、機器の管理画面でSSLVPNのログインの設定を開いてもらい、SAMLのほかに、どんな方式が並んでいるかを、全部書き出す。方式の数と、名前だけでよい。SAMLを使っていなければ、告知の条件に当たらない。使っているなら、機器の版の確認（05章の4番目の項目）へ進む。

🅲 手順3 — 担当サイトの入口を、1つずつ書き出す

管理画面や社内ツールから3つを選び、ログインの入口を、1つにつき1行で書き出す。入口の名前、使う人、何でログインするか、MFAが掛かるか、確かめた日、の5つの列があれば足りる。入口の候補は、次のとおりである。これは、筆者が思いつく例で、出典の一覧ではない。

• ふだんのログインの画面。
• SSO（まとめてログインする仕組み）のログイン。
• パスワードを忘れたときの再設定。
• 端末をなくしたときの、MFAの登録のやり直し。
• 招待メールのリンクから入る、最初の設定。
• アプリやツールから使う、専用のパスワードやトークン。
• 古い管理画面のアドレスのように、使っていないが、残っている入口。

🅲 手順3の補足 — 入口の種類ごとに、見るところを比べる

書き出した入口を種類で分けると、見るところが変わる。

• ふだんのログイン ── MFAの確認が毎回入るか。
• パスワードの再設定 ── MFAの代わりに、何で本人を確かめるか（02章のOWASPの文）。
• 使っていない古い入口 ── 止められるか（03章のOWASPの対策の一文）。
• アプリ用の専用パスワードやトークン ── MFAを通らずにログインできる方式か（出典には無い、筆者の案）。

🅲 手順3の補足 — 台帳の1行の例（架空）

次の1行は、書き方を示す架空の例で、実在の記録ではない。入口は「管理画面のパスワード再設定」、使う人は「顧客の担当者」、ログインは「メールで届くリンク」、MFAは「無し」、確かめた日は当日の日付である。この行を見て、手順5の3つのどれにするかを決める。

🅲 手順4 — 入口ごとに、ログイン直前まで進める

入口ごとに、自分の試験用のアカウントか、担当者の画面で、ログインの直前まで進み、MFAの確認が入るかを見る。ログインして中に入る必要はない。確認が入らない入口は、台帳の「MFA」の列に「無し」と書く。再設定の入口では、MFAの代わりに何で本人を確かめているかを書く。これは、OWASPの「再設定は、ふだんの認証より弱くあってはならない」という考え方を、台帳に落とす作業である。

🅲 手順5 — 掛かっていない入口を、止める・掛ける・理由を書く

MFAが掛からない入口を見つけたら、3つのどれかにする。使っていないなら止める。使うなら、MFAを掛ける。いまは掛けられないなら、理由と、掛ける予定の日を、台帳に書く。止められるか、掛けられるかは、サービスごとに違うので、各サービスの説明と担当者に聞いて決める。

🅲 手順6 — 更新した後に、同じ確認をもう一度する

SonicWallの機器を更新したら、手順4と同じ確認を、SAMLの入口と、それ以外の入口の両方で行う。更新の前後で、同じ入口を、同じ順番で見る。結果は、日付と一緒に、台帳に書く。

05 明日、担当サイトで確認できることチェックリスト

以下は、SonicWallの1件を担当サイトの入口に当てはめて、MFAが全部の入口に掛かっているかを確かめる13項目である。チェックの状態は、使っているブラウザに保存され、サーバーには送られない。

• CISAの悪用確認リストのデータでCVE-2026-19868を探し、追加日（11月6日）と期限の欄（11月20日）、「侵害の調査」の欄を、台帳に書き写す
• SonicWallの告知（SNWLID-2026-0014）を開き、Gen7とGen8の、影響を受ける版と修正版を、台帳に書き写す
• 担当サイトを3つ選び、SonicWallのファイアウォールを使っているかを、顧客や委託先に1通のメッセージで聞いて、使っている・使っていない・分からないで書く
• 使っている場合は、機器の画面に出る版の番号を、担当者に画面で見せてもらい、Gen7の7.3.3-7015以前か、Gen8の8.2.2-8015以前かを、当たる・当たらないで書く
• SSLVPNのログインの設定を開いてもらい、SAMLを使っているかを、使っている・使っていないで書く
• SSLVPNに並んでいるログインの方式を、SAML以外も含めて全部書き出し、数を台帳に書く
• 担当サイトの管理画面や社内ツールから3つを選び、ログインの入口を、1つにつき1行で、台帳に書き出す
• 書き出した入口ごとに、自分の試験用のアカウントでログインの直前まで進み、MFAの確認が入るかを、入る・入らないで書く
• パスワードの再設定と、MFAの登録のやり直しの入口で、MFAの代わりに何で本人を確かめているかを、1行で書く
• アプリ用のパスワードやAPIのトークンなど、MFAを通らない方式が使えるかを、使える・使えないで書き、使えるものの数を書く
• 使っていない古いログインの入口（古い管理画面のアドレスなど）を、担当者に聞いて、止められるものの数を書く
• 機器を修正版へ更新した後に、手順4と同じ確認を、SAMLの入口とそれ以外の入口の両方で行い、結果と日付を書く
• 次の確認日を台帳に書き、その日に、告知の更新履歴の行の数と日付を、もう一度開いて比べる

06 代替・他の選択肢 — 更新までの間と、入口が多いサイトでできること

状況ごとに、表で並べる

告知の対策は、最新版への更新である。それ以外の行は、出典に書かれていない筆者の案で、どれを選ぶかは、担当サイトの事情で決まる。

状況	選べる対応	利点	注意すること
すぐ更新できる	修正版へ更新する	告知が書いた対策そのもの	更新の前後で、自分の試験用のアカウントで、SSLVPNへログインできるかを確かめる
日にちを置かないと更新できない	更新の日を決め、それまで、SSLVPNを使う人と、使っていない利用者の数を、台帳に書く	更新の順番を、顧客に説明しやすい	告知の「回避策」の欄は「None」。使う人を絞っても、更新の代わりにならない
SAMLを使っていない	台帳に「対象外・確認日・誰に聞いたか」を書く	告知は、影響をSAMLが有効な場合に限る	同じ告知の別の6件には、SAMLの条件が書かれていない（筆者が読んだ範囲）。更新の予定は、別に決める
担当サイトの入口が多い	入口の台帳を作り、MFAの無い入口を、止める・掛ける・理由を書く	回避されうる道を、数で見られる	止めた入口を使っていた人がいないか、先に担当者に聞く
MFAを外したくなった	外さない	OWASPの手引きは、MFAを、パスワードに関する攻撃の大半への飛び抜けて良い防御と書く	外す前に、入口を数える

入口の候補を調べる道具

当サイトの🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — 外から見える入口の候補を探す（利用には無料の会員登録が必要です）は、ページの説明によれば、外から、ポートの探索、ディレクトリやファイルの探索、APIの入口の検出ができる。ログインの入口かどうかを、このツールが判定するとは、説明に書かれていないので、確かめていない。見つかった候補を、台帳の入口の列に足すための手がかりとして使える。Basic認証を残している入口があるなら、🔧 【セキュリティ】Apache ベーシック認証パスワード発行 — Basic認証のパスワードの文字列を作るで、パスワードの文字列を作れる。管理用のパスワードを作るときは、🔧 【運営】パスワード・ジェネレーター、シンプルで使いやすさにこだわってみた、ツール — 管理用のパスワードを作るが使える。Basic認証のパスワードのファイルの置き場所は、ブログの「Basic認証のパスワードのファイルが、公開の場所の中に9本あった ── 外からは全部403だったが、読めなかったのは1つの決まりのおかげだった。確かめ方と、公開の外へ移した記録」に書いた。

07 当サイトで確かめたこと — SonicWallは使っていない。ログインの入口の棚卸しは、まだしていない

この製品は、使っていない

当サイトは、SonicWallの機器を使っていない。したがって、当サイトで更新した記録は無く、05章の3〜6番目の項目と12番目の項目は、担当サイトに向けて書いた。

当サイトのログインの入口は、まだ数えていない

当サイトの会員の画面には、ふだんのログインのほかに、パスワードを忘れたときの再設定の画面がある（当サイトの無料ツールの1つ、パスワード・ジェネレーターの説明が、この再設定に触れている）。それらの入口で、MFAが掛かるか、掛かる入口と掛からない入口があるかは、この記事の時点で、まだ確かめていない。05章の7番目から11番目の項目を、当サイトで行い、結果を日付つきでこの章に書き足す。

確かめていないこと

• 当サイトの各ログインの入口の数と、MFAの有無。
• SonicWallの告知の、更新履歴の後の変更。11月7日に読んだ時点の更新履歴は、初版（11月6日）の1行だった。

08 このテーマは、ここまで — 悪用確認リストを追った記事から、ログインの入口へ

これまでの記事

当サイトは、悪用確認リストに載った製品を、担当サイトの台帳に落とす形で、1本ずつ書いてきた。

• 入口の機器の台帳・アカウント・ログは、「VPN機器のIvanti Connect Secureの2件が悪用確認リストに載り、期限の欄は11月2日と13日に分かれた ── 担当サイトへの入口の機器の台帳・アカウント・ログを確かめる13項目（2026年11月時点）」で書いた。
• 期限の欄の読み替えは、「CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）」で書いた。
• 管理画面の利用者の数え方は、「IPAは、外部に公開しているアプリ・利用中の外部サービス・保有データの3つを速やかに点検するよう呼びかけた ── 管理画面の利用者・ログの保持日数・不要なデータを台帳にして確かめる13項目（2026年10月時点）」で書いた。
• トークンの失効と、社内向けの画面は、「JPCERT/CCの国内の不正アクセスの注意喚起は10月23日に更新された。対策の節は、トークンの有効期限と失効を挙げている ── 失効の手順を実際に引き、社内向けの画面が外から開かないかを確かめる13項目（2026年10月時点）」で書いた。

今回の記事の位置

これまでの記事は、機器や部品の版と更新の優先順位を扱った。今回は、ログインの入口の数へ視点を移した。入口の確認は、サービスや担当者が増えるたびにやり直しになる、というのが筆者の読みである。

2026年11月7日 — この記事の確認日

SonicWallの告知の最終更新日は2026年11月6日で、更新履歴は初版の1行だった。NVDの記録の状態は「Undergoing Analysis」（訳: 分析中）で、NVD自身の点数は、まだ付いていなかった。この日以降に、告知や記録が更新された場合は、05章の2番目の項目で、書き写した版を、もう一度比べる。当サイトの、期限の日に自分の環境で確かめた記録は、ブログの「PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法」にある。