GitLabの脆弱性が10月29日にCISAの悪用確認リストへ載り、期限の欄は11月1日だった。対象は自前で動かす側で、GitLab.comは修正済みと提供元が書く ── サイトを作る道具の更新台帳を作って確認する13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — CISAの悪用確認リストにGitLabが10月29日に載り、期限の欄は11月1日だった
   1. カタログの行を読む
   2. 3つの日付の間隔
   3. 一覧の注記が書いていること
2. 02 なぜ・背景 — サイトの更新は追うが、サイトを作る道具の更新は抜け落ちやすい
   1. 担当サイトの台帳に、道具は載っていない
   2. 道具の側が、サイトの側へ届く道
   3. 期限の欄の日付が先に届く
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. パッチ版とマイナー版の呼び方
   2. 悪用確認リストの「載る条件」
4. 04 型別 — 自前の側と提供元の側、確かめられる範囲、台帳の作り方
   1. 🅰 適用範囲 — 自前で動かす側だけが更新の作業を持つ
   2. 🅱 この情報が測っていないこと
   3. 🅲 手順1 — 会社の中の「作る道具」を種類で洗い出す
   4. 🅲 手順2 — 版を調べて、修正版と比べる
   5. 🅲 手順3 — 外から画面が開けるかを見る
   6. 🅲 手順4 — CIの設定を書き換えられる人の一覧を作る
   7. 🅲 手順5 — 更新の前に取る控えと、更新の道筋を確かめる
   8. 🅲 手順6 — 更新の後に、版の表示をもう一度見る
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 台帳の持ち方と、更新の知らせの受け取り方
   1. 台帳をどこに置くか
   2. 更新の知らせの受け取り方
7. 07 当サイトで確かめたこと — GitLabは動いていない
8. 08 このテーマは、ここまで — 悪用確認リストを追った記事の流れ
   1. これまでの記事
   2. 今回の記事の位置
9. 09 この記事のまとめ

01 何が書いてあるか — CISAの悪用確認リストにGitLabが10月29日に載り、期限の欄は11月1日だった

CISA（米国のサイバーセキュリティの政府機関）は、「悪用が確認された脆弱性」の一覧（Known Exploited Vulnerabilities Catalog）を公開している。この一覧に、2026年10月29日、GitLabの脆弱性CVE-2026-97229が加わった。GitLabは、ソースコードの保管（Git）と、自動でビルドや検査を流す仕組み（CI/CD）を1つにまとめた、よく使われる開発の道具である。会社や制作会社が自前のサーバーで動かしていることがあるが、サイトそのものではなく、サイトを作る側の道具である。

担当サイトの更新台帳は、PHPやWordPressの版を並べるところまでは作っている会社が多い。だが、サイトを作って運用する道具の台帳は、持っていない会社が多いと筆者は読む（筆者の読みで、数えた数字ではない）。この記事は、脆弱性の中身の解説ではなく、制作や運用に使っている道具の更新台帳を作る手順に絞る。一覧の期限の欄の読み替えは、既存の解説記事に任せて、リンクで済ませる。

カタログの行を読む

CISAのカタログで、CVE-2026-97229の行を開いた。あわせて、NVDの記録と、GitLabのパッチ公開のお知らせ（10月12日の日付）を開いた。3つの記述を、同じ表にまとめる。

NVDの説明文の要旨は、認証を受けていない利用者が、CI/CDの設定に含まれる細工された正規表現を通して、GitLabのサーバー上で任意のコードを実行できる場合がある、というものである。原因は、正規表現の検証が足りないことと書かれている。CISAの名称は整数のオーバーフローで、NVDの説明文は正規表現の検証不足と書く。表現が違うので、同じ問題を別の側面から書いたものかを迷う。GitLabのお知らせは、正規表現のコンパイラーでの整数のオーバーフローと書いて、2つをつないでいる。

3つの日付の間隔

