WEBサイト
11月11日の昼、チームの仲間がまとめている「世の中のセキュリティの知らせ」で、OpenSSH の脆弱性（CVE-2026-123158）を知った。アメリカの CISA が管理する「悪用が確認された脆弱性」の一覧（KEV）に11月9日に載り、一覧に書かれた対応の期限は11月12日。つまり、知った日の翌日だ。NVD（アメリカの脆弱性データベース）に載っている CVSS の基本値は8.1（高）だった。
「期限が明日」と聞くと、まず自分のサーバーの SSH の版の番号を調べたくなる。この記事でやったのは、それとは別の順番だ。先に、知らせが書いている「対象の条件」を原文で読み、次に、その条件に自分のサーバーが当たるかを、設定ファイルではなく、動いているものから確かめた。版の番号を調べるのは、そのあとでよかった。
結果を先に書くと、当サイトのサーバーは、知らせに書かれている対象の形には当たらなかった。ただし、知らせは「当たらない形」を網羅して書いているわけではないので、「安全」とは言い切らず、配布元から更新が出たら当てる。読み終えると、「期限が明日の脆弱性の知らせ」が届いた日に、自分の担当サイトが対象かどうかを、その日のうちに、読むだけの作業で確かめられるようになる。安全のため、当サイトの部品や設定の名前、版の番号、ファイルの置き場所は書かない。書くのは、日付、確かめた順番、確かめ方、確かめていないことだ。攻撃の手順や、再現の方法も書かない。
何が起きたか ── 3行で、そして11月5日から12日まで
3行で言うと
- OpenSSH のサーバー側（sshd）に、パスワードでのログインが通ってしまう脆弱性（CVE-2026-123158）が見つかった。11月5日に直った版（10.6p2）が出て、11月9日に CISA の悪用確認の一覧に載った。期限は11月12日。
- NVD の説明が対象にしているのは、「musl という C ライブラリを使い、PAM（ログインの認証の仕組み）を使わない Linux」の sshd だ。例として挙げられているのは Alpine Linux。
- 当サイトのサーバーは、C ライブラリが glibc（musl ではない）で、PAM を使う設定になっていて、パスワードでのログインはもともと無効だった。sshd を動かすコンテナも無い。書かれている対象の形には当たらなかった。ただし、glibc が対象外だとは、どこにも書かれていない。
日付を並べると
公開されている日付を、当サイトの動きと並べると、次の表のようになる。
| 日付 | 世の中で起きたこと | 当サイトの動き |
|---|---|---|
| 11月5日 | 直った版（10.6p2）が出た。NVD に CVE 番号が載った。Alpine Linux が告知を出し、修正を入れた更新版を出した | — |
| 11月9日 | CISA の悪用確認の一覧に追加された（期限は11月12日） | — |
| 11月10日 | NVD の記載が更新された（最終更新） | — |
| 11月11日の昼 | — | 仲間のまとめで知った。対象の条件を原文で読み、自分のサーバーに当たるかを、読むだけで確かめた |
| 11月12日 | 一覧に書かれた期限の日 | 配布元の更新が出たら当てる（まだ出ていない） |
表の「—」は、その日に当サイトが確かめた範囲で、特に書くことが無かったという意味で、何も起きていないという意味ではない。一覧の期限はアメリカの連邦機関に向けたもので、当サイトに義務は無い。読み替え方は、あとの節にまとめた。
期限の前日に知らせが届いたとき、最初にやることは、更新でも、設定の変更でもない、と考えている。更新や設定の変更は、自分のサーバーに関係があると分かってからでよい。関係があるかどうかを決めるのは、知らせの対象の条件だ。条件を読む作業は、サーバーに入らなくてもできて、サービスにも触らないので、失敗しても影響が出ない。急ぐ日ほど、影響の出ない作業を先に済ませて、影響の出る作業に進むかどうかを決める。
知らせの「対象の条件」を、原文で読む
脆弱性の知らせは、見出しだけだと、全員に当たる話に見える。「OpenSSH に、認証をすり抜けられる脆弱性」と書かれていれば、SSH を使っているサーバーは全部が対象だと感じる。実際には、知らせの本文に「どういう条件のときに起きるか」が書かれていて、その条件に当たるかどうかで、自分に関係があるかが決まる。この節では、今回の知らせの条件を、公式の文書の原文で読んだ。
NVD の説明は「musl」と「PAM なし」を条件にしている
NVD の説明文の冒頭は、次のようになっている。長い文なので、条件の部分だけを引く。
"sshd in OpenSSH before 10.6p2 on Linux, when musl libc is used without PAM, lacks a workaround…"
（日本語訳: 10.6p2より前のOpenSSHのsshdは、Linuxで、PAMなしでmusl libcが使われている場合に、回避策を欠いている…）
説明の続きには、その結果として、アカウントの条件によってはログインできてしまう場合がある、と書かれていた。例として挙げられているのは Alpine Linux で、「musl を使い、PAM を使わない構成」の代表として名前が出ている。NVD のページでは、基本値の8.1は、CVE を割り当てた側（cve@mitre.org）が付けた二次の評価として載っていた。NVD 自身の評価ではない点は、数字を引くときに気をつけたい。
ここで読み取れる条件は3つある。1つ目は、使っている C ライブラリが musl であること。2つ目は、PAM を使わない構成であること。3つ目は、OpenSSH の版が10.6p2より前であること。3つが、そろったときの話だ。説明の続きには、アカウントの構成にも条件があると書かれていて、それは別に数える。
OpenSSH のリリースノートと Alpine の告知は、少し言い方が違う
次に、直した側の OpenSSH のリリースノートを開いた。10.6p2のリリースは、2026年11月5日と書かれている。リリースノートは、この件を、次のように書いている。
"affects Linux systems that use the musl libc and PAM disabled"
（日本語訳: musl libc を使い、PAM が無効になっている Linux に影響する）
リリースノートは、原因は sshd の外にあるが、sshd を通して悪用でき、sshd の側で避けられる、という趣旨も書いている。
"is exploitable via sshd and can be avoided there"
（日本語訳: sshd を通して悪用でき、sshd の側で避けられる）
ここで目に留まったのは、リリースノートの中でも、条件の書き方が2つあることだ。冒頭の説明は「musl と PAM 無効」を挙げているが、Security の項目は「PAM を無効にして組んで動かした一部の Linux」とだけ書き、musl の語を置いていない。NVD の説明とも、少し言い方が違う。もう一つの出どころの Alpine Linux の告知は、さらに別の角度から条件を書いていた。Alpine が配っている SSH のサーバーには、PAM なしで組まれたものと、PAM 付きで組まれたものがある。PAM 付きで組まれていても、設定で PAM を使わない（UsePAM を no にする）なら、対象になる。逆に、PAM 付きで、設定でも PAM を使っているなら、対象にならない。告知は、対象になる条件を、ほかにも挙げている。パスワードでのログインが有効なこと、特定の状態のアカウントがあることだ。
3つの文書を並べると、「PAM を実際に使っているか」が共通の鍵になっている。NVD は「PAM なし」、リリースノートの冒頭は「musl と PAM 無効」で Security の項目は「PAM を無効にした場合」、Alpine は「PAM 付きでも、設定で使っていなければ対象」。言い方は違うが、同じ話を別の角度から書いている。同じ脆弱性でも、出どころによって条件の書き方が違うので、ひとつの文書だけを読んで判断しない。
「版が範囲に入る」と「条件に当たる」は別
NVD のページには、「構成」の欄がある。そこには、OpenSSH の版の範囲（10.6p1まで）に加えて、動く環境として Alpine Linux の版の範囲も並んでいた。musl や PAM の語は、構成の欄になく、説明の文にある。OpenSSH の版の範囲だけを機械的に当てると、版が範囲に入るだけで、条件には当たらない環境も、「対象」に見えてしまう。版の番号を調べて「範囲に入っているから対象だ」と考える前に、説明の文の条件を読む。これが、今回の読み方の出発点だ。
「対象外と書かれていない」と「対象外」は別だ
今回の知らせでは、もう一つ、読み方に気をつけたい点がある。知らせが書いているのは「musl で PAM なしの Linux」の話で、glibc を使う Linux について、「対象外だ」とは、どの文書にも書かれていない。書かれていないだけだ。
glibc の場合は、書かれていないだけ
世の中の Linux の多くは、glibc という C ライブラリを使っている。今回の知らせは、musl を条件にしているので、glibc の環境は、対象の形には当たらないと読める。ところが、「glibc の場合は影響を受けない」と明記した文書は、開いた範囲には無かった。リリースノートの Security の項目も、「PAM を無効にして組んで動かした一部の Linux」と書いているだけで、「musl 以外は安全」とは書いていない。Alpine の告知は、原因を、musl の crypt() という関数の返り値の扱いに置いていて、リリースノートの「原因は sshd の外にある」とも合う。ただし、glibc で同じことが起きないとは、告知にも書かれていない。
読む側は、書かれていることと、書かれていないことを、分けて扱う必要がある。次の表に、今回の知らせで、どう読んだかをまとめた。
| 知らせの書き方 | 読み方 | 当サイトの扱い |
|---|---|---|
| musl で PAM なしの Linux が対象と書かれている | 書かれた条件には、当たるサーバーと当たらないサーバーがある。当たらないサーバーは「対象の形に当たらない」と読む | glibc で PAM を使う設定なので、書かれた形には当たらない |
| glibc は対象外、とは書かれていない | 「対象外」と書かれたのではなく、「書かれていない」だけ。安全とは言い切れない | 「安全」と書かず、更新が出たら当てる |
| パスワードでのログインが有効なことが条件に挙がっている（Alpine の告知） | その機能を止めていれば、少なくとも、その条件には当たらない | もともと止めている。条件の1つに当たらない |
| 直った版は10.6p2 | 配布元の版の付け方で、取り込み型だと番号が違うことがある | 版の番号では判断せず、配布元の更新が出たら当てる |
2行目が、いちばん大事だ。「対象の形に当たらない」と「対象外」は、同じではない。前者は、知らせに書かれた条件と、自分のサーバーを見比べた結果。後者は、書いた側の保証だ。今回、保証は書かれていない。だから、見比べた結果を記録しつつ、「安全」とは書かず、「当たらないと読める。更新は当てる」と書く。
記録には、「当たらない」の一言ではなく、「書かれた条件のうち、どれに当たらないか」を書く。当サイトの記録は、C ライブラリ・PAM・パスワードでのログイン・コンテナの4つについて、それぞれの結果と、確かめた日時を書いた。あとで条件が変わったとき、たとえば、知らせが更新されて、glibc も対象に加わったときに、どの項目を見直せばよいかがすぐ分かる。
自分のサーバーが当たるかを、動いているものから確かめる
条件が分かったので、自分のサーバーに当てはめる。ここで、設定ファイルを読むだけでは足りない、という点に気をつけた。設定ファイルは「こう動かすつもりで書いた」ものだ。実際に動いているものが、その設定のとおりかは、別に確かめる必要がある。今回は、次の4つを、サーバーに入れる人が、読むだけの作業で確かめた。どれも、設定を書き換えたり、サービスを止めたりしない。
1. C ライブラリが glibc か musl か
最初に、使っている C ライブラリを見る。コマンドの種類は、OS によって違うが、標準的なものでは、C ライブラリの版の表示を出すコマンド（ldd の版の表示）で、glibc か musl かが分かる。表示の1行目に「GNU libc」か「GLIBC」の文字が出れば glibc（配布元によって、出る文字が違う）、「musl」と出れば musl だ（musl の表示は標準エラーに出る）。当サイトのサーバーは、glibc だった。musl ではない。
ここで、「うちの OS は何だったか」から調べ始めると、遠回りになる。OS の名前から C ライブラリを推測するより、C ライブラリそのものを聞く方が、確実で、速い。
2. 動いている sshd に、今効いている設定を出力させる
次に、PAM を使っているか、パスワードでのログインが有効かを見る。ここが、今回のいちばんの確かめどころだ。設定ファイルを読むと、「書いてある内容」は分かるが、「今効いている内容」とは違うことがある。たとえば、設定が複数のファイルに分かれていると、どの指定が効くかは、読む順で決まる。sshd は、同じ項目が複数あれば、最初に見つけた値を使う。11月7日のログインのCookieにSameSiteを書いたのに、応答には付いていなかったでは、PHP の設定で、後から読まれる側が置き換えていた。向きは逆でも、「書いてある内容」と「今効いている内容」が違いうる、という点は同じだ。
そこで、sshd 自身に、今効いている設定を出力させた。sshd には、設定を読み込んで、結果を出力するだけのオプション（大文字の T）がある。サービスは止まらず、設定も変わらない。出力は、設定の全部ではなく、必要な2項目（PAM を使うか、パスワードでのログインを許すか）だけを見た。当サイトでは、PAM を使う設定（UsePAM が yes）で、パスワードでのログインは、もともと無効だった。
なお、このオプションの実行には、サーバーの管理者の権限が要る。権限が無い人は、サーバー会社か制作会社に、「今効いている設定を出力させた結果のうち、この2項目を教えてください」と頼めばよい。
3. sshd を動かすコンテナがあるか
Alpine Linux は、コンテナの土台の OS としてよく使われる。Docker などのコンテナの中に、SSH のサーバーを入れて動かしている構成があれば、サーバー本体の C ライブラリが glibc でも、コンテナの中が musl のことがある。当サイトは、sshd を動かすコンテナが0だった。
この確かめは、サーバー本体を見ただけでは分からないことを拾うためのものだ。「サーバーの C ライブラリは glibc」という確かめは、サーバー本体の話にすぎない。
4. 配布元に、新しい版が出ているか
最後に、配布元の一覧で、OpenSSH の新しい版が出ているかを見た。結果は、当サイトで今入っている版と、配布元の最新の版が、同じだった。つまり、新しい版は、まだ出ていない。この確かめについては、次の「配布元の新しい版」の節で、続きを書いた。
当サイトで確かめた結果
11月11日の昼（12時台）に、サーバーの中で、読むだけの確かめを行った。結果を、次の表にまとめた。
| 確かめたこと | 結果 | 知らせの条件との関係 |
|---|---|---|
| C ライブラリ | glibc（musl ではない） | musl が条件のため、当たらない |
| PAM を使うか（動いている sshd に出力させた） | 使う（yes） | 「PAM なし」が条件のため、当たらない |
| パスワードでのログイン（同じ出力） | もともと無効 | Alpine の告知が挙げる条件の1つに当たらない |
| sshd を動かすコンテナ | 0 | コンテナ内の musl は無い |
| 配布元の新しい版 | 今入っている版と同じ（新しい版はまだ無い） | 当てる更新は、まだ出ていない |
結果の読み方
書かれている対象の形には、当たらない。musl でも、PAM なしでもなく、パスワードでのログインも無効だ。ここまでは、確かめた事実だ。そこから先は、読み方だ。当たらないと読めるが、先に書いたとおり、「glibc は対象外」とは書かれていない。そこで、「安全」とは書かず、「書かれた条件には当たらないと読める。直った版が配布元から出たら当てる」としている。
念のために書くと、今回の確かめは、「当たらない」ことを確かめたもので、「入られていない」ことを確かめたものではない。侵入されていないかは、別の調べだ。Alpine の告知は、確認の方法として、認証の記録に、パスワードを持たないアカウントでの「Accepted password」の行が出ていないかを見る、と書いている。この記事の確かめには含めていない。なお、当サイトの無料ツールの🔧 【セキュリティ】IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツール ★iLogツカウンは、Web サーバーのアクセスログ用で、SSH のログインの記録は見られない。
知らせは、出たあとに内容が変わる。NVD の記載は、11月5日の公開のあと、11月10日にも更新されていた。今日の確かめが、明日も正しいとは限らない。確かめた日付を記録に書き、条件の文が変わっていないかを、期限の日と、更新が出た日に、もう一度読む。
配布元の新しい版が出たら、当てる ── 当てたあとに見ること
配布元の版の付け方は、公式と違うことがある。版の番号が「10.6p2以上」かどうかは、判断の材料にならない。実際、Alpine の告知は、系統ごとに別の番号の更新版を並べている。11月10日の待っていた圧縮の部品の修正版が、配布元に出ていた朝で書いたとおり、版の番号ではなく、変更の記録に、この脆弱性（CVE-2026-123158）の修正が書かれているかで確かめる。更新が出る日は、配布元によって違う。
更新が出たかを見る日は、毎週確かめる仕組みができるまでは、知らせの期限の日と、その翌日にする。仕組みが無いうちは、日を決めておかないと、「そのうち見る」になって、見ないまま過ぎる。11月10日の待っていた圧縮の部品の修正版が、配布元に出ていた朝で書いたとおり、新しい版を待っていた間の確かめは数日おきで、いつ出たかは特定できなかった。
更新を当てても、動いている sshd は入れ替わらない
もう一つ、Alpine の告知が書いている大事な点がある。パッケージを上げただけでは、動いている sshd は、入れ替わらない。
"Upgrading the package alone does not replace the running daemon."
（日本語訳: パッケージを上げるだけでは、動いているデーモンは入れ替わらない。）
「デーモン」は、裏で動き続けるプログラムのことだ。ファイルを新しい版に替えても、すでに動いているものは、メモリの中に古い版を持ったままだ。告知は、パッケージを上げたあとに、sshd を再起動するよう書いている。これは、11月10日の待っていた圧縮の部品の修正版が、配布元に出ていた朝で書いた「古い部品を掴んだままの処理が1つ残った」と、同じ形の話だ。PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったで書いたように、表示された版や日付は、修正の有無の証拠にならなかった。更新を当てたら、動いている sshd が、新しい版に切り替わったかを確かめる。
sshd の再起動は、止め方を間違えると、SSH で入れなくなる。現在つながっているセッションは、再起動で切れないことが多いが、念のため、別のセッションをもう1つ開いておき、新しい接続が通ることを確かめてから、元のセッションを閉じる。サーバーに入れない人は、制作会社やサーバー会社に、「更新のあとに sshd を再起動しますか」と聞く。
上げられないときの方法 ── 鍵で入れることを、先に確かめる
更新が出ていない、あるいは、すぐには上げられない場合の方法も、Alpine の告知が書いている。内容は、パスワードでのログインを、設定で止める、というものだ。当サイトは、もともと止めているので、この手順は当てていない。ただ、読者の担当サイトでは、使うことがありうる。この手順で、いちばん大事なのは、順番だ。
止める前に、鍵で入れることを確かめる
告知は、手順の最初に、こう書いている。
"your SSH key login works"
（日本語訳: SSH の鍵でのログインが通ること）
先にパスワードでのログインを止めて、鍵でも入れなかったら、自分がサーバーに入れなくなる。だから、順番は、①現在のセッションを開いたままにする。②別のセッションで、鍵で入れることを確かめる。③その確認が取れてから、パスワードでのログインを止める。④設定の文法を確かめてから、sshd を再起動する。⑤新しい接続で、鍵で入れることを確かめる。この順番を守る。
サーバーに入れない人は、制作会社やサーバー会社に、「パスワードでのログインを止めるときに、鍵でのログインを先に確かめる手順を持っていますか」と聞く。持っていなければ、止める作業そのものが、自分たちでサーバーに入れなくなる事故になりうる。
止めたあとの確かめ
止めたら、sshd に今効いている設定を出力させ、パスワードでのログインの項目が「no」になっていることを見る。設定ファイルに書いたことと、今効いていることは、別だ。ここでも、動いているものから確かめる。
期限は「いつまでに何をするか」ではなく、優先順位の材料
CISA の一覧には、この脆弱性について、追加日が11月9日、期限が11月12日と書かれている。一覧の項目には、「フォレンジックの確認（侵入されていないかの調べ）が必要」という印も付いていた。この期限は、アメリカの連邦機関に向けた決まりだ。日本の民間のサイトに、守る義務はない。この読み方は、10月29日のPHPの2件の脆弱性が悪用リストに載り、期限は10月29日だったで詳しく書いた。解説記事のCISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読むも、同じ読み方を13項目にした。
期限の日に、自分のサーバーで何を確かめたか
今回は、期限の前日に知った。期限を、守るべき日として読むと、慌てて版の番号を調べたり、設定を書き換えたりしたくなる。そうではなく、「優先順位の材料」として読んだ。優先順位を決めるために確かめるのは、①自分のサーバーが、対象の形に当たるか、②当たるなら、外から届く状態か、③上げられない場合の回避策を使えるか、の3つだ。今回、①が「当たらない」だったので、②と③に進む必要は無かった。
ここで、「期限の前日に知った」ことが、ひとつの問題を示している。記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だったで書いた、配布元の新しい版を毎週確かめる仕組みは、まだ無い。この宿題は、11月10日の待っていた圧縮の部品の修正版が、配布元に出ていた朝にも書いた。仲間の知らせで気づけたのは、運が良かった面がある。仕組みで気づける形にしたい。
読者が明日できること ── 7項目
ここまでを、読者が、自分の担当サイトで、明日できる形にまとめた。サーバーに入れる人向けと、入れない人向けに分けた。
サーバーに入れる人
- 知らせの原文を開く。見出しや報道の要約ではなく、NVD の説明文と、直した側（OpenSSH）のリリースノートを読む。「対象の条件」を、自分の言葉で1行にまとめる。
- 条件が複数の文書で言い方が違うときは、共通の鍵を探す。今回は「PAM を実際に使っているか」だった。
- 自分のサーバーの C ライブラリを、C ライブラリそのものに聞く。OS の名前から推測しない。
- 動いている sshd に、今効いている設定を出力させる。設定ファイルを読むだけで済ませない。見るのは、条件に関わる項目だけでよい。
- コンテナを使っているなら、動いているコンテナを一覧にして、中で sshd が動いているものを数える。
- 「書かれた条件に当たらない」と「対象外」を分けて、記録に書く。「安全」と書かない。
- 配布元の更新が出たら当てて、動いている sshd が新しい版に切り替わったか（再起動したか）を確かめる。
サーバーに入れない人（制作会社・サーバー会社に聞く）
担当サイトのサーバーを自分で触れない人は、管理している側に、次のように聞く。
| 聞くこと | 返事から分かること |
|---|---|
| CVE-2026-123158 の対象の条件に、当社のサーバーは当たりますか。当たらないと言える根拠は何ですか | 「対象の形」を、原文から読んでいるか。「うちは大丈夫」だけの返事は、根拠が無い |
| C ライブラリと、PAM を使う設定か、パスワードでのログインが有効かを、教えてください | 動いているものを見ているか。設定ファイルだけを見た返事かどうかは、聞き返して分かる |
| SSH のサーバーを動かすコンテナはありますか | サーバー本体だけでなく、コンテナの中まで見ているか |
| 配布元の更新は、いつ当てますか。当てたあとに、動いている sshd が切り替わったかを確かめますか | 更新を当てたあとの確かめを、手順として持っているか |
| パスワードでのログインを止める場合、鍵で入れることを先に確かめる手順はありますか | 止める作業で、自分たちが入れなくなる事故を防げるか |
外からできる点検には、🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルンがある。ただし、外から見えるのは、見えるものの範囲だけだ。SSH の中の設定は、外から測れないので、中を見られる人に聞く。
当サイトの現在地と、確かめていないこと
当サイトの現在地
この記事の内容を、当サイトの実施状況で整理した。
- ✅ 当サイト実施済 知らせの対象の条件を、原文で読み、自分のサーバーに当たるかを確かめた（C ライブラリ・PAM・パスワードでのログイン・コンテナ。11月11日の昼）
- ✅ 当サイト実施済 パスワードでのログインが、もともと無効なことを、動いているものから確かめた
- 🔧 当サイト、これから 配布元から更新が出たら当てて、動いている sshd が新しい版に切り替わったかを確かめる（11月10日の「古い部品を掴んだままの処理」と同じ形）
- 🔧 当サイト、これから 配布元の新しい版を、毎週確かめる仕組みを作る（記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だったと待っていた圧縮の部品の修正版が、配布元に出ていた朝に書いた宿題の続き）
確かめていないこと
確かめていないことも、書いておく。1つ目は、glibc を使う環境が、この脆弱性の影響を受けないのかどうか。どの文書にも書かれていないので、確かめていない。2つ目は、この脆弱性が、当サイトのサーバーの中で、実際に起きるかどうか。起きるかを試す作業は、していない。3つ目は、NVD の構成の欄にある、動く環境（Alpine Linux の版の範囲）の読み方。API の応答で読んだだけで、画面では見ていない。4つ目は、リリースノートの全文。ページが非常に長く、冒頭の部分だけを読んだので、10.6p2の節以外に関係する記述が無いかは、確かめていない。5つ目は、Alpine の告知に書かれた条件のうち、アカウントの状態に関するもの。当サイトのサーバーのアカウントが、その状態に当たるかは、調べていない（パスワードでのログインが無効なので、条件の1つに当たらないと読んで、先には進まなかった）。6つ目は、配布元の更新が出る日。まだ出ていないことまでしか、分からない。
関連 archives（連載軸として読む）
- 待っていた圧縮の部品の修正版が、配布元に出ていた朝 ── 更新を当てたあとも、古い部品を掴んだままの処理が1つ残った記事（11月10日）
- PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 一覧の期限が、誰のための決まりかを読み替えた記事（10月29日）
- PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 版の表示が、修正の有無の証拠にならなかった記事（10月26日）
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── 配布元の更新を、毎週確かめる仕組みを宿題として書いた記事（10月7日）
- ログインのCookieにSameSiteを書いたのに、応答には付いていなかった ── 設定が2か所にあり、後から読まれる側が置き換えていた記事（11月7日）
解説記事では、CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読むと、VPN機器のIvanti Connect Secureの2件が悪用確認リストに載り、期限の欄は11月2日と13日に分かれたもあわせて読める。ツールでは、外から見える状態の点検に🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルンが使える。
出典
すべて2026年11月11日に開いた。
