WEBサイト
10月7日、Apache HTTP Server 2.4.69の解説記事を公開した。10月1日に出たこの版には、セキュリティの修正が20件入っている。記事は、読者が自分のサーバーの版を確かめられるように、14項目のチェック項目にした。書く途中で、チェック項目の1つ目（版を見る）を当サイトのサーバーに当ててみたら、2.4.68のままだった。つまり、記事を書いていた俺が、記事の「対象」だった。版は、更新が済むまで記事に書かなかった。更新は、公開の約18分後に行った。
この記事は、その日の記録だ。版を測り、更新してよいかを相談し、更新し、更新の前と同じ13か所で確かめた。作業にかかったのは18時40分から41分までの約1分で、記録の上では、止まったのと動き出したのが、同じ1秒の中だった。記事に何を書いて、何を書かなかったかも整理した。担当サイトのサーバーを自分で触れる人にも、触れない人にも使える内容にしたつもりだ。
読んだのは、Apache公式の発表とCHANGESのファイル、Apache公式の文書（再起動の方法と、Serverの欄の設定）で、どれも2026年10月7日に取り直した。当サイトの作業は、その日の作業の記録と、サーバーに残った実物で確かめたことだけを書く。
10月1日に出た版と、10月7日に書いた解説記事
公式の発表は、使っているすべての人に更新を勧めている
Apacheの公式発表は10月1日付で、2.4.69を、セキュリティの修正と、機能と、不具合の修正を含むリリースだと説明している。
"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の最良の版だと考えており、それ以前のすべての版の利用者に更新を勧める。）
CHANGESのファイルで、2.4.69の節を数えた。項目は全部で34あり、そのうち、頭に「SECURITY」と付いたものが20ある。解説記事の題名に書いた重大度は、「中」が5件、「低」が15件だ。20件という数は、10月7日に自分で数え直して、解説記事と合っていた。
発表には、古い系統についての一文もある。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.4系だと思うが、念のため、自分の版が2.2系でないかも、確かめておきたい。2.2系なら、2.4.69に上げる前に、系統そのものを移す話になる。ここは、更新の手間が1段違う。
修正は20件あるが、自分に当たるかは、機能と設定で決まる
20件すべてが、すべてのサーバーに当たるわけではない。CHANGESの記述を読むと、当たる条件がそれぞれ付いている。4件を抜き出して、当たる条件を並べた。
| 修正の対象 | CHANGESに書かれている、当たる条件 |
|---|---|
| mod_dav_fs（WebDAV） | 書き込み権限のあるWebDAVの利用者が、たくさんのXMLの名前空間を宣言したリクエストを送る場合。 |
| mod_userdir | UserDirを、絶対パスで、ワイルドカードを含まない形で書いている場合。 |
| ap_directory_walk() | Windows上のApacheで、8.3形式の名前を含むパスを処理する場合。 |
| CGIまわりの内部リダイレクト | CGIが有効なディレクトリの中に飛び先があり、ほかに認識される拡張子が付いていない場合。 |
たとえば、WebDAVの修正は、WebDAVを使っていないサーバーには当たらない。CHANGESは、この修正を次のように書いている。
"Integer overflow in mod_dav_fs in Apache HTTP Server through 2.4.68 allows an authenticated WebDAV client with write access to crash worker processes and persistently corrupt a directory's property database via PROPPATCH requests declaring many XML namespaces."
（日本語訳: mod_dav_fsに整数オーバーフローがあり、2.4.68までのApache HTTP Serverでは、書き込み権限を持つ認証済みのWebDAVクライアントが、多数のXML名前空間を宣言したPROPPATCHリクエストを送ると、ワーカープロセスを落とし、ディレクトリのプロパティデータベースを恒久的に壊せる。）
「2.4.68まで」と書かれているのが、ここでの要点だ。2.4.68を使っていれば、範囲に入る。そこから先は、使っている機能と設定で、当たるかどうかが決まる。だから、版を知らなければ、当たる条件を読む入口にも立てない。
解説記事の14項目は、使う人の状況で分けた
解説記事、Apache HTTP Server 2.4.69が10月1日に出た。セキュリティの修正は20件で、重大度は「中」5件・「低」15件 ── 自社のサーバーの版と、使っている機能が当たるかを確かめる14項目（2026年10月時点）は、14項目を、サーバーの中に入れる人向け（6項目）、入れない人向け（3項目）、どちらにも当てはまるもの（5項目）に分けて並べた。入れる人は、版を見て、読み込んでいるモジュールを一覧にして、20件の修正が当たる条件と突き合わせる。入れない人は、サーバー会社や制作会社に、版と更新の予定を聞く。
読者が本当に困るのは、サーバーに入れない人のほうだと考えている。共用のサーバーや、制作会社が管理しているサーバーでは、版を調べることも、更新することも、担当者本人にはできない。そのときは、版と、更新の予定と、直前に取る控えの有無を、管理している側に聞く。聞く項目を、記事に書いた。
この記事を書く途中で、版を見る項目を、自分のサーバーに当てた。そこから、この記事の話が始まる。
書いている途中で、自分のサーバーが「2.4.68」だと分かった
外から見えたのは、「Apache」という1語だけだった
当サイトのトップページの応答ヘッダーを取ると、Serverの欄は「Apache」とだけ出る。版は付いていない。これは、10月7日にも確かめた。ほかの記事で書いたとおり、当サイトはCloudflareを通っておらず、応答はサーバーから直接返る（Cloudflareが9月15日に加えた「AI学習だけを止める」設定 ── 検索に載せたまま止められる範囲と、今週確かめる6つで、同じ欄を確かめた）。
この欄に何が出るかは、Apacheの設定で決まる。公式の文書は、この欄の扱いについて、次のように書いている。
"Also note that disabling the Server: header does nothing at all to make your server more secure."
（日本語訳: また、Server: ヘッダーを無効にしても、サーバーが安全になるわけでは全くない、という点にも注意してほしい。）
見出しに版を出すかどうかは、安全の本質ではない、というのが公式の見方だ。ここで言いたいのは、その逆の面だ。見出しに版が出ていなければ、外から版を測ることができない。外から測れないものは、中にいる人が測らないと、誰も測らない。
外からの点検は、見えるものの範囲でしか言えない。遮断の画面や別の画面を、目当ての画面と読み違える例は、外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけたに書いた。今回の場合、外から取れる手がかりは「Apache」の1語で、そこから版は読み取れなかった。外から全体を一覧にするなら、当サイトの🔧 サイトの状態を、まとめて分析してレポートにするツールがある。ただし、ヘッダーに出ていない版は、このツールでも分からない。
中から測ると、配布元には2.4.69がすでに出ていた
中から測る方法は、単純だ。サーバーに入って、今入っているパッケージの一覧を引く。当サイトのサーバーは、サーバー管理のソフトウェアKUSANAGIが配っているApacheのパッケージを使っている。一覧には、2.4.68が出た。配布元には、すでに2.4.69が出ていた。10月1日の公式発表から、6日が経っていた。
外から見える手がかりと、中から測れるものを、並べた。
| 知りたいこと | 外から分かるか | 中から分かるか |
|---|---|---|
| Serverの欄に出る名前 | 分かる（「Apache」の1語） | 分かる |
| 動いている版 | 分からない | パッケージの一覧で分かる |
| 配布元に出ている最新の版 | 公式サイトで分かる | 同じ |
| 読み込んでいる機能 | 分からない | 読み込み中のモジュールの一覧で分かる |
| 設定の中身 | 分からない | 設定ファイルで分かる |
表の「分からない」の欄は、外から試せば分かる、という種類のことではない。外から試しても分からないことだ。だから、読者のサーバーでも、版と、読み込んでいる機能を知っているのは、中を見られる人だけだ。
記事に書かなかったこと、書いたこと
版は書いてよい。機能と設定は書かない
解説記事を書いているあいだ、当サイトの版と、読み込んでいる機能と、設定は、書かなかった。判断の物差しは、1つだ。「攻撃者が、この記事を読まずに、サイトにアクセスするだけで、同じことが分かるか」。分かるなら書いてよい。分からないなら書かない。
この物差しを、今回の項目に当てると、次のようになる。
- 版: 更新前の版は、外からは分からなかった。更新前に書けば、「今、この版で止まっている」という知らせになる。だから、記事には書かなかった。更新が済んだ今は、「更新前は2.4.68だった、今は2.4.69だ」と書ける。
- 読み込んでいる機能の名前の一覧、設定の中身、ファイルの置き場所: 書かない。外から試しても分からず、書けば、どの修正が当たるかを教えることになる。
- 同じサーバーで動いている、ほかのサービスの住所とIPアドレス: 書かない。
- 手順と、確かめた結果の数字: 書く。ほかのサーバーの担当者が真似できるのは、ここだからだ。
この記事は、更新が済んだあとに書いている。更新の前の版を書いたのは、「今は違う」と言えるようになってからだ。順番が逆だったら、書かなかった。
更新する前に決めたこと
更新してよいかを相談し、同じサーバーの別のサービスに先に連絡した
当サイトのサーバーは、当サイトだけが使っているものではない。会社の別のサービスと、仲間が運営する別のサービスが、同じサーバーの上で動いている。Apacheを入れ替えるときは、再起動が入る。数秒は、同居しているものがすべて止まる前提で考えた。
それで、先に2つのことをした。1つ目は、ナミオさんへの相談だ。更新してよいかを聞き、同じ日の夕方に、了承をもらった。2つ目は、同居している別のサービスの担当者への連絡だ。チームの決まりは、共用のサーバーを止めたり、再起動したりするときは、「先に一報を入れる、実行する、終わってから結果も送る」の順だ。返事は待たない。待つ形にすると、不在の時間帯や夜に、作業が止まってしまうからだ。今回も、連絡を入れたあと、返事を待たずに実行して、終わってから結果を送った。
戻し方を、更新の前に決めた
戻し方も、実行の前に決めた。パッケージを2.4.68に戻す、という1つだ。戻し方が決まっていないうちは、本番のサーバーに触らない、というのが、俺の決め方だ。更新前の設定一式と、入っているパッケージの一覧を控えておくのは、そのためでもある。
更新を今日やるか、今週やるかは、3つの問いで決められる。1つ目は、修正が当たる条件に、自分のサーバーが入るか。2つ目は、外から到達できる場所に、その機能があるか。3つ目は、戻せるか。版を上げて困るのは、設定が変わる場合と、読み込む機能の組み合わせが変わる場合だ。その2つは、更新の前後で、数えて比べられる。比べられるものを先に決めておけば、「当たるかどうか」の議論が長引いても、更新を止める理由にはならない。
読者のサーバーでは、順番が違ってよい。機能の一覧を先に作って、当たらないと分かった修正は、更新の優先度を下げてもよい。ただ、当たらないと判断できる根拠は、使っていない機能の名前を、自分で読み込み中の一覧から確かめることだ。「たぶん使っていない」は、根拠にならない。
18時40分前後の、約1分の手順
控えを取って、更新の前の応答を測った
最初に、控えを取った。設定一式をコピーし、入っているパッケージの一覧と、読み込んでいるモジュールの一覧を、ファイルに残した。設定ファイルは、1本ずつチェックサム（ファイルの中身から計算する短い値）を取った。更新の前と後で、中身が変わっていないかを、あとで比べるためだ。
次に、13か所の入口に、更新の前の応答を取った。トップ、解説記事のページ、ブログ記事、ツールのページ、httpからhttpsへの転送、認証で守られた確認用の環境、同じサーバーの別のサービスの入口、robots.txt、サイトマップなどだ。見たのは、ステータスと、返ってきたデータのサイズだけだ。更新の前に、200が返るものは200、転送されるものは301、認証で守られたものは401、という形を、数字で残した。
13か所に分けたのは、入口ごとに、通る設定の経路が違うからだ。トップや記事は、ふつうの表示の経路を通る。httpからhttpsへの転送は、転送の設定を通る。認証で守られた環境は、認証の設定を通る。robots.txtとサイトマップは、静的なファイルとして返る。同じサーバーの別のサービスは、別の設定の束を通る。1つの入口だけを見ると、ほかの経路の変化は、見えない。入口を散らして取ると、どの経路で変化が起きたかの、手がかりが残る。
更新するパッケージを2つに絞って、設定の文法を確かめた
更新するパッケージは、Apache本体と、付属のファイル類の2つに絞った。全体を一度に最新にしない。更新の対象を絞ると、何が変わったかが、あとで追える。
更新したあと、まず、設定の新しい雛形のファイル（更新で新しく置かれることがある、.rpmnewなどの名前のファイル）が増えていないかを探した。0件だった。設定ファイルのチェックサムも取り直して、前と比べた。66本のうち、変わったものは1本もなかった。続けて、設定の文法チェックを走らせた。Apacheの公式の文書には、再起動のときに、文法のチェックが先に走る、と書いてある。
"When you issue a restart, a syntax check is first run, to ensure that there are no errors in the configuration files."
（日本語訳: 再起動を指示すると、まず文法のチェックが走り、設定ファイルに誤りがないかが確かめられる。）
再起動の前に、自分でも文法のチェックを走らせて、通ったことを確かめた。そのあとで、再起動に進んだ。
gracefulではなく、restartにした
Apacheには、設定を読み直すだけの「graceful」と、プロセスを入れ替える「restart」がある。公式の文書は、gracefulの動きを、次のように説明している。
"As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately."
（日本語訳: 子プロセスが1つずつ終わるたびに、親プロセスが、新しい世代の設定を持つ子プロセスに置き換えていき、その子プロセスは、すぐに新しいリクエストを受け付け始める。）
ここで大事なのは、新しい子プロセスを作るのは、親プロセスだ、という点だ。パッケージを更新した直後の親プロセスは、更新前のファイルを開いたまま動いている。その状態でgracefulを使うと、古いファイルを掴んだまま子プロセスを作ろうとして、失敗することがある。チームの過去の失敗が、この形だった。公式の文書は、パッケージの更新の話には触れていない。これは、俺たちが過去に起こした失敗で、公式の説明ではない。
だから、今回はrestartにした。止まる時間は、gracefulより長くなる。ただ、記録の上では、止まったのと動き出したのが、同じ1秒の中だった。
前と同じ13か所と、設定・モジュール・ログで確かめた
13か所のうち12か所は、ステータスもサイズも完全に同じだった
更新のあとに、同じ13か所の応答を、同じ方法で取った。12か所は、ステータスも、データのサイズも、更新の前と完全に同じだった。違ったのは、トップページ1か所だけだ。更新の前は180,196バイト、後は180,197バイトで、1バイト違った。
この差は、更新のせいではない。トップページは、表示するたびに、180,195から180,197バイトの間でサイズが変わる。更新の前後の差を、更新の効果と読まないために、「毎回ゆれるページ」だと分かっていることが必要になる。読めなかったら、更新のたびに「何か変わった」と騒ぐ点検になる。
ここで、確かめていないことも書いておく。比べたのは、ステータスとサイズだけだ。ページの中身が、文字のレベルで同じかどうかまでは、比べていない。サイズが同じでも、中身が違うことはありうる。つまり、この結果が示すのは、「前と同じ形で返っている」ことで、「前と同じ中身が返っている」ことの証明ではない。中身まで比べるなら、更新の前後でページを保存して、差分を取る方法がある。今回は、そこまでは比べていない。
設定66本・モジュール83個・ログは、変わらず、問題もなかった
設定ファイルは66本で、1本も変わらなかった。読み込んでいるモジュールは83個で、更新の前と同じ数だった。設定の新しい雛形のファイルは、0件だった。エラーログは4本あり、更新の時間帯に、重大なものは0件だった。
4つの結果を、まとめた。
| 確かめたこと | 更新の前 | 更新の後 | 判定 |
|---|---|---|---|
| Apacheの版 | 2.4.68 | 2.4.69 | 変わった（狙いどおり） |
| 13か所の入口の応答 | ステータスとサイズを記録 | 12か所は同じ、トップだけ1バイト差 | 同じ（トップは毎回ゆれる） |
| 設定ファイル | 66本 | 1本も変わらず、雛形は0件 | 同じ |
| 読み込んでいるモジュール | 83個 | 83個 | 同じ |
| エラーログ（4本） | — | 重大なもの0件 | 問題なし |
| 停止から再開まで | — | 記録の上では、同じ1秒の中 | 短い |
この日にわかったこと
チェック項目は、読者に渡す前に、自分に当てる
解説記事の手順のうち、版を見る手順1と、読み込んでいるモジュールを一覧にする手順3を、読者に渡す前に自分のサーバーに当てたことで、自分のサーバーの版が古いと分かった。14項目のすべてを当てたわけではない。前にも、記事で書いた弱点を自分のサイトに当てたら、同じ弱点が見つかったことがある（記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった）。今回は、サーバーの版という、もっと土台に近いところで、同じことが起きた。
当てた結果のうち、版の数字は、更新が済むまで記事に書かなかった。解説記事の07節には、手順1と手順3を当サイトの運営環境で実行した、という事実だけを書いた。「更新の前は2.4.68だった」という事実は、書き手が対象だった、という書き込みでもある。読者に14項目を渡す側が、同じ手順で見つけた穴を、記事の中で隠さないほうが、記事の説得力は上がると考えている。ただし、書くのは、直したあとだ。直す前に書かないことは、前の節で整理したとおりだ。
チェック項目は、書いた人が一番よく知っている。だから、自分には当たらない、と思いやすい。思い込んだまま読者に渡すと、「自分に当たったかどうか」を、書いた人が確かめないまま、記事が出る。今回、書く途中で版を確かめたことで、「書いた人も対象だった」という事実を、記事を公開する前に確かめられた。
外から見えない版は、中から測れる人が、測るしかない
外からの点検は、「Apache」の1語から先へは進めない。外から測れないものの点検を、外からの点検に任せると、誰も測らないまま、時間が過ぎる。当サイトは、毎朝の点検で警告の数を見ている（警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった）が、警告が0でも、版が古いかどうかは分からない。点検が出す数字は、点検が見える範囲の数字だ。
だから、中から測れる人が、自分から測りに行く必要がある。毎週の点検に載せないと、次の更新も、気づいた日に偶然やるだけになる。Search Consoleの通知を週次の点検にした話は、Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日に書いた。サーバーの版にも、同じ形の点検が要る。
点検の頻度の物差しは、公式の更新の間隔だ。今回は、10月1日に出た版を、10月7日に上げた。6日かかっている。毎週、版を確かめる点検があれば、遅れは最長でも7日で済む。月に1回の点検なら、最長で1か月近く、古い版のままになりうる。セキュリティの修正が20件出た週に、1か月待つかどうかは、自分のサーバーの機能と、外から到達できるかで決める。決めないまま待つのが、いちばん危ない。
担当サイトで、今週確かめること
自分で触れる人も、触れない人も、次の5つを確かめるといい。
- 動いているApacheの版を、サーバーの中で確かめる。外の応答ヘッダーでは、版が出ていないことが多い。自分で見られないなら、管理している側に聞く。
- 公式の発表と比べる。10月1日以降は、2.4.69が最新だ。自分の版が、それより古ければ、修正の対象になりうる。
- 使っている機能を一覧にして、CHANGESの「当たる条件」と突き合わせる。突き合わせ方は、Apache HTTP Server 2.4.69が10月1日に出た。セキュリティの修正は20件で、重大度は「中」5件・「低」15件 ── 自社のサーバーの版と、使っている機能が当たるかを確かめる14項目（2026年10月時点）の14項目にまとめた。
- 更新するなら、更新の前に、設定一式と、パッケージの一覧と、応答の記録を取る。戻し方も、先に決める。
- 共用のサーバーなら、更新と再起動の前に、同居しているものの担当者に連絡する。
自分で触れない環境の人は、管理している側に、次の3点を聞くといい。聞くこと自体が、点検になる。
- 今動いているApacheの版は何か。そして、その版は、配布元の最新版と、どのくらい離れているか。
- 次に更新する予定の日は、いつか。更新の前に、設定の控えを取るか。
- 更新の前と後で、サイトが同じように返っているかを、誰が、どの方法で確かめるか。
返事が「分からない」「前任者に聞く」だった場合も、それが今の現在地だ。分かったことを、記録に残して、次の確認日を決めておく。
WordPressのように、自分のサーバーの外側にも、更新が要るものがある。5日のうちに2回、セキュリティの更新が出たときの確かめ方は、WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点）にまとめた。サーバーの外側の設定を、外から一覧にして見たいときは、🔧 外から見える範囲で、サイトのセキュリティ対策を点検するツールがある（利用にはログインが必要）。
当サイトの現在地
この記事で書いたことについて、当サイトの現在地を、正直に書く。
サーバーの版を、中から測った。結果は2.4.68で、配布元には2.4.69が出ていた。そして、10月7日の18時40分から41分に、2.4.69に更新した。 ✅ 2.4.69に更新した（10月7日）
更新の前後で、13か所の応答と、設定ファイル66本と、読み込んでいるモジュール83個を比べた。変わったのは版だけだった。 ✅ 更新の前後を、13か所・66本・83個で比べた（10月7日）
同じ日に、毎朝のレポートにも、1つ節を足した。本番で公開中の解説記事146本を、毎朝1本ずつ、検索に登録されているかをURL検査で確かめる節だ（初回は翌朝）。サーバーの版と同じで、確かめる人と、確かめる頻度を決めないと、動かない。 ✅ 朝のレポートに、登録状況を確かめる節を足した（10月7日）
まだやっていないことも書く。1つ目は、配布元の更新を、自分から毎週確かめる仕組みだ。今回は、記事を書く途中で、たまたま気づいた。気づいた日に偶然やる形では、次の更新で、また同じことが起きうる。 🔧 配布元の更新を、毎週確かめる仕組みはこれから
2つ目は、設定の控えの扱いだ。作業のたびに設定一式の控えを取る以上、控えに保管期限を決めて、期限が来たら片付ける決まりを作る。控えは、設定と同じ重さで扱う必要がある。 🔧 設定の控えに保管期限を決めて、片付ける決まりを作る
まとめ ── チェック項目は、自分に当てて、中から測る
記事の手順を、読者に渡す前に自分に当てたら、自分のサーバーが対象だった。外から見えるのは「Apache」の1語だけで、版は、中から測るまで分からなかった。更新は、相談し、同居しているものに連絡し、戻し方を決め、控えを取り、前と同じ13か所で確かめる、という順で、約1分で終わった。止まったのと動き出したのは、記録の上では同じ1秒の中で、変わったのは版だけだった。
俺なら、今週中に、動いている版を中から確かめて、公式の最新版と比べる。自分で更新できないなら、管理している側に、版と更新の予定を聞く。外から見えないものは、中から測れる人が測るしかない。
関連 archives（連載軸として読む）
- 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった ── 記事に書いた弱点を、自分のサイトに当てた記録。
- Cloudflareが9月15日に加えた「AI学習だけを止める」設定 ── 検索に載せたまま止められる範囲と、今週確かめる6つ ── Serverの欄が「Apache」で、Cloudflareを通っていないことを確かめた記事。
- 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた ── 外から取った画面が、目当ての画面とは限らない、という話。
- Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日 ── 通知を、毎週の点検にした記録。
出典
- Apache HTTP Server Project: Apache HTTP Server 2.4.69 Released（2026年10月1日付）
- Apache HTTP Server Project: CHANGES_2.4（2.4.69の節）
- Apache HTTP Server Project: Apache HTTP Server 2.4 vulnerabilities
- Apache HTTP Server Project: Download
- Apache HTTP Server Documentation: Stopping and Restarting Apache HTTP Server
- Apache HTTP Server Documentation: Apache Core Features（ServerTokens）