パッチ公開（10月12日）からNVDの公開（10月13日）までが1日、そこからCISAの一覧への追加（10月29日）までが16日、追加日から期限の欄（11月1日）までが3日である。パッチ公開から一覧への追加までは17日、パッチ公開から期限の欄の日付までは20日になる。

一覧の注記が書いていること

一覧の行の備考欄には、同じ根っこの問題（Rubyの正規表現の部品に関する整数のオーバーフロー）で、ほかの製品も影響を受けうるという趣旨の注記がある。どの製品かは、一覧には書かれていない。GitLabの更新が済んだ会社も、同じ部品を使うほかのソフトがないかは、この記事の台帳づくりの対象になる。ただし、影響の有無は各ソフトの提供元の案内で確かめるしかなく、この記事では確かめていない。

02 なぜ・背景 — サイトの更新は追うが、サイトを作る道具の更新は抜け落ちやすい

担当サイトの台帳に、道具は載っていない

WEBディレクターが更新を追うのは、たいてい、公開しているサイトの側である。PHP、WordPress、プラグイン、サーバーのOSがそれにあたる。一方、サイトを作る過程で使う道具は、導入したのが開発者の1人だったり、制作会社の中で動いていたりして、会社の資産台帳にも担当サイトの台帳にも載らないことがある。GitLabの画面は、社内か制作会社の人しか見ないので、サイトの訪問者には見えない。見えないものは、更新の話題に上りにくい。

道具の側が、サイトの側へ届く道

道具が公開サイトと別の場所にあっても、無関係とは言い切れない。CI/CDの仕組みは、サイトの部品を作って、サーバーへ配る役目を持つことが多い。ソースコードの保管場所には、サイトの設定や、場合によっては外部サービスへの接続の情報が置かれることもある。道具が乗っ取られた場合の被害は、道具の中だけで済むとは限らない。これは筆者の読みで、今回のCVEがそうなった、という意味ではない。今回のCVEについて、公式の記述が書いているのは、GitLabのサーバー上で任意のコードが実行されうる、という範囲までである。

期限の欄の日付が先に届く

ニュースでは「期限は11月1日」と短く伝わる。この日付は、米国の連邦の行政機関に向けた決まりである。日本の会社に同じ義務があるわけではない。期限の欄の読み方は、CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）に詳しく書いたので、ここでは繰り返さない。この記事で足すのは、期限の日付が自分の会社に何を意味するかを決める前に、そもそもその製品を会社が動かしているかを数えるという、一歩手前の作業である。

03 用語 — 出てくる言葉を、先にそろえる

パッチ版とマイナー版の呼び方

GitLabの版の番号は、19.4.2のように3つの数で書く。最初の2つ（19.4）が系列、最後の数（2）が、その系列の中の修正の回数である。今回の影響範囲は、19.2、19.3、19.4の3つの系列に分かれて書かれている。自分の版が「19.3.4」なら、19.3の系列の修正版19.3.5より前なので、影響の範囲にいる。系列ごとに修正版の番号が違うので、自分の系列の行だけを見る。

悪用確認リストの「載る条件」

CISAの説明のページによると、一覧に載せる条件は3つである。CVE番号が付いていること、悪用されたという信頼できる証拠があること（成功だけでなく試みも含む）、ベンダーの更新のような明確な対処があること。調べるための通信、研究、公開された試験用コードだけでは、条件を満たさない。一覧に載ったことは、悪用の証拠があるという印であって、点数が高いという印ではない。今回のCVEは点数も最高の10.0なので、2つが重なっている。

04 型別 — 自前の側と提供元の側、確かめられる範囲、台帳の作り方

🅰 適用範囲 — 自前で動かす側だけが更新の作業を持つ

