修正版は3本、下限は18通り — GitLab の18件を版数で機械判定する
GitLab が 2026年9月10日、CE / EE のクリティカルパッチリリースを出した。修正版は 19.3.2 / 19.2.6 / 19.1.8 の3本で、ここで塞がれた CVE は 18件ある。
そのうち CVE-2026-85706 は CVSS 3.1 で 10.0、CISA が翌 9月11日に KEV(Known Exploited Vulnerabilities・悪用が確認された脆弱性のカタログ)へ収載し、是正期限を 3日後の 9月14日に設定した。リポジトリの commits API に、認証を経ずにサーバ上の任意のファイルを読めるパストラバーサル(CWE-22)がある。
急ぐ理由は分かる。問題は「自分が該当するのか」である。ここが一行では書けない。
修正版は3本なのに、下限は18通りある
リリースノートの18件を、影響範囲の下限だけ並べてみる。上限はすべて共通で、3系列それぞれの修正版の1つ手前(19.1.7 / 19.2.5 / 19.3.1)である。
| CVE | CVSS | 下限 |
|---|---|---|
| CVE-2026-82837 | 5.3 | 10.1.0 |
| CVE-2026-88765 | 8.5 | 12.3 |
| CVE-2024-11222 | 6.4 | 13.0 |
| CVE-2026-8030 | 4.3 | 13.0 |
| CVE-2026-7514 | 4.3 | 13.9 |
| CVE-2026-78252 | 8.2 | 15.3 |
| CVE-2026-13210 | 7.7 | 15.7 |
| CVE-2026-86341 / CVE-2026-86340 | 4.4 | 17.1 |
| CVE-2026-3855 | 3.1 | 18.2.7 |
| CVE-2026-87719 | 9.9 | 18.3 |
| CVE-2025-14871 / CVE-2026-1168 | 7.5 | 18.4.6 |
| CVE-2026-12910 | 5.4 | 18.6 |
| CVE-2026-85706 | 10.0 | 18.7 |
| CVE-2026-16794 | 4.3 | 18.11 |
| CVE-2026-79708 | 8.5 | 19.0 |
| CVE-2026-19619 | 4.7 | 19.0 |
下限は 10.1.0 から 19.3 まで散っている。同じパッチで直る18件が、始まった時期は最大で9年ぶんずれている。 だから「18.7 以降が危ない」も「19系が危ない」も、どちらも18件全体の説明にはならない。CVSS 10.0 の1件だけを見れば 18.7 が下限だが、その隣にある CVSS 9.9 の CVE-2026-87719 は 18.3 が下限で、18.5 で止まっている環境は前者に該当せず後者に該当する。
そしてもう一段やっかいなのが、修正版が3本しか無いという点である。19.1 / 19.2 / 19.3 の3系列にしか修正版が存在しない。18系で止まっている環境には、上げるべき「自分の系列の修正版」が無い。系列をまたいで 19.1.8 以降へ上げるしかない。
前に書いた JFrog Artifactory の2件では、系列ごとに修正版が用意されていて、「自分の系列の最新に上げる」が片方のCVEには効き、もう片方には効かなかった。今回は形が違う。そもそも自分の系列に修正版が無い帯がある。
目で追うと必ず間違える。データにして数える。
判定スクリプト
リリースノートの表をそのままデータにして、稼働中の版から該当CVEを数える。依存は無い。
1 | |
判定の本体は2つに分かれる。1つは「該当するか」、もう1つは「どこへ上げるか」である。後者が今回の肝で、自分の系列に修正版が無い場合を別扱いにする。
1 | |
applies の最後の return true が、18系で止まっている環境を拾う行である。上限は「自系列の修正版の1つ手前」なのだから、修正版が存在しない系列では上限が無い、と読む。
走らせる
代表的な版を並べて実行した実際の出力である。
1 | |
読み取れることが3つある。
1つ目。19.0.4 と 18.10.2 の差が「CVSS 10.0 に該当するかどうか」ではない。 どちらも CVE-2026-85706 に該当する(18.7 以上だから)。違うのは件数で、19.0.4 は18件全部、18.10.2 は15件である。落ちた3件は下限が 18.11・19.0・19.0 のもので、要するに新しい版のほうが該当件数が多い。「古いほど危ない」という直感はここでは成り立たない。
2つ目。17.5.0 は CVSS 10.0 に該当しない。 下限 18.7 に届いていないからである。ところが該当は9件あり、最大 CVSS は 8.5 である。KEV の是正期限に追われているのは 85706 だが、17系の環境がやるべきことは「85706 は無関係だから急がない」ではなく「9件に該当していて、しかも上げ先が2メジャー先の 19.1.8 しかない」である。判断の材料がまったく違う。
3つ目。12.2.0 の該当は1件だけである。 下限 10.1.0 の CVE-2026-82837(CVSS 5.3)しか当たらない。これは「12.2.0 は安全」という意味ではまったくなく、この18件の対象になるほど新しくないというだけである。12系はとうに保守期間の外で、この表に載っていない過去の脆弱性が積み上がっている。スクリプトが数えているのは「このリリースノートの18件」だけだと、出力の読み手に必ず伝える必要がある。
落とし穴: 版数を文字列で比べる
cmp をわざわざ書いたのは、"19.10.0" < "19.2.6" が JavaScript では true になるからである。実測した。
1 | |
1 | |
文字列比較は先頭から1文字ずつ見るので、"1" と "2" の比較で決着してしまう。19.10.0 は 19.2.6 より 新しいのに、文字列では古いと判定される。
これは机上の話ではない。GitLab の 19.1 系はこのあと 19.1.9、19.1.10 と進む。version < "19.1.8" という文字列比較で「まだ危ない」を判定していると、19.1.10 に上げた環境が「未対応」と表示され続ける。逆向きの事故も起きる。下限 18.4.6 に対して "18.4.10" >= "18.4.6" は false なので、該当しているのに該当しないと判定される。
安全側にも危険側にも倒れる。だから桁ごとに数値で比べる。
まとめ
同じパッチリリースで直る複数のCVEを、1つの「影響範囲」で要約しない。 今回の18件は修正版が3本しか無いので、上げ先だけを見れば話は単純に見える。しかし該当範囲の下限は 10.1.0 から 19.3 まで18通りに散っていて、稼働中の版によって該当件数は 0件から18件まで変わる。「18.7 以降が危ない」と一行で覚えると、18.5 の環境で CVSS 9.9 を見落とす。
やることは2つだけである。リリースノートの表をそのままデータにすること。版数を桁ごとに数値で比べること。この2つを守れば、稼働中の版を1つ入れるだけで該当件数と上げ先が出る。目で追う作業をやめられる。
出典: GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8(確認日 2026-09-15)。CVE-2026-85706 の KEV 収載日と是正期限は CISA Known Exploited Vulnerabilities Catalog による。GitLab.com は修正済みで稼働しており、GitLab Dedicated の利用者は対応不要とリリースノートに明記されている。本記事が扱うのは自己管理型の GitLab である。