WEBサイトBrotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目（2026年10月時点）
Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目（2026年10月時点）
目次
01 何が起きたか — Brotliのデコーダーに範囲外への書き込みがあり、10月27日にCISAの悪用確認リストへ載った
引用について
この記事の「" "」で囲んだ英語の文は、公式の告知・文書・カタログからの引用で、日本語訳は記事の筆者が付けた。いずれも2026年10月28日に、ページの本文を取り直して、1文字ずつ照らした。照らせなかった文は、引用の形にせず、要旨として書いた。攻撃の手順は、書かない。
2026年10月27日、アメリカのCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）が公開している「悪用が確認された脆弱性のカタログ」に、CVE-2026-111497が追加された。対象はGoogleのBrotliで、圧縮されたデータを元に戻す部分（デコーダー）の欠陥である。この記事は、この知らせを受けて、担当サイトの中で「圧縮を受け取って、解く側」になっている場所を数えることだけを書く。サーバーが応答を圧縮して送る側の設定は、別の話として、03章と04章で切り分ける。
Node.jsの告知が書いた、欠陥の中身
2026年10月21日のNode.jsのセキュリティリリースの告知は、この欠陥を、重大度「high」（高）として載せた。告知の最初の1文は、こうである。
"A flaw in the Brotli decoder bundled with Node.js allows malformed compressed input to write past the end of an internal decoder buffer."
（訳: Node.jsに同梱されたBrotliのデコーダーの欠陥により、壊れた圧縮データを与えると、デコーダー内部の領域の終わりを越えて書き込めてしまう。）
影響の書き方は、次の文である。
"An attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory, which can lead to a crash, disclosure of process memory, or remote code execution."
（訳: アプリケーションがnode:zlibで展開するBrotliのデータを与えられる攻撃者は、プロセスのメモリを壊すことができ、クラッシュ、プロセスのメモリの開示、遠隔からのコード実行につながりうる。）
ここで大事なのは、条件が「アプリケーションが展開するBrotliのデータを、外から与えられること」になっている点である。サーバーが自分のページをBrotliで圧縮して送ることではなく、誰かが作った圧縮データを、自分の側のプログラムが受け取って解くことが条件になる。告知は、影響を受ける版を、Node.jsの26.x、24.x、22.xと書き、修正を入れたリリースとして、v22.23.4、v24.22.1、v26.12.1を挙げた。告知は2026年10月21日の水曜日付けである。
ライブラリ本体の修正は、Brotli 1.2.1
Brotli本体のGitHubのリリースページには、v1.2.1が載っていて、「SECURITY」の欄に次の1行がある。
"CVE-2026-111497: out-of-bounds write permits remote code execution"
（訳: CVE-2026-111497: 範囲外への書き込みにより、遠隔からのコード実行が可能になる。）
リリースの日付は、ページに「21 Oct」と出ていた。つまり、Brotli 1.2.1も、Node.jsの告知も、10月21日である。オープンソースのセキュリティ情報を流すoss-securityのメーリングリストでは、10月23日にJan Schaumannという人が「問題はNode.jsだけではなく、Googleのbrotliそのものにある」という趣旨で書き、10月24日にAlan Coopersmithという人が、patchtheplanetというサイトが、Node.js、Bun、Envoy Proxy、Istioのリリースを一覧にしていること、AikidoというサイトのブログがPyPIのbrotliのパッケージを加えていること（同じ投稿が挙げたもので、Aikidoの記事の本文は、この記事では開いていない）を書いた。
PHPのWindows版も、10月26日に作り直された
php.netは、2026年10月26日付けで、「Updated PHP Windows builds for Brotli security fix」（訳: Brotliのセキュリティ修正のための、PHPのWindows版の更新ビルド）を載せた。対象はPHP 8.5.12-1、8.4.27-1、8.3.36-1、8.2.35-1である。到達する経路は、こう書かれている。
"In PHP Windows builds, the vulnerable decoder can be reached through the cURL extension when automatic HTTP response decompression is enabled."
（訳: PHPのWindows版では、HTTPの応答の自動展開が有効なとき、欠陥のあるデコーダーに、cURL拡張を通して到達しうる。）
"This is disabled by default in cURL, but applications and HTTP client libraries can enable it."
（訳: これはcURLでは既定で無効だが、アプリケーションやHTTPクライアントのライブラリは有効にできる。）
末尾の「-1」は、同じPHPのソースで、依存部品だけを更新した作り直しを示す、とも書かれている。つまり、PHPの版の番号は変わらない。この点は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録で書いた「版の表示は修正の証拠にならない」と、同じ形である。
CISAのカタログの行
CISAのカタログのデータ（JSON）で、この番号の行を読むと、追加日は2026-10-27、対応の期限は2026-11-10、製品は「Google Brotli」、弱点の種類は、CWE-252（戻り値を確かめない）とCWE-787（範囲外への書き込み）だった。「ランサムウェアの攻撃に使われたか」の欄は「Unknown」（不明）である。短い説明は、次のとおりである。
"Google Brotli contains an unchecked return value vulnerability that allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream."
（訳: Google Brotliには、戻り値を確かめない欠陥があり、認証の無い遠隔の攻撃者が、細工したBrotli圧縮のデータの流れで、隣のデコーダーの状態のメモリを壊し、重要なメモリの内容を開示させ、サービス拒否を起こし、場合によっては任意のコードを実行できる。）
注意
カタログに載ったのは「悪用が確認された」という意味で、あなたのサイトが狙われた、という意味ではない。欠陥のある部品を、外から与えられたデータに使っているかどうかで、当てはまるかが決まる。その確認が、この記事の05章である。
02 なぜ・背景 — 同じ圧縮が、「送る側」と「解く側」で別の問題になる
送る側: ページをBrotliで小さくして配る
Brotliは、データを小さくして送るための圧縮の方式の1つである。ウェブサーバーが、ページやCSSを圧縮して送ると、通信量が減る。ブラウザは、「このBrotliなら読める」と伝えるために、リクエストのヘッダー（Accept-Encoding）に方式の名前を書き、サーバーは、使った方式を応答のヘッダー（Content-Encoding）に書く。この流れで、圧縮するのはサーバー、解くのは利用者のブラウザである。今回の知らせは、この「送る側」の設定の話ではない。
解く側: 自分のプログラムが、外から来たデータを受け取って展開する
一方、サイトの裏側では、サーバー自身が「受け取る側」になる場面が多い。外のAPIから情報を取る、他のサイトのRSSやページを読む、決済や地図や翻訳のサービスへ問い合わせる、といった処理である。これらの処理で、相手が圧縮して返してきた応答を、自分のプログラムが解く。このとき解くのは、自分のサーバーの中の部品である。今回の欠陥は、この部品の側にある。
自動で展開する設定が、解く側を作る
外へつなぐ処理が、勝手に圧縮された応答を受け取るわけではない。つなぐ側が「圧縮した形で返してよい」と相手に伝え、返ってきた応答を自動で元に戻す設定にしたときに、解く側になる。cURLの公式の文書は、この設定をこう書く。
"Sets the contents of the Accept-Encoding: header sent in an HTTP request, and enables decoding of a response when a Content-Encoding: header is received."
（訳: HTTPリクエストで送るAccept-Encodingヘッダーの中身を設定し、Content-Encodingヘッダーを受け取ったときに、応答の展開を有効にする。）
同じ文書は、方式の名前を並べて指定できること、brはbrotliで、curl 7.57.0から使えること、空の文字列を渡すと、その環境のcURLが組み込んでいるすべての方式を示すヘッダーを使うこと、設定を無しにすると展開もしないことを書いている。PHPのマニュアルでは、この設定が、定数CURLOPT_ENCODING（cURL 7.21.6で非推奨）と、CURLOPT_ACCEPT_ENCODING（7.21.6から）の2つの名前で出てくる。古いコードには前者が、新しいコードには後者が書かれるので、探すときは両方を探す。
HTTPクライアントのライブラリが、設定を持っている
php.netの告知は「アプリケーションやHTTPクライアントのライブラリは有効にできる」と書いた。つまり、自分のコードに設定が無くても、使っているライブラリが、自動展開を有効にして動いていることがある。コードの検索で見つからないことと、解く側になっていないことは、同じではない。
03 用語 — 圧縮の話で出てくる言葉を、先にそろえる
用語: Brotli（ブロトリ）とデコーダー
Brotliは、Googleが公開している圧縮の方式とそのライブラリである。圧縮されたデータを元に戻す部分を、デコーダー（展開器）という。今回の欠陥は、デコーダーの側にある。
用語: Accept-EncodingとContent-Encoding
前者は、リクエストで「この圧縮の方式なら受け取れる」と伝えるヘッダー、後者は、応答で「この方式で圧縮した」と伝えるヘッダーである。cURLの文書は、前者を設定すると、応答の展開が有効になると書く。
用語: 範囲外への書き込み（out-of-bounds write）
プログラムが、用意した領域の終わりを越えて、メモリに書き込んでしまう欠陥である。CISAのカタログは、この欠陥の種類を、弱点の分類CWE-787として載せている。
用語: 同梱（バンドル）
ソフトが、必要な部品を、自分の中に抱えて配ることをいう。Node.jsは、Brotliのデコーダーを同梱している。同梱された部品は、OSの部品を更新しても、入れ替わらない。だから、同梱している側のソフトの更新が要る。
悪用が確認された脆弱性のカタログ
CISAのカタログ（Known Exploited Vulnerabilities、略称KEV）は、実際に悪用が確認された脆弱性の一覧で、各行に、追加日と、対応の期限が付く。今回の期限は2026年11月10日である。カタログの「必要な対応」の欄は、ベンダーの指示に沿って緩和策を適用すること、CISAのBOD 26-04という指針に従うこと、緩和策が無ければ製品の利用をやめることを書いている。BOD 26-04が誰に向けた指針かは、この記事では確かめていない。
04 型別 — 出典が挙げる範囲、挙げていない範囲、数え方の手順
🅰 出典が挙げる範囲は、4つの場所だった
開いた出典が挙げた、影響を受ける場所を、まとめる。
- Node.js: 26.x、24.x、22.xが対象。node:zlibでBrotliを展開するアプリケーションが条件（Node.jsの告知）
- PHPのWindows版: cURL拡張で、応答の自動展開が有効なとき（php.netの告知）。Linux版については、この告知に書かれていない
- Brotliを取り込んだ他のソフト: Bun、Envoy Proxy、Istio（oss-securityの投稿が、patchtheplanetの一覧として挙げた）、PyPIのbrotliのパッケージ（Aikidoのブログ記事が加えている、と同じ投稿が書いた。その記事の本文は、この記事では開いていない）
- Perlのモジュール: IO::Compress::Brotliの、0.004001から0.023より前の版（oss-securityに10月23日に出た、CPANのセキュリティ担当の投稿。件名のCVE-2026-115936は、Brotli本体のCVE-2026-111497とは別の番号）。本文は、下で読む
Perlの件は、投稿の本文を2026年10月28日に開いて読んだ。本文が書いているのは、次の3点である。1つ目は、対象の版が、Brotliのライブラリを自分の中に同梱して作られていて、その同梱の部品に、デコーダーの範囲外への書き込みがあること。2つ目は、0.023でその部品をBrotli 1.2.1に更新したこと。3つ目は、システムのBrotliを更新しても、これは直らないことである。
"The bundled copy, 1.0.4 through 1.2.0 across the range, carries the decoder out-of-bounds write described in CVE-2026-111497. Version 0.023 updates it to brotli 1.2.1."
（訳: 同梱された部品は、対象の版の全体を通して1.0.4から1.2.0で、CVE-2026-111497に書かれたデコーダーの範囲外への書き込みを抱えている。0.023は、これをBrotli 1.2.1に更新する。）
"Upgrading the system brotli does not remediate this."
（訳: システムのbrotliを更新しても、これは直らない。）
同じ投稿は、直し方を「IO-Compress-Brotli 0.023以上へ上げる」と書き、信頼できないデータをunbroメソッドやdecompressメソッドで展開する呼び出しが、同梱のデコーダーに届く、とも書いている。つまり、Node.jsと同じく、同梱している側のモジュールの更新が要る。一方、投稿が書いていないこと（0.004001より前の版や、ほかのPerlのモジュールの扱い）は、この記事も書かない。
🅰 出典に書かれていない範囲
次のものが影響を受けるかは、開いた出典のどれにも書かれていなかった。書かれていないことは、「影響が無い」という意味ではない。
- ApacheやnginxのBrotliのモジュール
- Linuxの配布元（ディストリビューション）の、Brotliのパッケージが、いつ修正されたか
- PHPのLinux版、ホスティング事業者が用意したPHP
- WordPressやその他のCMS、ECのパッケージ
この記事は、これらについて、影響の有無を言い切らない。確かめる方法は、04章の🅲と05章に書く。
実務のヒント
「書かれていない」と「無い」を分けて、台帳に書く。台帳の「影響」の欄は、「あり」「なし」だけでなく、「出典に記載なし。事業者に確認中」を作っておくと、あとで見返すときに、確かめた範囲が分かる。
🅱 公開された情報が測っていないこと
- どの環境で、欠陥に実際に到達できるか。告知は、到達しうる条件を書くが、あなたの環境で到達できるかは、書かない
- 修正の入っていない版が、どれだけ使われているか
- カタログに載った悪用が、どのソフトに向けられたか。カタログの行は、製品を「Google Brotli」とだけ書く
- 攻撃を受けた痕跡の見つけ方。この記事は、痕跡の調べ方を書かない
🅲 数え方の手順 — 台帳の「場所」の列を作る
手順は4つの段に分ける。
- 場所を列挙する: 担当サイトが、外のサービスから応答を受け取る処理を、洗い出す。外のAPI、RSSの取得、画像や文書を取りに行く処理、決済や翻訳や地図の呼び出し、などである
- 展開の有無を見分ける: それぞれの処理が、圧縮された応答を自動で展開する設定になっているか、コードの検索と、使っているライブラリの文書で確かめる
- 部品の持ち主を見分ける: 展開する部品が、OSのものか、言語の実行環境（Node.jsなど）に同梱されたものか、言語のパッケージが自前で持つものかを、書き分ける
- 直す手段を見分ける: OSのパッケージなら配布元の更新、実行環境なら実行環境の更新、言語のパッケージならパッケージの更新、と手段が違う。持ち主ごとに担当者を決める
版の番号だけで終わらせない
修正が入ったかを、版の表示だけで判断しないことは、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。Node.jsのように、修正版に新しい版の番号が付くものは、番号が確かめの入口になる。ただし、PHPのWindows版の「-1」のように、版の番号が変わらず、中身だけが替わるものがある。OSのパッケージは、配布元が修正を取り込むと、版の番号ではなく、改訂番号が上がる。確かめるときは、パッケージの変更履歴に、CVEの番号が出るかを見る。
05 明日、自社のサイトで確認できることチェックリスト
以下は、担当サイトで、Brotliの欠陥に関わる「解く側」を数える13項目である。1〜3番目はNode.js、4〜6番目は外へつなぐコードと自動展開、7〜9番目はPHPのWindows版・Python・Perl、10番目は「送る側」の切り分け、11〜13番目は事業者への確認・期限・記録である。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。
- 使っているソフトの台帳を開き、Node.jsを使う箇所（画面の組み立て・API・ビルド）を行ごとに数えて、箇所の数を書く
- 数えた箇所のNode.jsの版を書き出し、10月21日の告知の版と、系統ごとに比べる（22系は22.23.4、24系は24.22.1、26系は26.12.1）。同じ系統で、その版より小さいものに印を付ける
- OSのパッケージでNode.jsを入れている箇所があれば、パッケージの変更履歴を開き、CVE-2026-111497が出るかを見る
- コードの置き場全体を、CURLOPT_ENCODINGとCURLOPT_ACCEPT_ENCODINGの2つの名前で検索し、ヒットしたファイルの数を、検索した範囲と一緒に書く
- ヒットした設定値を1つ開き、空の文字列か、方式を名指ししたものか、brを含むものかを見分けて、台帳に書く
- 依存の一覧（composer.jsonやpackage.json）を開き、外へつなぐライブラリの名前を3つ以上書き出し、それぞれの文書で、応答の自動展開の項目を探す
- PHPをWindowsで動かす機械（開発機・検証機・社内ツール）が何台あるかを担当者に聞いて数え、あれば、ファイル名に「-1」が付いた版へ入れ替えたかを記録で確かめる
- Pythonで動かす処理があれば、パッケージの一覧にbrotliの名前があるかを、一覧コマンドで1回確かめる
- Perlで動かす処理があれば、IO::Compress::Brotliの版が0.023以上かを、モジュールの一覧で確かめる
- 自分のページを取得するコマンドにAccept-Encodingでbrを付け、応答のContent-Encodingの有無を見て、「送る側」の確認として別の欄に書く
- ホスティング事業者と制作会社に、「Brotliの件で、御社が管理する範囲に影響があるか」「修正をどの形で入れるか」「いつまでに」の3つを、文章で送る
- 社内の対応の期限を、CISAのカタログの期限である2026年11月10日を目安に書き、箇所ごとに担当者の名前を入れる
- 確認した箇所を、場所・展開の有無・部品の持ち主・修正の確認方法・確認した日の5列の表にして残す
実際のコマンドを2つだけ示す。コードの検索は、次の形になる（置き場の場所に合わせて変える）。
grep -rlE "CURLOPT_(ACCEPT_)?ENCODING" --include=*.php 置き場の場所送る側の確認は、次の形である（自分のページのアドレスに変える）。
curl -s -H "Accept-Encoding: br" -D - -o /dev/null https://example.com/後者の結果にContent-Encodingがbrと出ても、それはサーバーが圧縮して送っていることを示すだけで、解く側の確認ではない。
06 代替・他の選択肢 — 直す手段は、部品の持ち主で決まる
手段の比較
| 部品の持ち主 | 直し方 | 確かめ方・注意 |
|---|---|---|
| Node.js | 告知にある修正版（22.23.4・24.22.1・26.12.1）へ更新する | 同梱の部品なので、OSのBrotliを更新しても入れ替わらない。更新後に、実行環境が新しい版で動き直したかを見る |
| PHPのWindows版 | 「-1」が付いた作り直しのビルドへ入れ替える | PHPの版の番号は変わらない。配布元のファイル名と日付で確かめる |
| 言語のパッケージ | パッケージを更新する。自前の部品を持つものは、パッケージ側の修正を待つ | OSの部品を更新しても直らないことがある。パッケージの更新の記録を見る |
| OSのパッケージ | 配布元が出す更新を入れる | 版の番号ではなく、変更履歴にCVEの番号が出るかを見る。出典に、配布元ごとの状況は書かれていない |
| 自動展開の設定 | 必要な方式だけを名指しし、brを外す | 応答を圧縮して返さない相手なら影響は小さいが、設定の変更は動作確認とセットにする |
担当サイトの種類ごとの、当てはまり方
次の表は、担当サイトの作り方ごとに、どこを先に見るかを筆者が整理したものである。公式の告知が、こう分けたわけではない。
| サイトの種類 | 当てはまりうる所 | 最初に確かめること |
|---|---|---|
| Node.jsで作るサイト | 画面の組み立てやAPIをNode.jsで動かし、外から来たBrotliのデータをnode:zlibで展開する処理があるとき（Node.jsの告知） | Node.jsの版を、系統ごとの修正版と比べる（05章の1〜3番目） |
| PHPで外のAPIにつなぐサイト | WindowsのPHPで、cURLの応答の自動展開が有効なとき（php.netの告知）。LinuxのPHPは、告知に書かれていない | 自動展開の設定を2つの名前で検索する（05章の4〜6番目）。Windowsの機械があれば、「-1」の版かを確かめる（7番目） |
| 静的サイト（HTMLやCSSを置いて配るだけ） | 自分のプログラムで外の応答を解く処理が無ければ、「解く側」は無い。配信の圧縮は別の話 | 外へつなぐ処理が本当に無いかを、台帳の「場所」の列で確かめる。サーバーの部品は事業者に聞く（11番目） |
一時的な手として、自動展開の範囲を絞る
cURLの文書は、方式を名指しできると書く。外のサービスが、gzipで返せば足りるなら、「gzip, deflate」に絞り、brを受け取る入口を閉じることが、一時的な手になりうる。ただし、これは筆者の整理で、公式の告知が勧めた手ではない。告知が勧めるのは、修正版への更新である。絞るときは、相手のサービスがgzipだけで返せるかを、動作確認で確かめてから変える。
更新を試験環境で先に試す
実行環境の更新は、画面が崩れていないかを、複数ページで確かめる。試験環境と本番を、ページごとに比べるなら、🔧 WEBサイトの状況チェック・比較ツール（試験用のサイトと本番の違いをページごとに比べる・会員限定）が使える。外から見える範囲の点検には、🔧 WEBサイトの外からできるセキュリティ対策監査ツール（会員限定）があるが、これは外から見える範囲の点検で、サーバーの内側で解く側になっている部品は、見えない。
配信の圧縮を止める必要は、出典に書かれていない
サーバーがBrotliで応答を配る設定を、止めるべきだとは、開いた出典のどれにも書かれていない。止めたくなったときは、先に、そのモジュールが今回の欠陥の対象かを、モジュールの提供元に確かめる。確かめる前に止めても、解く側の部品は直らない。
07 当サイトで確かめたこと — 自前のコードを検索した結果と、確かめていないこと
2026年10月28日に、当サイトの試験環境の、自前のPHPのコードを、05章の4番目の形で検索した。数えた範囲は、アプリケーションとテーマのPHPのファイル2,514本（外部のライブラリを置く場所を除く）で、そのうち、外へつなぐ設定を書いたファイルは10本、応答の自動展開の設定を書いたファイルは0本だった。
数えた範囲の外の自前のコードで1か所見つけ、同じ日に絞った（2026年10月28日）
この記事を公開する前の確かめで、上の数えた範囲の外にある自前のコードに、応答の自動展開をすべての方式で受け付ける設定が1か所あった。06章に書いた方法（方式を名指しして、Brotliを外す）で、同じ日に、試験環境と本番の両方を直した。変えたのはその設定の1行だけで、直した後にページの表示が変わっていないことを確かめた。
当サイトで確かめていないこと
- 外から与えられたデータを、Node.jsで展開する処理が、あるかどうか
- PythonやPerlのBrotliのパッケージが、当サイトの処理に入っているか
- 外部のライブラリを置く場所にも、応答の自動展開の設定を書いたファイルがあるが、当サイトの処理から使われているかは確かめていない
- サーバーの部品の修正の有無は、この記事では扱わない
08 このテーマは、ここまで
修正が入ったかの確かめ方と、外へつなぐ通信の棚卸しは、これまでにも書いてきた。
版の表示は、修正の証拠にならなかった
PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったことと、修正で増えた設定の値で確かめる方法を書いた。Brotliの件も、PHPのWindows版の「-1」のように、番号が同じで中身が替わる形がある。
外から取った画面は、目当ての画面とは限らない
外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけたは、遮断の画面を404と読んだ失敗の記録である。05章の10番目のように外から応答を取るときも、取った画面の題名を先に見て、目当ての画面かを確かめる。
外へつなぐ通信の先は、一覧にする
認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録は、サーバーの中から外へつなぐ通信が、漏れた証明書を通していたことを、測り直して塞いだ記録である。外へつなぐ先を一覧にして、定期的に発行元を見る手は、今回の「解く側」を数える手と同じ土台に乗る。
PHPの重大な脆弱性の、更新の順番
PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録は、PHPの重大な脆弱性で、自分のサイトが関係するかを確かめる順番と、更新の後に確かめることを書いた。担当サイトの一覧に「どの部品を、誰が更新するか」を書く考え方は、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）でも扱った。
サーバーのソフトの更新を、確かめる仕組み
記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.***を、記事を公開したその日に上げるまでは、記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった、という記録である。PHP公式は、次の通常のリリースまで、セッションのアップロード進捗を0にするよう勧めた ── 設定の値・切り替えるコード・修正版に上げたあとの戻りを確かめる13項目（2026年10月時点）は、PHPの設定の値を確かめる13項目で、「値で確かめる」考え方は、今回も同じである。
2026年10月28日 — この記事の確認日
この記事の内容は、2026年10月28日に、Node.jsの告知、php.netの告知、oss-securityの3つの投稿（10月23日のPerlの件を含む）、BrotliのGitHubのリリースページ、cURLとPHPのマニュアル、CISAのカタログのデータを開いて確かめた時点のものである。配布元のパッケージの修正や、事業者の案内が出たときは、日付つきで追記する。
現在の貴方のIPアドレス
このサイトで書いている人