GitLabのパッチ公開のお知らせの要旨は次のとおりである。パッチは19.4.2、19.3.5、19.2.8として2026年10月12日に出た。GitLab.comは、すでに修正版で動いている。GitLabが管理する専用環境（GitLab Dedicated）の利用者の環境は、パッチ公開の前に内部のリリースで直された、とも書かれている。自前で動かしている環境には、直ちに更新するよう強く勧めている。同じ更新で、GitLabはほかのCVEも直している。更新の理由は、このCVEだけではない。

この書き方からは、会社が使っているGitLabが3つのどれかで、やることが変わる。表にまとめる。

なお、「GitLab.comを使っているから関係ない」と言い切れるのは、GitLab.comの利用者の環境そのものについてだけである。同じ会社が、GitLab.comのほかに、自前のGitLabを動かしていることもある。その場合は、自前の側が台帳の行になる。

🅱 この情報が測っていないこと

3つの公式情報が書いていないことも多い。実際に悪用された相手や手口の詳細は、どこにも書かれていない。一覧は悪用の証拠があることを示すが、どの環境が狙われたかは示さない。また、CISAの名称とNVDの説明文の言い方の違いの理由も、記録の上では示されていない。日本国内での被害の状況は、筆者が開いたページには出ていなかった。この記事は、攻撃の方法や手順を書かない。守る側が確かめられるのは、版、運用者、外からの見え方、権限の一覧の4つである。

🅲 手順1 — 会社の中の「作る道具」を種類で洗い出す

GitLabだけを探すと、ほかの道具が抜ける。次の種類ごとに、会社と制作会社が何を使っているかを聞く。表にして、1種類ずつ埋める。

聞く相手は、社内の担当者、制作会社の窓口、サーバーの運用者の3者である。1通のメッセージに、上の6つの種類を並べて送ると、返事が1回で集まる。「使っていない」という返事も、台帳の行に書く。書かないと、次に誰かが同じことを聞き直す。

🅲 手順2 — 版を調べて、修正版と比べる

自前でGitLabを動かしている場合は、サインインして版を見る。GitLabの「Find the GitLab version（訳: GitLabの版を調べる）」のページによると、自前で動かす環境では、左のサイドバーの下にある「Help」から「Help」を開くと、ページの上部に版が出る。管理者でなくても、サインインした利用者なら見られると読める書き方である（筆者はGitLabを自前で動かしていないので、画面は確かめていない）。GitLab.comの場合は、公式のページに書かれた住所の「help」を開く。版が分かったら、次の順で比べる。

1. 版の最初の2つの数（系列）が、19.2、19.3、19.4のどれかを見る。ほかの系列は、今回の影響範囲の表には出ていない。
2. 該当する系列なら、最後の数を見る。19.2なら8未満、19.3なら5未満、19.4なら2未満が、影響の範囲である。
3. 影響の範囲なら、同じ系列の修正版（19.2.8、19.3.5、19.4.2）以上に上げる予定日を、運用者に書面で聞く。

19.1以前や、19.5以降の版については、今回開いた情報には書かれていない。書かれていない系列は「安全」とは読まず、GitLabの公式のお知らせで確かめる。更新の後に版の表示が変わったかを、もう一度見る。表示が変わっていなければ、更新が済んでいない。

🅲 手順3 — 外から画面が開けるかを見る

NVDの説明は、認証を受けていない利用者を挙げている。つまり、外から画面に届くかどうかが、危険の大きさを左右する。確かめ方は簡単である。ブラウザのシークレットウィンドウで、GitLabのアドレスを開く。ログインの画面が出るのか、何も出ないのか、会社のネットワークの外からは届かないのかを、書き留める。見える画面を、そのまま書き写すだけでよい。試す操作はしない。

届く範囲を決めるのは、社内のネットワークの設定やVPNである。画面が外から開けた場合は、「誰でも」「会社のネットワークだけ」「VPNの利用者だけ」のどれかを、運用者に確かめて台帳に書く。🔧 WEBサイトの外からできるセキュリティ対策監査ツール（要ログイン） — 外から見える設定を点検して、更新の後の見直しに使うは、公開サイトの側の外から見える設定の点検に使える。社内の道具そのものの点検は、このツールの対象ではない。

