WEBサイト
圧縮の部品（Brotli）の脆弱性（CVE-2026-111497）で、当サイトは10月28日に、直った版がまだ出ていない部品を1つ抱えたままになっていた。Webサーバーと PHP が読む部品は、同じ日に別の配布元の直った版へ替えてある。残っていたのは、サーバーのOS側の部品だ。直った版が出たら、圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だったには「この記事の内容を見直す」と、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だったには「替える」と書いていた。
11月10日の朝の点検で、その約束の相手が配布元の一覧に出ているのを見つけた。この記事は、その朝の確かめを順番に書いた記録だ。ポイントは3つある。1つ目は、10月28日の時点で版の番号は上がっていたのに、直ってはいなかったこと。2つ目は、直ったかどうかを、版の番号ではなく「変更の記録」で確かめたこと。3つ目は、部品を替えたあとも、古い部品を掴んだままの処理が1つ残り、「直った」と言い切れなかったことだ。
読み終えると、担当サイトの「直った版が出たか」を、自分のサーバーの配布元の一覧と変更の記録で確かめ、替えたあとに何が残るかを数えて、制作会社やサーバーの担当に聞けるようになる。安全のため、部品や設定の名前、版の番号、ファイルの置き場所は書かない。書くのは、日付、件数、確かめた順番、確かめ方、確かめていないことだ。
何が起きたか ── 3行で、そして10月22日から11月10日まで
3行で言うと
- 10月28日の時点で、OS側の圧縮の部品には、番号の上がった版が入っていたが、変更の記録にこの脆弱性（CVE-2026-111497）の記載は無く、直ってはいなかった。待つことにして、10月29日・11月2日・11月6日の3回（記録に残っている範囲）確かめたが、どれも「まだ出ていない」だった。
- 11月10日の朝、当サイトのサーバーの配布元に新しい版が出ていた。変更の記録にこの脆弱性の修正が書かれていたので、同じサーバーで別のサービスを預かる担当に先に一報し、その部品だけを替えた。サービスの再起動はしていない。
- 替えたあとの応答と画面は前と同じだった。ただし、古い部品を掴んだままの処理が1つ残った。通信を受け持つ処理なので、止めると接続が切れるおそれがあり、止めていない。次にサーバーを起動し直すときに切り替わる。入れ替えは済んだが、その処理のメモリの中は、今も古いままだ。
日付を並べると
この脆弱性は、10月22日にCVE番号が公開された。当サイトの動きと並べると、次の表のようになる。
| 日付 | 世の中で起きたこと | 当サイトの動き |
|---|---|---|
| 10月22日 | CVE番号が公開された（NVDの公開日） | — |
| 10月23日 | 別の配布元（長期サポート向け）が、修正した版の告知を出した | — |
| 10月27日 | CISAの悪用確認の一覧に追加された（期限は11月10日と書かれている） | — |
| 10月28日 | — | Webと PHP が読む部品を、別の配布元の直った版へ替えた。OS側の部品は、番号の上がった版が入ったが、変更の記録にこの脆弱性は無かった |
| 10月29日 | — | 自分のサーバーの配布元で確かめた。まだ無い |
| 11月2日 | — | もう一度確かめた。新しい版は無く、変更の記録にこの番号は0件 |
| 11月6日 | — | 昼の点検でも、新しい版は無かった |
| 11月10日 | — | 朝の点検で、新しい版が出ているのを見つけ、その部品だけを替えた |
表の「—」は、その日に当サイトが確かめた範囲で、特に書くことが無かったという意味で、何も起きていないという意味ではない。11月10日は、CISAの一覧に書かれた期限の日にあたる。この期限はアメリカの連邦機関に向けたもので、当サイトに義務は無い。ただ、日付が重なったので、並べて書いた。
版の番号が上がっても、直ったとは限らなかった
10月28日に入った版は、変更の記録にこの脆弱性が無かった
10月28日、当サイトは圧縮の部品を2つ更新した。1つは、Webサーバーと PHP が読む部品で、別の配布元が出した直った版だ。もう1つは、OS側の部品で、番号が1つ上がった版が入った。番号が上がったので、直ったと読みたくなる。ところが、その版の変更の記録を開くと、書かれていたのは別の変更だけで、この脆弱性の番号は無かった。
この「OS側の部品は、まだ直っていない」ことは、同じ日の、別の担当者の確認で分かった。
配布元は、公式の版の番号を上げずに直すことがある
なぜ、版の番号が当てにならないのか。Red Hatは、公開している説明の中で、こう書いている。
"Customers need to be aware that just looking at the version number of a package will not tell them…"
（日本語訳: 利用者は、パッケージの版の番号を見るだけでは、（脆弱性が直っているかは）分からないと知っておく必要がある…）
同じページは、直し方の仕組みも説明している。
"They will instead have an older upstream version with backported patches applied."
（日本語訳: 代わりに、古い元の版に、取り込んだ修正が当てられたものになる。）
「元の版」は、公式が出している版のことだ。配布元は、公式の新しい版を丸ごと入れるのではなく、公式の古い版に、修正だけを取り込んで出すことがある。この方式を、修正の取り込み（バックポート）と呼ぶ。このとき、公式が直した版の番号より低い番号のまま、直った版になる。
今回の脆弱性でも、10月23日に別の配布元（長期サポート向け）が出した告知は、元の公式の版の番号を上げず、配布元の印を末尾に付けた版で直した、と読める書き方だった。公式が直した版の番号より低く見えるのに、脆弱性は直っている。この例が、版の番号だけで判断してはいけない理由を示している。同じ向きの話は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったで、PHPについて書いた。表示された版や「作った日」は、修正の有無の証拠にならなかった。
だから、変更の記録を読む
版の番号に代わる確かめ方が、変更の記録だ。パッケージには、「いつ、何を直したか」の履歴が付いていて、直した脆弱性の番号が書かれていることが多い。この履歴に、探している番号があるかを見る。ただし、変更の記録は万能ではない。書かれていないことは、直っていない証拠ではなく、書き忘れかもしれない。書かれていることも、「直した」と書いてあるという事実までしか言えない。動作で確かめられるものは、動作でも確かめる。次の表に、4つの確かめ方を並べた。
| 確かめ方 | 分かること | 分からないこと |
|---|---|---|
| 版の番号 | 前と違うか。入れ替わったか | 修正が入ったか。取り込み型だと、公式より低い番号のまま直ることがある |
| 変更の記録 | 配布元が、この番号の修正を取り込んだと書いているか | その修正が、全部の経路を塞ぐか。書いた日が、配布元の一覧に出た日か |
| 勧告のページ | 製品ごとの状態と、公式が勧める対応 | 最新の状態か。更新が追いついているか（今回は「調査中」のままだった） |
| 動いている処理の中 | どの処理が、どの部品を読み込んでいるか。古い部品を掴んだままか | その処理が、危ない経路で実際に使うか |
この4つは、1つで足りるものではなく、組み合わせて使う。10月28日は、1つ目（版の番号）が上がっていて、2つ目（変更の記録）に無かった。11月10日は、1つ目が上がり、2つ目に書かれていた。違いは、2つ目にある。
「直った版が出たか」は、自分のサーバーの配布元で確かめる
待っている間の確かめを、日付つきで並べる
待つと決めたからには、待っている間も、確かめ続ける必要がある。当サイトが確かめた日と結果を、次の表にまとめた。
| 確かめた日 | 結果 | どう確かめたか |
|---|---|---|
| 10月29日 | まだ無い | 自分のサーバーの配布元の一覧で、新しい版があるかを見た |
| 11月2日 | 新しい版は無い。変更の記録に、この番号は0件 | 一覧と変更の記録の両方。さらに、知っている別の番号が記録に載るかも見た |
| 11月6日（昼） | まだ無い | 昼の点検の中で見た（手順の記録は残っていない） |
| 11月10日（朝） | 新しい版が出ていた | 朝の点検で、一覧と変更の記録の両方を見た |
3回目までは「まだ無い」で、4回目に見つかった。確かめた日と結果は、日付つきで残した。残してあったので、「11月6日の昼には無く、11月10日の朝には在った」と、後から言える。
仲間が運営するサイトで出ても、自分のサーバーに来ているとは限らない
10月29日の朝、仲間が運営するサイトで、OS側の直った版が出た、と聞いた。当サイトのサーバーでも探したが、無かった。理由は配布元が違うことで、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だったの「配布元の取り違え」に、10月29日の時点で書いた。それでも11月2日に、別の配布元の版の話と、自分の配布元の話を混同しかけて、仲間と読みが食い違った。そこで、配布元の違いだと確かめ直した。
同じ系統のOSでも、配布元が違えば、直った版が出る日は違う。仲間のサーバーで出ていることは、自分のサーバーに来ている証拠にならない。逆に、自分のサーバーで出ていないことは、安心の理由にならない。確かめる先は、自分のサーバーの配布元の一覧だ。配布元の名前は、記録に書く前に、そのサーバーの中で確かめる。
測り方の確かめ ── 見つからない結果を、うのみにしない
11月2日の確かめでは、変更の記録に、この番号が0件だった。「0件」は、本当に無い場合と、探し方が壊れている場合がある。そこで、記録の中に必ず載っているはずの、前の別の脆弱性の番号でも探した。その番号は載っていた。探す手順は生きていて、そのうえで、この番号は無かった。
11月10日にも、同じことをした。新しい変更の記録には、前の別の番号が4か所載っていて、探す手順が壊れていないことを示していた。そのうえで、今回の番号の修正が書かれていた。0件のときも、見つかったときも、「必ず在るはずのもので試す」を先に済ませてから、結果を読む。
変更の記録の日付は、配布元に出た日ではない
11月10日に見つけた変更の記録の日付は、11月2日だった。ところが、当サイトは11月2日にも、11月6日の昼にも、出ていないことを確かめている。記録の日付と、配布元の一覧に並んだ日は、別のものだ。記録の日付は、パッケージを作った側が付けた日と読める。ただし、確かめてはいない。
だから、「いつ出たか」は、当サイトの記録からは分からない。言えるのは、「11月6日の昼には無く、11月10日の朝には在った」までだ。この間の4日のうち、いつ出たかは、毎日確かめていなかったので、特定できない。待っている間は、確かめる頻度が、気づく日を決める。今回は、4日おきほどの確かめだったので、出てから気づくまで、数日の差がありうる。
勧告のページは、まだ「調査中」だった
11月10日に、Red Hatのセキュリティ情報（RHSB-2026-015）を開き直した。更新は10月27日の17時37分で止まり、状態は「調査中」のままだった。ページには、こう書かれている。
"The investigation is ongoing and this bulletin will be updated as new information emerges."
（日本語訳: 調査は続いており、この告知は、新しい情報が出たら更新される。）
修正済みのパッケージの一覧も、載っていなかった。一方で、当サイトのサーバーの配布元には、変更の記録に修正が書かれた版が出ていた。勧告のページは、11月10日に開いた時点で、10月27日から更新されていなかった。勧告のページが「調査中」のままでも、配布元の一覧に直った版が出ていることはありうる。逆に、勧告に書かれていても、自分のサーバーには来ていないこともある。見る場所は、1つに決めない。ただし、「自分のサーバーに入る版かどうか」を決めるのは、自分のサーバーの配布元の一覧だ。
ここで言えるのは、11月10日に開いた時点で、そう読めた、というところまでだ。ページが古い内容を返している可能性は、確かめていない。
11月10日の朝に、確かめた7つ
新しい版を見つけたとき、すぐに更新を実行したくなる。当サイトは、次の7つの順番で進めた。順番は、10月28日の部品の入れ替えと同じ形にしてある。7つ目は、「やったあとに残るものを数える」ことだ。
1. 新しい版が在るか
自分のサーバーの配布元の一覧で、この部品の新しい版が在るかを見る。この朝は、一覧に新しい版が出ていた。ここで分かったのは、「在る」という事実だけで、「直っている」とはまだ言えない。
2. 変更の記録に、この番号の修正が書かれているか
版の番号の前に、変更の記録を開いた。この脆弱性の番号で探すと、修正が書かれていた。記録の日付は11月2日だった。前の節に書いたとおり、この日付は、配布元に出た日とは別に扱う。探す手順が壊れていないかは、前の別の番号が、同じ記録の中に4か所載っていることで確かめた。
10月28日の版は、版の番号が上がっていたのに、変更の記録にこの番号が無かった。今回は、番号が書かれていた。「版が新しい」と「記録に書かれている」は、別のものだと、ここで分かれた。
3. 誰がこの部品を読んでいるか
部品を替える前に、動いている処理のうち、どれがOS側のこの部品を読み込んでいるかを数えた。結果は、通信を受け持つ処理が1つだけだった。WebサーバーとPHPは、別の部品を読んでいて、OS側の部品は読んでいなかった。
数える理由は2つある。1つは、替えたあとに「何を再起動すれば足りるか」を決めるため。もう1つは、替えたことで影響が出る範囲を、前もって知るためだ。読んでいる処理が1つだけと分かれば、影響の範囲は、その1つの処理と、それが担う通信に絞られる。
4. 同じサーバーの別のサービスの担当に、先に伝える
当サイトのサーバーには、別のサービスも載っている。部品を替える前に、その担当に、これから何を替えるか、再起動はしない予定であることを、先に一報した。返事は待たなかった。
この一報は、許可を取るためのものではなく、返事を待たずに進めた。先に伝えておけば、あとで何か起きたときに、担当が「何を替えたか」を最初から知っている。伝えることと、許可を取ることは別で、相手が決める余地のある作業なら、返事を待つほうがよい。今回は、替えるのが1つの部品で、サービスの再起動をしない作業だった。
5. その部品だけを替える
入れ替わるものを、先に一覧で見てから、実行した。更新の道具は、頼んだ部品のほかに、動いている別の部品まで一緒に上げようとすることがある。だから、実行の前に、何が入れ替わるかを見る。サービスの再起動はしていない。
読者の担当サイトでは、実行の前に「直す前の版へ戻す」手順があるかも確かめておくとよい。戻せないと分かった更新は、実行しないほうが安全だ。
6. 前と後を比べる
替える前に、応答と画面の中身を控えた。替えたあとに、同じ手順で取り直した。比べた結果を、次の表にまとめた。
| 比べたもの | 前と後 |
|---|---|
| 6つのURLの応答 | 同じ |
| 4ページの見出し・リンク・画像 | 同じ |
| 壊れた画像・構造化データの壊れ・PHPのエラー表示 | 前も後も、問題なし |
| トップページの表示の時刻 | 違う（時計の表示なので、更新の影響ではない） |
| 同じサーバーの別のサービス | 200（正常） |
応答のコードが同じというだけでは足りない。応答のコードからは、画面の中身が変わったかどうかは分からない（本番のコードが、試験環境の設定を読んでいたの中でも、前の姿を先に取っておく大事さを書いた）。画面の中身まで、前と後を比べたことで、「動作は変わらなかった」と言える。前後の画面を残すには、当サイトの🔧 【運営】WEBサイトのスクリーンショット、まとめて撮っちゃおツール ★トレルンも使える。
7. 古い部品を掴んだままの処理を数える
部品を替えたあと、動いている処理のうち、まだ古い部品を掴んでいるものがないかを数えた。部品の入れ替えは、ファイルを新しいものに置き換える作業だ。すでに動いている処理は、起動したときに読み込んだ古い部品を、メモリの中に持ったまま動き続ける。動いている処理が読み込んでいる部品の一覧には、置き換えられて今は無いファイルの横に、「deleted（削除済み）」という表示が出る。この表示が付いた処理を数えた。
結果は、1つだった。通信を受け持つ処理で、手順3で読み込み元として数えたのと同じ処理だ。この処理の扱いが、次の節の話になる。
「直った」と言い切らない理由 ── 入れ替えと、メモリの中は別
入れ替わったことと、動いている処理が新しくなったことは別
ファイルは新しくなった。ただ、1つの処理は、古い部品を掴んだままで、そのメモリの中は古いままだ。だから、当サイトでは、この部品について「直った」と言い切らない。言えるのは、「ファイルは入れ替えた。1つの処理のメモリの中は古いままで、次に起動し直すときに切り替わる」までだ。圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だったで書いたとおり、部品を替えたら、止めて起こし直す、が基本だ。今回は、その最後の1手を、すぐには打てなかった。
止めずに置いた理由
通信を受け持つ処理を、この場で止めると、接続が切れるおそれがある。それで、止めずに置いた。次にサーバーを起動し直すときに、新しい部品を読み込んで、切り替わる。
止めずに置くことは、危険を放置することとは違うと考えている。ただし、置くなら、条件が要る。1つ目は、置いていることを、記録に書くこと。2つ目は、いつ切り替わるか（次の起動）と、そのあとに何を確かめるかを書くこと。3つ目は、置いている間の危険が、どこまで残るかを、分かる範囲で書くこと。この記事は、1つ目と2つ目に当たる。3つ目は、次の節で書く。
残っている危険は、確かめていない
この脆弱性の危険は、外から届いた圧縮データを、元に戻す処理が突かれることにある。Red Hatのページは、こう書いている。
"Exploitation requires that the target decompress attacker-controlled Brotli data…"
（日本語訳: 悪用するには、対象が、悪意を持った側が用意したBrotliのデータを、元に戻す必要がある…。）
残った1つの処理が、圧縮を元に戻す場面があるかは、確かめていない。ただ、「ある」とも「ない」とも、確かめていないので書けない。書けるのは、元に戻す処理が、危ない経路の入口であることと、その処理のメモリの中が、古いままであることまでだ。
圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だったでは、外から圧縮を受け取る場所を、数えて塞いだ。ただ、あのとき数えたのは、プログラムを読んで見つかる場所だった。サーバーの中で動いている、通信を受け持つ処理は、その数え方の対象ではなかった。
次の起動のあとに確かめること
次にサーバーを起動し直したあと、同じ数え方で、古い部品を掴んだままの処理が0になったかを確かめる。0なら、この部品は、ファイルも、動いている処理も新しくなったと言える。0でなければ、どの処理が残っているかを数え直す。そのときの結果は、この記事に、日付つきで追記する。
もう1つ、確かめたい。次の起動のあとに、6つのURLと4ページの中身を、今回と同じ手順で比べる。起動し直しのときは、設定や修正が戻ってしまうことがあるので、前の姿と比べるだけの価値がある。
WEBディレクターが、担当サイトで明日やること
自分で確かめられる場合
サーバーの中を見られる立場なら、次の7つを、順に進める。
- 使っている配布元の名前を、自分のサーバーの中で確かめて、記録に書く。仲間のサーバーや報道で見た名前を、そのまま書かない。
- 確かめたい脆弱性の番号で、自分のサーバーの配布元の一覧と、変更の記録を探す。版の番号だけで決めない。
- 探す手順が壊れていないかを、必ず載っているはずの別の番号で確かめる。0件のときも、見つかったときも。
- 確かめた日と結果を、毎回、日付つきで残す。「出た日」を後から言えなくても、「ここまでは無かった」は言える。
- 替える前に、その部品を読み込んでいる処理を数える。そして、影響の範囲を決める。
- 入れない試しで、入れ替わるものを確かめてから、その部品だけを替える。前後で、応答と画面の中身を比べる。
- 替えたあとに、古い部品を掴んだままの処理を数える。残っていたら、止める日と、そのあとの確かめを決めて記録する。
外から見える範囲の点検は、当サイトの🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルンで始められる。ただし、サーバーの中の部品や、動いている処理は、外からは見えない。今回の確かめは、すべてサーバーの中からのものだ。画面の前後を比べるには、🔧 【メンテナンス】WEBサイトの状況チェック・比較ツール★チガウンが使える。試験用に用意したサイトと本番の違いを、ページごとに自動で比べるツールで、会員限定だ。
制作会社・サーバーの担当への聞き方
サーバーを自分では見られない立場なら、聞く。「更新しましたか」と聞くだけでは、「しました」で終わる。確かめられる形で聞く。
| 聞くこと | 返ってきた答えの読み方 |
|---|---|
| 修正は、どの脆弱性の番号について、どの配布元の何で確かめましたか。版の番号だけではありませんか | 「最新です」だけなら、版の番号の話にすぎない。変更の記録に番号があったか、を聞く |
| 「直った版が出たか」は、どこの配布元の一覧で確かめていますか | 「ニュースで見た」「別のサーバーで出ていた」なら、自分のサーバーの配布元で確かめる習慣は、まだ無い。責める場面ではなく、確かめる先を決める場面だ |
| 部品を替えたあと、その部品を掴んだままの処理は残っていませんか | 「再起動しました」で終わらず、数えた結果を聞く。残っているなら、いつ切り替わるかも |
| 替えたあと、応答だけでなく、画面の中身も前後で比べましたか | 応答のコードだけなら、画面の中身は未確認 |
| すぐ止められない処理は、ありますか。それは、いつ、どう確かめますか | 「ある」と答えられるのは、数えている証拠。「ない」と即答なら、数えたかを聞く |
疑うための質問ではない。確かめる材料を、お互いに出し合うための聞き方だ。
待っている項目に、「待ちの印」を付ける
今回のように、「直った版が出たら替える」と決めた項目は、待っている間、一覧の中で止まっている。止まっている項目には、「何を待っているか」と「次に見直す日」を書く。書いておかないと、止まっているのか、忘れているのかが、区別できなくなる。本番のコードが、試験環境の設定を読んでいたで書いた、62日止まった項目は、この「待ちの印が無い」点が同じだった。
今回は、見直す約束を圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だったに、替える約束をPHPの2件の脆弱性が悪用リストに載り、期限は10月29日だったに書き、10月29日・11月2日・11月6日と、日付つきで確かめていた。何を待っているかと、確かめた日が記録に残っていたので、11月10日の朝も確かめられた。ただし、確かめる頻度は、4日おきほどの手作業だった。配布元の新しい版を、毎週確かめる仕組みは、記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だったの宿題として残っていて、今も手で見ている。
公式の文書は、何と言っているか
Red Hat: 版の番号では、直ったか分からない
Red Hatのセキュリティ更新の説明は、修正の取り込み（バックポート）を、更新を安全に配るための方法として説明している。先に引用した2つの文のとおり、利用者は、版の番号だけでは、直ったかを判断できない。直ったかを確かめる材料として、同じページは、告知や、脆弱性の状態を機械で照合する情報を挙げている。変更の記録を読むことは、この考え方と矛盾しない。
Red Hat: この脆弱性の勧告は、調査中だった
前の節に書いたとおり、11月10日に開いた時点で、この脆弱性の勧告は「調査中」で、更新は10月27日だった。勧告のページは、対応するパッケージが出たら、すぐに更新するよう勧めている。回避策としては、Webの入り口（プロキシなど）で、外から来る圧縮の方式の指定を、断る方法が書かれている。当サイトの入り口で、この方法を使うかは、今回は決めていない。
CISA: 一覧への追加と、期限
CISAの悪用確認の一覧には、この脆弱性が、10月27日に追加された。一覧では、名前が「Google Brotli Unchecked Return Value Vulnerability」（戻り値の未確認）と書かれている。NVDの説明にある「バッファオーバーフロー」とは、呼び方が違う。同じ番号なら同じ問題だ。追うときは、名前ではなく番号で追う。期限は11月10日と書かれていて、これはアメリカの連邦機関に向けたものだ。日本の民間のサイトに義務は無いが、悪用が確認された脆弱性の、優先順位を決める材料にはなる。
当サイトの現在地 ── 実施したことと、これから
- ✅ 当サイト実施済 OS側の圧縮の部品の直った版が出ているのを、11月10日の朝の点検で見つけた。変更の記録に、この脆弱性（CVE-2026-111497）の修正が書かれていることを確かめた。探す手順が壊れていないかも、別の番号で確かめた。
- ✅ 当サイト実施済 部品を読み込んでいる処理を数え、同じサーバーの別のサービスの担当に先に伝え、その部品だけを替えた。サービスの再起動はしていない。
- ✅ 当サイト実施済 替えた前後で、6つのURLの応答と、4ページの中身（見出し・リンク・画像・壊れた画像・構造化データ・PHPのエラー表示）を比べ、同じだった（トップの表示の時刻の差を除く）。同じサーバーの別のサービスも、正常だった。
- ✅ 当サイト実施済 10月28日の約束（OS側の直った版が出たら替える）を、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だったの項目に反映し、「🔧」から「✅」に直した。圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だったにも、日付つきで追記した。
- 🔧 当サイトこれから 古い部品を掴んだままの通信を受け持つ処理が、次にサーバーを起動し直したときに切り替わったかを確かめ、この記事に追記する。
- 🔧 当サイトこれから 配布元の新しい版を、毎週確かめる仕組みを作る。今は手で見ている。
- 🔧 当サイトこれから 担当サイトの一覧に、「配布元」と「修正が入ったかを何で確かめたか」の欄を足す。圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だったとPHPの2件の脆弱性が悪用リストに載り、期限は10月29日だったに書いた約束で、まだ足していない。
まとめ
持ち帰ってほしいことは、5つだ。
- 版の番号が上がっても、直ったとは限らない。10月28日に入った版は、番号が上がっていたのに、変更の記録にこの脆弱性の番号が無かった。
- 「直った版が出たか」は、自分のサーバーの配布元の一覧と、変更の記録で確かめる。仲間のサーバーや報道では、分からない。変更の記録の日付は、配布元に出た日とは別に扱う。
- 探して見つからないときも、見つかったときも、必ず載っているはずのもので、探す手順が生きているかを先に確かめる。
- 部品を替える前に、その部品を読む処理を数え、同じサーバーの別の担当に先に伝える。替えるのは、その部品だけにして、前後で、応答だけでなく画面の中身も比べる。
- 替えたあとに、古い部品を掴んだままの処理を数える。残っていれば、「直った」と言い切らず、いつ切り替わるかと、そのあとに何を確かめるかを記録に書く。
確かめていないことも書いておく。1つ目は、残った1つの処理が、外から届いた圧縮データを元に戻すかどうかだ。確かめていない。2つ目は、変更の記録に書かれた修正が、この脆弱性のすべての経路を塞ぐかどうかだ。配布元の記録に書かれていることしか、確かめていない。3つ目は、変更の記録の日付が、パッケージを作った側の日付かどうかだ。そう読んだが、確かめていない。4つ目は、配布元の一覧に新しい版が出た日だ。11月6日の昼には無く、11月10日の朝には在った、までしか分からない。5つ目は、Red Hatのページが、実際に古い内容かどうかだ。開いた時点でそう読めたが、確かめていない。6つ目は、次に起動し直したあとの結果で、まだ起きていない。
関連 archives（連載軸として読む）
- 圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 直った版が出たら記事の内容を見直す、と書いた記事。11月10日に、日付つきで追記した（10月28日）
- PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 配布元の取り違えを書き、OS側の直った版が出たら替える、と書いた記事。11月10日に、約束の項目を直した（10月29日）
- PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 版の番号や「作った日」が、修正の証拠にならないという考え方の記事（10月26日）
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── 配布元の更新を、毎週確かめる仕組みを、宿題として書いた記事（10月7日）
- 本番のコードが、試験環境の設定を読んでいた ── 止まっている項目に、「何を待っているか」と見直す日を書く、という記事（11月9日）
解説記事では、Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載ったと、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要るもあわせて読める。ツールでは、画面の前後を日付つきで残すのに、🔧 【運営】WEBサイトのスクリーンショット、まとめて撮っちゃおツール ★トレルンが使える。
出典
すべて2026年11月10日に開いた。
- Red Hat: RHSB-2026-015 Out-of-Bounds Write - Google Brotli Decoder (CVE-2026-111497)（状態は「調査中」・更新は10月27日）
- Red Hat: CVE-2026-111497（悪用の条件の説明）
- Red Hat: Backporting Security Fixes（版の番号と、修正の取り込み）
- NVD: CVE-2026-111497 Detail（公開日は2026年10月22日）
- CISA: Known Exploited Vulnerabilities Catalog（CVE-2026-111497の項。追加日は10月27日、期限は11月10日）
- 別の配布元（長期サポート向け）の告知: 2026年10月23日付（この脆弱性を修正した版の案内）
