Apache HTTP Server 2.4.69が10月1日に出た。セキュリティの修正は20件で、重大度は「中」5件・「低」15件 ── 自社のサーバーの版と、使っている機能が当たるかを確かめる14項目（2026年10月時点）

目次

1. 01 何が起きたか — Apache HTTP Server 2.4.69が2026年10月1日に出た。セキュリティの修正は20件ある
   1. 公式の発表文に書かれていること
   2. 変更点の一覧に、セキュリティの修正が20件ある
   3. 20件を、機能ごとに並べる
2. 02 なぜ・背景 — 版の数字だけでは、修正が入っているかどうかは決まらない
   1. OSの提供元は、版を上げずに、修正だけを古い版に入れることがある
   2. 2.2系は、もう更新されない
   3. 20件は、一度に出た
3. 03 用語 — 読み違えやすい言葉を先にそろえる
   1. CVE番号と、重大度の評価
   2. モジュール
   3. Server見出しと、ServerTokens
4. 04 型別 — 自分のサーバーの版を確かめ、使っている機能を20件と突き合わせる
   1. 適用範囲 — 20件は、機能を使っているときに当たるものが多い
   2. 公式文書が書いていないこと
   3. この記事が確かめていないこと
   4. 手順1 — サーバーの中で、版を確かめる
   5. 手順2 — 外から応答を取って、Server見出しを見る
   6. 手順3 — 読み込まれているモジュールの一覧を出す
   7. 手順4 — 設定ファイルで、条件に当たる指定を探す
   8. 手順5 — OSのパッケージで入れた場合は、更新履歴でCVE番号を探す
   9. 手順6 — サーバーに入れない人は、サーバー会社と制作会社に聞く
   10. 手順7 — 記録を残し、次の確認の日を決める
5. 05 自分のサイトで確認するチェックリスト
   1. チェックリストの使い方
6. 06 代替・他の選択肢 — 確かめ方の違いと、更新するときに先に決めること
   1. 確かめ方4つの比較
   2. 更新するときに、先に決めておくこと
   3. すぐに更新できないとき
   4. 外から見える範囲を、まとめて見るためのツール
7. 07 当サイトで確かめたこと
   1. 当サイトの応答に、版の数字は出ていない
   2. 手順1と手順3は、当サイトの運営環境で実行した
   3. この結果から言えることと、言えないこと
8. 08 このテーマの、これまで
   1. セキュリティの修正が載っている、直近6つの版の件数
   2. 当サイトの、関連する過去の記事
9. 09 この記事のまとめ

01 何が起きたか — Apache HTTP Server 2.4.69が2026年10月1日に出た。セキュリティの修正は20件ある

公式の発表文に書かれていること

Apache HTTP Serverの公式の発表文（Announcement2.4.txt）を、2026年10月7日に開いた。冒頭に「Apache HTTP Server 2.4.69 Released」とあり、日付は「October 01, 2026」と書かれている。発表文は、この版の性格を次のように書いている。

"This release of Apache is a security, feature and bug fix release."

（訳: このApacheのリリースは、セキュリティ・機能・不具合修正のリリースである。）

発表文は続けて、更新を勧めている。

"We consider this release to be the best version of Apache available, and encourage users of all prior versions to upgrade."

（訳: 私たちはこのリリースを、利用できるApacheの中で最良の版だと考えており、以前のすべての版の利用者に、更新を勧める。）

変更点の一覧に、セキュリティの修正が20件ある

公式の変更点の一覧（CHANGES_2.4）の「Changes with Apache 2.4.69」の節を、1項目ずつ数えた。項目は全部で34あり、そのうち「SECURITY: CVE-」で始まるものが20件だった。残りの14項目は、ドキュメントの修正、mod_sslの互換性の修正、mod_mdの既定値の変更、HTTP/2の応答の扱いの修正、テストの枠組みの追加などである。

20件には、1件ずつCVE番号が付いている。Apacheのセキュリティのページは、CVE番号ごとに、重大度・影響を受ける版・修正された日を載せている。重大度は、「moderate（中程度）」が5件、「low（低）」が15件で、「important（重要）」と「critical（致命的）」は0件だった。このページは、評価について次のように断っている。

"Each vulnerability is given a security impact rating by the Apache security team - please note that this rating may well vary from platform to platform."