🅲 手順4 — CIの設定を書き換えられる人の一覧を作る

CIの設定は、サイトの部品を組み立てて配る流れを決める。書き換えられる人は、少ないほうがよい。GitLabの画面で、プロジェクトごとの利用者と役割の一覧を開き、設定を書き換えられる人を書き出す。各人の所属と、今も必要かを横に書く。辞めた人や、契約の終わった外部の人が残っていないかを見る。NVDの説明は認証を受けていない利用者を挙げているので、この一覧は更新の代わりにならない。更新を待つ間と、更新の後の点検に使う、補助の作業である。

🅲 手順5 — 更新の前に取る控えと、更新の道筋を確かめる

自前のGitLabを更新するときは、運用者の作業が前後に付く。GitLabの「Before you upgrade（訳: 更新の前に）」のページの要旨は、次の3つである。1つ目は、更新の前に、サーバーのスナップショットか、GitLabのバックアップを取ること。2つ目は、バックアップに、秘密の情報と設定ファイルを含めること。3つ目は、元に戻すときは、バックアップを取った環境と戻す先の環境で、GitLabの版が同じでなければならないこと。あわせて、更新の道筋（途中で必ず経由する版があるか）を先に調べるよう書かれている。

WEBディレクターが運用者に聞くのは、操作の中身ではなく、更新の予定日、更新の前に控えを取るか、戻し方があるかの3つである。自前の環境を更新する期限は、道筋によっては1回で済まない。修正版が19.4.2でも、今の版から1回で上げられるとは限らない。この点は、GitLabの更新の道筋のページに従う（今回は開いていない）。

🅲 手順6 — 更新の後に、版の表示をもう一度見る

更新が済んだと聞いたら、手順2と同じ画面で版を見直し、台帳の「版」の列を書き換える。更新したという返事より、画面の版の表示を台帳の根拠にする。版が修正版以上になっていれば、今回のCVEの影響の範囲からは外れる。更新の日付も同じ行に書く。

05 明日、担当サイトで確認できることチェックリスト

以下は、サイトを作る道具の更新台帳を作り、GitLabの今回のCVEに当てはまるかを確かめる13項目である。1〜3番目は公式情報の読み取り、4〜6番目は道具の洗い出し、7〜10番目は自前のGitLabがある場合の確認、11〜13番目は権限、変更履歴、更新期限の確認である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• CISAの悪用確認リストのカタログを開き、「GitLab」で絞って、CVE-2026-97229の行の追加日（10月29日）と期限の欄（11月1日）をメモ帳に書き写す
• NVDでCVE-2026-97229を開き、影響を受ける版の3つの範囲（19.2.0以上19.2.8未満、19.3.0以上19.3.5未満、19.4.0以上19.4.2未満）をメモ帳に書き写す
• GitLabのパッチ公開のお知らせ（19.4.2・10月12日）を開き、修正版の3つの番号を、2番目で書き写した範囲と突き合わせる
• 会社と制作会社の担当者に「GitLabを自分たちで動かしているか」を1通のメッセージで聞き、返事を「自前で動かす」「GitLab.comを使う」「使っていない」「不明」の4つに分けて書き留める
• 作る道具の台帳を1枚の表で作り、ソースコードの保管、CI/CD、課題管理、チャット、分析の管理画面、ファイルの共有の6つの種類ごとに、製品名を1行ずつ書き出す
• 台帳のGitLabの行に、運用者の名前、動かしている場所、版の3つの列を埋める。分からない列には「不明」と書く
• 自前のGitLabがある場合は、サインインして左のサイドバーの下の「Help」から「Help」を開き、ページ上部の版を書き写して、19.2、19.3、19.4のどの系列かを書き留める
• 版が影響の範囲に入る場合は、同じ日のうちに運用者へ、修正版の番号と更新の予定日を書面で尋ねる
• ブラウザのシークレットウィンドウで自前のGitLabのアドレスを開き、ログインせずに見える画面を1つ書き出す
• 外から画面が開けた場合は、届く範囲（誰でも、会社のネットワークだけ、VPNの利用者だけ）を運用者に確かめて、台帳に書く
• GitLabのプロジェクトのうち、サイトの配布に関わる1つを選び、CIの設定を書き換えられる人を一覧にして、所属と、今も必要かを3列で書く
• 選んだプロジェクトのCIの設定の変更履歴を、直近30日分開き、見覚えのない変更者や時刻がないかを数えて、件数を台帳に書く
• 更新の期限を自分で決めて台帳に日付を書き、次の見直し日をカレンダーに入れる

06 代替・他の選択肢 — 台帳の持ち方と、更新の知らせの受け取り方

台帳をどこに置くか

台帳の置き場は、表計算のシートでも、課題管理の画面でも構わない。大事なのは、更新の知らせが来たときに、1分で開ける場所にあることである。3つの置き方を比べる（筆者の整理）。

• 共有の表計算シート — 道具が10個前後までで、更新する人が数人のとき向く。最終確認日を書き忘れやすい。
• 課題管理の画面 — 道具ごとに更新の作業を追いたいとき向く。全体を1画面で見渡しにくい。
• 委託先の報告書に項目を足す — 運用を委託しているとき向く。委託先が項目の意味を取り違えることがある。

更新の知らせの受け取り方

製品の提供元は、更新の知らせを公開している。GitLabのパッチ公開のお知らせのように、ページを開けば日付と版が書かれているものが多い。GitLabの場合は、リリースノートのページが、版の系列ごとに、パッチのお知らせへの入口になっている（筆者が開いた時点では、このページ自体には個別の日付は載っていなかった）。担当者が週に1回、台帳の製品の提供元のページを開く日を決めておくと、ニュースが先に届く状態から抜けられる。CISAの一覧は、その補助として使う。載った製品が台帳にあるかを、見る。

07 当サイトで確かめたこと — GitLabは動いていない

2026年10月30日に、当サイトのサーバーで、GitLabのパッケージが入っているかを数えた。結果は0件だった。GitLabの名前で動いているプロセスも0件だった。この2つの確認が示すのは、当サイトを動かすサーバーの上では、GitLabを動かしていないことまでである。コンテナ（箱に入れて動かす仕組み）の中で動く形は、数えていない。

当サイトの運用の記録は、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法に書いた。サイトの側の更新の確かめ方は、その記事の範囲である。道具の台帳は、そこで抜けていた部分にあたる。

08 このテーマは、ここまで — 悪用確認リストを追った記事の流れ

これまでの記事

当サイトでは、2026年10月に入って、悪用確認リストに載った製品を何度か取り上げた。時系列で並べる。

• PHPの2件の重大な脆弱性が出た週は、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録で書いた。
• 修正が入ったかを値で確かめる方法は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。
• 圧縮の部品の脆弱性は、圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方に書いた。
• 期限の欄の読み替えは、CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）に書いた。
• 圧縮の部品の側の確認項目は、Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目（2026年10月時点）に書いた。
• サイトの前に置く部品の台帳は、SiteGuard Server Editionの脆弱性は、開発元が悪用を確認している。更新の前に診断情報を保存する ── サイトの前に置いた部品の台帳を作って確認する13項目（2026年10月時点）に書いた。

今回の記事の位置

これまでの記事は、サイトを動かす側の更新を扱ってきた。この記事で初めて、サイトを作る側の道具を扱った。2つの台帳は、並べて持つ。担当サイトの一覧の作り方は、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）にある。道具の台帳の列は、その8列とは別に持つ。 🔧 WEBサイト総合分析・レポートツール — 公開ページの状態をまとめて確認するは、公開サイトの側の状態を見る入口になる。