（訳: 個々の脆弱性には、Apacheのセキュリティチームが、影響の大きさの評価を付けている。この評価は、プラットフォームによって変わりうる点に注意してほしい。）

20件を、機能ごとに並べる

次の表は、変更点の一覧とセキュリティのページの文面を、機能（モジュール）ごとに並べ直したものである。説明の要約には、公式の文面にある、影響が出る条件も入れた。重大度は、Apacheのセキュリティチームの評価である。

機能	CVE番号	公式の説明の要約（条件を含む）	重大度
mod_dav_fs	CVE-2026-93546	書き込み権限のある認証済みのWebDAVクライアントが、PROPPATCHで多数のXML名前空間を宣言し、プロセスを落とす	中
mod_vhost_alias	CVE-2026-63292	Hostヘッダーが8192バイト超で、VirtualDocumentRootがホスト名の書式を使い、LimitRequestFieldSizeを既定より上げている場合に、サービス拒否や任意のコード実行の可能性	中
本体（Windows）	CVE-2026-59685	Windowsで、展開すると長くなる8.3形式の名前を含むパスの処理での、範囲外への書き込み	中
mod_http2	CVE-2026-57941	共有バッファの再入で起きる、解放後のメモリの使用	中
mod_dav	CVE-2026-42528	WebDAVのロックを作れる攻撃者が、メモリ計算の不具合で、子プロセスを落とせる	中
mod_userdir	CVE-2026-79768	UserDirにワイルドカードなしの絶対パスを指定している場合の、「/./」による情報の漏えい	低
mod_auth_digest	CVE-2026-73637	AuthDigestNcCheckが有効、またはAuthDigestNonceLifetimeが0のとき、認証前のクライアントが認証の状態を壊せる	低
mod_auth_digest	CVE-2026-73636	AuthDigestNonceLifetimeが0のとき、中間者が、取得済みの認証情報を再送して通せる	低
mod_auth_digest	CVE-2026-48005	AuthDigestNcCheckつきのDigest認証で、偽のヘッダーによる再認証の強制（サービス拒否）	低
mod_proxy_uwsgi	CVE-2026-63718	細工したuwsgiの応答とTransfer-Encodingによる、応答のスマグリング（2.4.30から）	低
mod_xml2enc	CVE-2026-63686	信頼できないバックエンドの応答の文字コード変換が途中で失敗すると、NULLポインタ参照でサービス拒否	低
mod_proxy_ftp	CVE-2026-63045	フォワードプロキシの構成で、信頼できないFTPサーバーが、PASV応答で第三者のホストへの接続を開かせる	低
mod_ssl	CVE-2026-59797	SSLRequireとファイル関連の式の組み合わせで、.htaccessから権限の不適切な管理が起きる	低
mod_dav_fs	CVE-2026-58415	GETで.DAVの状態ディレクトリを読み、書き込み権限のないリソースのプロパティを読める	低
mod_proxy_html	CVE-2026-56449	細工した応答の本文による、範囲外への書き込み	低
mod_rewrite	CVE-2026-56154	先読み（%{LA-U:HTTP:...}）を使うときの、解放後のメモリの使用	低
mod_charset_lite	CVE-2026-56153	ヒープの範囲外への書き込み	低
mod_session	CVE-2026-47360	SessionCookieRemoveが内部リダイレクトをまたいで変わると、セッションのクッキーがバックエンドに渡る場合がある	低
mod_heartmonitor	CVE-2026-46729	ユニキャストのリスナーでの、NULLポインタ参照によるサービス拒否	低
本体（CGI）	CVE-2026-42356	CGIからの一部の内部リダイレクトで、移動先もCGIとして実行される。移動先がCGI有効のディレクトリにあり、mod_mimeが解釈する他の拡張子を持たない場合（2.4.60から）	低

影響を受ける版は、多くの項目で「2.4.0から2.4.68まで」と書かれている。さらに、公式の2つの文書で、書き方が食い違う項目が2つある。mod_davのロックの項目は、説明文が「2.4.67以前」、セキュリティのページの欄が「2.4.68まで」と書く。mod_proxy_htmlの項目は、変更点の一覧が「2.4.0から2.4.68」、セキュリティのページが「2.4.68」だけを書く。どちらが正しいかは、書かれていない。2.4.68を使っている場合は、どちらの書き方でも当たる。それ以前の版の場合は、この2項目を、当たるものとして扱うほうが安全側だというのが、この記事の判断である。

02 なぜ・背景 — 版の数字だけでは、修正が入っているかどうかは決まらない

OSの提供元は、版を上げずに、修正だけを古い版に入れることがある

「2.4.69に上げれば20件とも直る」というのは、Apache公式の版の話である。実際のサーバーは、OSの提供元が配るパッケージで入れていることが多く、その場合は事情が変わる。Red Hatは、修正を古い版に入れる作業を、バックポートと呼んで、次のように説明している。

"Customers need to be aware that just looking at the version number of a package will not tell them if they are vulnerable or not."

（訳: 顧客は、パッケージの版の数字を見ただけでは、脆弱かどうかは分からないことを、知っておく必要がある。）

Debianのセキュリティに関するよくある質問にも、同じ考え方が書かれている。

"Instead of upgrading to a new release we backport security fixes to the version that was shipped in the stable release."

（訳: 新しいリリースに更新する代わりに、私たちは、安定版で配った版に、セキュリティの修正をバックポートする。）

この2社の説明から読み取れるのは、パッケージで入れたApacheは、版の数字が2.4.68のままでも、修正が入っている場合がある、ということである。逆に、自分でソースから入れた場合は、版の数字を公式の一覧と直接つき合わせられる、というのが筆者の読みである（この点の記載は、公式文書には確認できなかった）。

2.2系は、もう更新されない

"Please note the 2.2.x branch has now passed the end of life at the Apache HTTP Server project and no further activity will occur including security patches."

（訳: 2.2.xの系統は、Apache HTTP Serverプロジェクトでの提供の終了を過ぎており、セキュリティの修正を含め、今後の作業は行われないことに注意してほしい。）

これは発表文の注意書きである。2.2系を使っているサーバーには、今回の20件の修正は届かない。20件との突き合わせより先に、2.4系への移行の相談が要る。

20件は、一度に出た

セキュリティのページには、項目ごとに「Reported to security team」（訳: セキュリティチームへ報告された日）の日付が載っている。最も早く報告されたのはCGIの項目で2026年4月3日、最も遅いのはmod_userdirの項目で8月14日である。報告から2.4.69の公開（10月1日）までは、181日から48日の幅になる。前の版2.4.68は6月8日に出ているので、2.4.69との間は115日である。「更新の連絡が来る回数」は減っても、「1回に直る件数」は増える、という形である。

03 用語 — 読み違えやすい言葉を先にそろえる

CVE番号と、重大度の評価

モジュール

Server見出しと、ServerTokens

04 型別 — 自分のサーバーの版を確かめ、使っている機能を20件と突き合わせる

適用範囲 — 20件は、機能を使っているときに当たるものが多い

表の20件は、5つにまとめられる。どれを使っているかは、サイトごとに違う。

• WebDAVに関わる3件：mod_dav_fsが2件、mod_davが1件。
• Digest認証に関わる3件：mod_auth_digestの3件。Basic認証だけなら、関係しないと読める。
• 他のサーバーへの中継に関わる4件：mod_proxy_uwsgi・mod_xml2enc・mod_proxy_ftp・mod_proxy_html。
• 設定の指定が条件になっている8件：mod_userdir・mod_vhost_alias・mod_ssl・mod_rewrite・mod_charset_lite・mod_session・mod_heartmonitor・CGI。
• HTTP/2とWindows版の2件。

どの機能も使っていないサイトでは、当たる項目が少ない可能性がある。ただし、「少ない可能性がある」と「0件だと確かめた」は違う。

公式文書が書いていないこと

次のことは、確かめた範囲の公式文書に書かれていない。この記事も、断定しない。

• 20件が実際に悪用されたかどうか。変更点の一覧とセキュリティのページの2.4.69の部分を、「exploit」「in the wild」「actively」の3つの語で調べたところ、どれも0件だった。
• 更新できないときの回避策。「workaround」「mitigat」の2つの語は、同じ範囲で0件だった。
• OSの各提供元が、20件の修正を取り込む時点。

この記事が確かめていないこと

読者の環境で、20件のどれに当たるかは、この記事では確かめていない。設定は、読者の環境にしかないためである。

手順1 — サーバーの中で、版を確かめる

サーバーに入れる権限があるなら、確実なのは、サーバーの中でコマンドを実行することである。公式の説明では、httpdの「-v」は、版を表示して終わる。apachectlは、httpdの引数をそのまま渡せる。

httpd -v
apachectl -v

出力の先頭の「Server version: Apache/2.4.数字」の行の数字を、記録に写す。コマンドの名前や置き場所は、環境によって違う。公式の説明も、標準でない場所に入れた場合は、apachectlの中のhttpdの場所を書き換える必要がある、と書いている。見つからなければ、管理者に聞く。

手順2 — 外から応答を取って、Server見出しを見る

サーバーに入れない場合は、公開しているURLに、外から問い合わせて、応答の見出しだけを見る方法がある。

curl -I https://自社のドメイン/

出力の「Server:」の行を探す。ServerTokensが既定のFullなら、版の数字が出る。Prodなら「Apache」だけで、外からは版が読めない。外から版が読めないことは、悪い状態ではない。ただし、版が読めても読めなくても、修正が入っているかどうかは、この行からは分からない。パッケージで修正を取り込んだ場合、数字は古いままのためである。

外から取った画面は、目当ての画面とは限らない。題名や本文を先に見て、自社のサーバーの応答かを確かめる。この注意は、当サイトの記事「外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた」に書いた。

手順3 — 読み込まれているモジュールの一覧を出す

次に、動いている機能を確かめる。公式の説明では、「-M」は、読み込まれている静的・共有のモジュールを一覧にする。「-l」は、組み込まれたモジュールだけで、LoadModuleで後から読み込むものは出ない。20件の突き合わせには、-Mを使う。

httpd -M | grep -E "dav|userdir|auth_digest|vhost_alias|proxy|xml2enc|ssl|http2|rewrite|session|charset_lite|heartmonitor|cgi"

出た行から、表のどの機能が「ある」か「ない」かを、機能ごとに書く。「ない」機能の項目は、当たらないと読める。ただし、本体の項目（CGI・Windows）は、一覧とは別に確かめる。

手順4 — 設定ファイルで、条件に当たる指定を探す

モジュールが「ある」だけでは、当たるとは限らない。表の条件に合う設定が書かれているかを、設定ファイルで探す。公式の説明では、設定ファイルの既定はconf/httpd.confで、-fで変えられる。場所は、管理者に確かめる。

grep -rEn "UserDir|AuthDigestNcCheck|AuthDigestNonceLifetime|VirtualDocumentRoot|LimitRequestFieldSize|SSLRequire|SessionCookieRemove|LA-U" 設定ファイルのあるフォルダ

見つかった行を、表の条件と照らす。たとえば、AuthDigestNonceLifetimeに0が書かれていれば、CVE-2026-73637と73636の条件に合う。公式文書の既定値は300秒である。

.htaccessも探す。公式の説明では、.htaccessに何を書けるかはAllowOverrideで決まり、その既定値はNoneである。SSLRequireを書いた.htaccessは、公開フォルダ全体を探して確かめる。

手順5 — OSのパッケージで入れた場合は、更新履歴でCVE番号を探す

パッケージで入れた場合は、更新履歴（changelog）に、表のCVE番号が書かれているかを探す。Debianは、パッケージのchangelogを見るか、正確な版の数字をセキュリティ情報の版と照らすことで、安全な版かを確かめられる、と説明している。

rpm -q --changelog httpd | grep -c "CVE-2026-42356"

上のコマンドは、RPM系のOSでの一般的な例で、この記事では出力を確かめていない。表の20件を1件ずつ検索し、見つかった件数を数える。20件とも見つかれば、取り込み済みと読める。見つからない番号は、提供元に聞く。

手順6 — サーバーに入れない人は、サーバー会社と制作会社に聞く

借りているサーバーや、制作会社の管理のサーバーには、次の文面で問い合わせる。

2026年10月1日に公開されたApache HTTP Server 2.4.69で、
セキュリティの修正が20件ありました。
1. 当社のサーバーで動いているApacheの版を教えてください。
2. その版は、20件の修正（CVE番号の一覧を添付します）を
   取り込んでいますか。未取り込みなら、更新の予定日を教えてください。
3. WebDAV・UserDir・Digest認証・プロキシ（他のサーバーへの中継）を、
   当社のサーバーで使っていますか。

返事は、日付と要点を、1行ずつ記録する。

手順7 — 記録を残し、次の確認の日を決める

手順1〜6で分かったことを、日付つきで1つの記録にまとめる。月に1回、公式の発表文・変更点の一覧・セキュリティのページを開く日を、カレンダーに入れておく。

05 自分のサイトで確認するチェックリスト

下の14項目は、1項目5分ほどでできる作業である。項目1・3・4・5・6・13は、サーバーに入れる人向け、項目7〜9は、入れない人向け、項目2・10・11・12・14は、どちらにも当てはまる。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。

• サーバーの中で「httpd -v」を実行し、「Server version」の行の版の数字を、記録に1行で書き写す
• 書き写した版の数字が「2.4.69」か「2.4.68以前」かを、公式の発表（2026年10月1日）と見比べて、記録に書く
• 「httpd -M」を実行し、出てきた行の数を数えて、記録に書く
• モジュールの一覧に、表の機能（mod_dav・mod_userdir・mod_auth_digest・mod_ssl・mod_http2・mod_rewrite・mod_vhost_alias）が入っているかを、機能ごとに「ある」か「ない」で書く
• 「ある」機能について、設定ファイルをUserDir・AuthDigestNonceLifetime・VirtualDocumentRoot・SSLRequireの4つの語で探し、見つかった行の数を、語ごとに書く
• OSのパッケージで入れている場合は、更新履歴を、表のCVE番号3件で検索し、書かれていた件数を「3件中◯件」と書く
• サーバーを借りている会社の管理画面を開き、Apacheの版を表示する画面か案内のページがあるかを確かめ、あれば版を記録に写す
• 手順6の3つの問い合わせを、サーバー会社か制作会社の窓口に送り、送った日を記録に書く
• 返事が来た相手を、「取り込み済み」「未取り込み」「返事待ち」の3つに分けて、数を数える
• 外のパソコンで「curl -I https://自社のドメイン/」を実行し、「Server:」の行に版の数字が出るかを、「出る」か「出ない」で書く
• Server見出しに版の数字が出る場合は、管理者に、ServerTokensをProdにできるかを聞く文を、2行で書いて送る
• 項目1〜9で版が2.4.68以前と分かった場合は、更新を行う日・担当者・元に戻す手順の有無を、1行で書き出す
• 公式の変更点にある既定値の変更（mod_mdのMDServerStatus、mod_auth_digestのRFC 2069の扱い）が、自社の設定に関わるかを、設定ファイルの検索で「関わる」か「関わらない」で書く
• 公式の発表文・変更点の一覧・セキュリティのページを開く日を、毎月1回、カレンダーに登録し、登録した日付を記録に書く

チェックリストの使い方

時間が限られているときは、項目1・2・4・8の4つだけでも、「版が何か」「何の機能が動いているか」「聞くべき相手に聞いたか」が分かる。サーバーに入れない場合は、項目7・8・10の3つから始める。

06 代替・他の選択肢 — 確かめ方の違いと、更新するときに先に決めること

確かめ方4つの比較

方法	必要な権限	分かること	分からないこと
サーバーの中で版とモジュールを見る	サーバーに入る権限	版の数字と、読み込まれている機能	パッケージで修正が取り込まれたか
外からServer見出しを見る	要らない	ServerTokensが許す範囲の表示	版が隠されていれば何も。修正の有無は、いずれの場合も
パッケージの更新履歴を探す	サーバーに入る権限	CVE番号ごとの取り込み	パッケージの外で入れた部分
サーバー会社・制作会社に聞く	要らない	相手が確かめた、環境全体の状態	返事までの日数と、返事の正確さ

更新するときに、先に決めておくこと

更新する前に、更新する日・元に戻す手順・更新のあとに見る画面の3つを決める。公式の変更点には、更新で動作が変わる項目もある。mod_mdについて、変更点は次のように書いている。

"mod_md: MDServerStatus is now disabled by default."

（訳: mod_md: MDServerStatusは、既定で無効になった。）

mod_mdの公式文書は、この指定を、Managed Domain情報をserver-statusに加えるかを決めるものと説明し、既定値が2.4.69で「off」に変わったと書いている。表示を見ていた場合は、更新のあとに出なくなる可能性がある。また、mod_auth_digestの項目には「Drop RFC 2069 support; rewrite shared memory handling and client nonce handling」（訳: RFC 2069のサポートを外し、共有メモリの扱いとクライアントのnonceの扱いを書き直した）とある。Digest認証を使っているサイトは、更新のあとに、実際にログインできるかを確かめる。

すぐに更新できないとき

確かめた範囲の公式文書には、回避策の記載が見つからなかった。更新できない事情があるなら、表の条件から、自社が当たる項目の数を数え、あれば更新の日を先に決める。0件なら、優先度は下げられる。

外から見える範囲を、まとめて見るためのツール

外から見える情報を一度に確認したいときは、当サイトの無料ツール🔧 WEBサイトの外からできるセキュリティ対策監査ツールが使える（会員限定・無料登録）。説明には、DNSの記録、SSL/TLSの分析、CMS・フレームワーク・CDN・WAFの検出などが挙がっているが、Apacheの版を判定する項目は挙がっていない。公開ページのHTTPS対応やセキュリティヘッダーは、🔧 WEBサイト総合分析・レポートツールで見られる。どちらも、20件に当たるかを判定するツールではない。

CMSの更新を一覧にする方法は、当サイトの記事「WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点）」で扱った。

07 当サイトで確かめたこと

当サイトの応答に、版の数字は出ていない

当サイトもApacheで動いている。2026年10月7日に、手順2の方法で、トップページの応答の見出しを取った。「Server:」の行は「Apache」だけで、版の数字も、モジュールの名前も、OSの種類も含まれていなかった。公式文書が、ServerTokensのProdについて書く形と同じである。外から版を読む手がかりは、この行にはない。

手順1と手順3は、当サイトの運営環境で実行した

同じ日に、手順1と手順3を、当サイトの運営環境で実行した。コマンドは2本で、どちらも数秒で結果が出た。版の数字と、モジュールの一覧の中身は、この記事には書かない。版と機能の組み合わせは、20件のどれに当たるかを、外の人が数える材料になるためである。設定ファイルの中身も、同じ理由で書かない。結果と対応の日は、社内の記録にだけ残す。

この結果から言えることと、言えないこと

言えるのは、外から見える範囲では、当サイトの版は読み取れないことである。言えないのは、外から読めないことが、修正が入っている証明になるかどうかである。この2つは、別の話である。14項目のうち、サーバーに入る権限が要らないのは、項目2・7〜12・14の8項目である。サーバーに入れない人でも、確認の約6割は進められる。

08 このテーマの、これまで

セキュリティの修正が載っている、直近6つの版の件数

Apacheのセキュリティのページは、版ごとに「Fixed in Apache HTTP Server 2.4.69」のような見出しの下に、修正された項目を並べている。直近の6つについて、見出しごとの項目数と公開日を、次の表にまとめた（2026年10月7日に数えた。見出しが無い2.4.63は含めていない）。

版	公開日	修正の件数	評価の内訳
2.4.64	2025年7月10日	8件	中5件・低3件
2.4.65	2025年7月23日	1件	中1件
2.4.66	2025年12月4日	5件	中3件・低2件
2.4.67	2026年5月4日	11件	重要1件・中2件・低8件
2.4.68	2026年6月8日	13件	中6件・低7件
2.4.69	2026年10月1日	20件	中5件・低15件

この6つの中では、2.4.69の20件が最も多い。2.4.67・2.4.68・2.4.69では、11件・13件・20件と増えている。ただし、件数の増加が危険の増加を意味するかは、公式文書に書かれていない。件数は、悪用された数ではない。

当サイトの、関連する過去の記事

• 毎朝の「警告1,415件」を、初めて種類別に数えた ── 96.7%は見なくていいもので、唯一の「本物」は自分で叩くまで分からなかった — 警告の件数を種類別に割った記録。20件を自社に当てはめる数え方と、同じ形である。
• 警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった — 数えた件数のうち、本物が少数だった話。
• 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった — 記事に書いたチェック項目を、自分のサイトに当てた記録。
• 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面が、目当ての画面とは限らなかった話。
• AIエージェントのコードに脆弱性が見つかった日 ── 発見と修正の記録 — 脆弱性が見つかった日の、発見と修正の記録。