GitLabのCVE-2026-85706がKEV入り。認証なしでサーバー上のファイルが読まれるcommits APIのパストラバーサルと更新手順

ソースコード置き場が、未認証のファイル読み取りの入口になりました#

GitLabは2026年9月10日、GitLab Community Edition(CE)とEnterprise Edition(EE)のCritical Patch Releaseとして19.3.2、19.2.6、19.1.8を公開しました。このリリースで修正されたCVE-2026-85706は、repository commits APIのパスの閉じ込め不備と認証強制の欠落により、認証していない利用者がGitLabサーバー上の任意のファイルを読めてしまう脆弱性です。翌9月11日、CISAはこのCVEを実際の悪用の証拠に基づいてKEVカタログへ追加しました。

GitLabは、ソースコードだけでなくCI/CDの変数、デプロイ用のトークン、Runnerの登録情報、外部サービスとの連携設定を抱える機械です。サーバー上のファイルが外から読めるということは、そうした秘密情報の置き場所に手が届く可能性があるということです。この記事では、セルフマネージドGitLabの運用者と開発基盤の管理者向けに、公表された事実、影響版の読み方、更新の段取り、更新だけでは片づかない事後対応の順に整理します。

公開された事実を一次資料でそろえる#

まず、GitLabのリリースノート、CISAのKEVカタログ、NVDに記録された値を並べます。

GitLabのリリースノートは、CVE-2026-85706について「under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API」と説明しています。報告者はHackerOneのバグバウンティプログラムを通じたs3ntago氏です。同じページには、GitLab.comはすでに修正版で動いており、GitLab Dedicatedの利用者は対応不要であること、セキュリティ修正の詳細を記したissueはリリースから90日後に公開されることも書かれています。

CISAの9月11日付けのアラートは、GitLabのこの1件だけを追加したものです。同じ日には別のアラートでConnectWise ScreenConnectのCVE-2026-84869、JFrog ArtifactoryのCVE-2026-42016とCVE-2026-42018もKEVへ追加されています。ScreenConnectのエントリはGitLabと同じくdueDateが9月14日でforensicTriageがYes、Artifactoryの2件はdueDateが9月25日でforensicTriageがNoです。この記事ではGitLabに絞ります。

NVDの記録は執筆時点(2026年9月14日)で解析状況がReceivedで、NIST自身のCVSS評価はまだ付いていません。FIRSTのEPSSは、2026年9月13日付けで0.01164(パーセンタイル0.65458)でした。EPSSは今後30日の悪用確率の推定値であり、すでにKEVで悪用の証拠が確認されている今回は、優先度をEPSSで下げる根拠にはなりません。

パストラバーサルで任意のファイルが読める仕組み#

パストラバーサルは、アプリケーションが利用者の入力をファイルのパスの一部として使うときに、決められたディレクトリの外へ抜け出す指定を止められないことで起きます。../ のような親ディレクトリへの移動や、それをエンコードしたり重ねたりした表記が正しく無害化されないと、本来はリポジトリのデータだけを返すはずの処理が、サーバー上の別の場所にあるファイルを読み込んで返してしまいます。

KEVのエントリが付けたCWE-35は、.../...// のように区切り文字やドットを重ねた表記で、単純な ../ の除去をすり抜ける類型を指します。一方、GitLabがNVDへ登録したCWEは、パストラバーサル全般を表すCWE-22です。一般にこの種の脆弱性は、入力されたパスを正規化したあとで、許可したディレクトリの内側にあるかを確かめていない場合に生じます。ただし、今回のGitLabの実装でどの処理が不足していたかは公表されていません。

今回はそこに、GitLabの説明どおり認証の強制の欠落が重なっています。ファイルを読む処理に、ログインしていない相手からのリクエストが届いてしまうため、攻撃者はアカウントを持っていなくても試せます。どのパラメーターがどう扱われていたかという具体的な条件は、執筆時点では公開されていません。GitLabの方針では、該当issueの公開はリリースから90日後です。

CVSSのベクトルは、機密性(C)に加えて完全性(I)もHighと評価しています。説明文が触れているのはファイルの読み取りだけで、完全性をHighとした理由はリリースノートには書かれていません。スコープ(S)もChangedと評価されていますが、その理由も公開資料には示されていません。CVSS 3.1の仕様では、Changedは脆弱なコンポーネントの権限管理の範囲を越えて、別のコンポーネントの資源に影響が及ぶ場合に選ぶ値と定義されています。

読まれ得るファイルが侵害の起点になる理由#

どのファイルが読めるかは、GitLabのプロセスを動かしているOSの利用者に、そのファイルの読み取り権限があるかどうかで決まります。すべてのファイルが読めるとは限りません。ただ、GitLabはアプリケーション自身が動くために、データベースへの接続情報や暗号鍵を読める状態で持っています。

GitLabのバックアップのドキュメントは、Linuxパッケージでの導入なら最低限 /etc/gitlab/gitlab-secrets.json と /etc/gitlab/gitlab.rb を別途バックアップするよう求め、その理由を説明しています。データベースには二要素認証の暗号化された情報やCI/CDのsecure variablesが入っており、secretsファイルにはそのデータベースの暗号鍵が入っているためです。暗号化された情報と鍵を同じ場所に置くと暗号化の意味がなくなる、とも書かれています。

ここから、読み取りの被害が広がる筋道は次のように整理できます。

• 設定ファイルに書かれたデータベース、オブジェクトストレージ、SMTP、LDAPなどの接続情報が漏れると、GitLabの外にある資源へ直接アクセスされます
• データベースの暗号鍵とデータベースの中身の両方に手が届くと、暗号化して保存していたCI/CD変数や連携用の認証情報が意味を失います
• CI/CD変数には、クラウドの認証情報、コンテナレジストリのパスワード、本番環境へのデプロイ鍵が入っていることが多く、GitLabから本番環境へ侵入が広がる入口になります
• Runnerの登録トークンやAPIのアクセストークンが使われると、パイプラインに不正な処理を差し込まれ、ビルド成果物が汚染されるおそれがあります

つまり、今回の脆弱性の本当の影響は、GitLabのサーバーがどの秘密情報を抱え、それがどこへつながっているかで決まります。ソースコード管理だけに使っている環境と、本番デプロイまでGitLabのCI/CDで回している環境とでは、事後対応の範囲が大きく変わります。

影響を受ける版と修正版の読み方#

影響範囲は、GitLabの表記では「18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2」です。これを系列ごとに読み替えると次のとおりです。

読み違えやすいのは2点です。1点目は、18.7から19.0の範囲にいる場合、その系列向けの修正版は出ていないことです。「18.7 before 19.1.8」は、18.7以降かつ19.1.8未満がすべて影響を受けるという意味で、抜け出すには19.1.8以降の系列へ上がる必要があります。2点目は、18.6以前でCVE-2026-85706の対象外だとしても、同じリリースで直された別の脆弱性は、17件のうち14件が18.7より前の版から影響を受けていることです。最も古いものは10.1.0からです。

稼働中の版は、GitLabにログインして左サイドバーの下部から「Help」を開くと、ページの上部に表示されます。サーバーのシェルに入れる場合は、Linuxパッケージの導入で sudo gitlab-rake gitlab:env:info を実行すると、GitLabのバージョンを含む環境情報が表示されます。検証環境、災害対策用の待機系、Geoのセカンダリサイトなど、普段は意識しない場所にあるGitLabも一覧に含めます。

同じリリースの修正をまとめて取り込む理由#

19.3.2、19.2.6、19.1.8には、CVE-2026-85706を含めて18件のセキュリティ修正が入っています。CriticalはCVE-2026-85706とCVE-2026-87719の2件で、Highが6件あります。主なものを抜き出します。

いずれの修正版も、上の表の各CVEをまとめて直しています。KEVに入ったのはCVE-2026-85706だけですが、CVE-2026-87719やCVE-2026-79708、CVE-2026-13210は、どれもCI/CD変数や認証情報という同じ種類の資産に関わります。ファイル読み取りの穴だけ塞いで他の穴を残しても、守りたいものは変わらず危険にさらされたままです。個別の回避策を探すより、修正版への更新でまとめて閉じるのが確実です。

修正版への更新手順#

GitLabのリリースノートは、影響を受けるすべての導入環境をできるだけ早く最新版へ上げるよう強く推奨しています。回避策の記載はありません。更新は次の順で進めます。

すぐに更新できない場合は、GitLabへの到達経路を社内ネットワークやVPNの内側に絞るのが、影響を小さくする現実的な手です。これはGitLabが示した回避策ではなく、インターネットからの未認証アクセスという条件を外すための一般的な措置です。社内から到達できる相手には依然として攻撃の余地が残るため、更新までのつなぎとして扱います。

更新だけでは閉じない事後対応#

修正版を入れると、それ以降のファイル読み取りは防げます。しかし、修正前にすでに読まれていたファイルの中身は取り戻せません。KEVへの追加は、この脆弱性が実際に悪用された証拠があることを示しますが、個々の環境が侵害されたことまでは意味しません。影響版を動かしていた期間の到達経路とログを確かめ、読まれた可能性を否定できない場合は、読まれた前提で事後対応を進めます。

APIアクセスログで確認する観点#

GitLabのログシステムのドキュメントによると、Linuxパッケージの導入ではAPIリクエストの記録が /var/log/gitlab/gitlab-rails/api_json.log に1行1件のJSONで残ります。NGINXを通ったリクエストは /var/log/gitlab/nginx/gitlab_access.log に記録されます。Helmチャートでは、Webserviceのポッドのapi_jsonサブコンポーネントのログが対応します。確認するときは次の点に着目します。

• repository commitsのAPI(/api/v4/projects/ 配下の repository/commits を含むパス)への、認証された利用者の記録がないリクエスト
• パスやパラメーターに、.. や、それをURLエンコードしたり重ねたりした表記が含まれるリクエスト
• 普段の利用者やCIの接続元とは異なる送信元IPから、短時間に繰り返されたリクエスト
• 応答サイズが通常のcommits APIの応答と明らかに違うリクエスト

具体的な攻撃リクエストの形は公開されていないため、ここに挙げたのは絞り込みの観点です。該当する記録が見つからないことだけで、侵害がなかったとは判断できません。ロードバランサーやWAFなど、GitLabの手前にある機器のログもあわせて確認します。怪しい記録が見つかった場合は、その送信元から他にどのAPIを呼んでいるか、同じ時間帯に新しいトークンや利用者が作られていないかも突き合わせます。

秘密情報の入れ替え#

GitLabの「Responding to security incidents」は、認証情報が露出した場面の対応として、トークンの種類と権限の範囲を確かめ、所有者を特定し、影響を評価したうえで失効または再発行するよう求めています。対象として、パスワード、個人アクセストークン、グループやプロジェクトのアクセストークン、Runnerのトークン、パイプラインのトリガートークン、SSH鍵が挙げられています。

今回の状況に当てはめると、入れ替えの候補は次の3層に分かれます。

• GitLabの設定ファイルに書かれた外部サービスの認証情報(データベース、オブジェクトストレージ、SMTP、LDAPやSAMLの連携、外部の監視やバックアップ先)
• CI/CD変数に入れているクラウドの認証情報、レジストリのパスワード、デプロイ鍵、外部APIのキー
• GitLab自身が発行したアクセストークン、Runnerのトークン、トリガートークン、デプロイトークン

データベースの暗号鍵が入った gitlab-secrets.json は、失うとデータベースの暗号化された値を復号できなくなるとバックアップのドキュメントに書かれています。鍵そのものを差し替えるのは影響が大きいため、実施する場合はGitLabのドキュメントやサポートで手順を確かめてから判断します。鍵の扱いを確かめている間も、その鍵で保護されていた認証情報の露出範囲の評価と、必要な入れ替えは並行して進められます。

BOD 26-04のフォレンジックトリアージ#

KEVのrequiredActionは、ベンダーの指示に沿った緩和策の適用に加えて、BOD 26-04とCISAの「Forensics Triage Requirements」への準拠を求めています。BOD 26-04が直接義務づけるのは米国連邦政府の文民行政機関(FCEB)ですが、CISAはすべての組織にリスクに基づく脆弱性管理とKEVの優先的な是正を勧めています。

BOD 26-04の実装ガイダンスは、フォレンジックトリアージを6段階に分けています。Step 1がスコーピング(KEV追加から2時間以内が目安)、Step 2が証拠の保全と収集(2時間から24時間)、Step 3が重大なパッチの適用と安定化、Step 4が封じ込めと制御、Step 5がトリアージ分析、Step 6がエスカレーション判断(48時間から72時間)です。Step 2では、可能な限り証拠の収集前にシステムを変更したり修正したりしないよう求めています。Step 5では、不正アクセス、攻撃者の存在、横展開、永続化の仕組み、データの集積や持ち出しの有無を確認するよう挙げています。示された時間は推奨であり、要件は適切なトリアージ分析が行われることだと注記されています。また、KEVのdueDateについては、公開された資産に存在し、技術的な影響が全面的で、攻撃が自動化できるとCISAが判断した場合に3日の期限になると説明しています。

連邦機関でなくても、この順番は参考になります。ログを退避してから更新し、更新後に分析して、侵害なし、侵害の疑い、侵害確認のいずれかに結論を整理します。侵害の疑いや確認に至った場合は、GitLabの外側、つまり漏れた認証情報でアクセスできるクラウドや本番環境の側でも、同じ期間のアクセス記録を確かめます。

対応チェックリスト#

開発基盤を本番環境と同じ重みで扱う#

GitLabは社内向けの道具として置かれることが多い一方、実際には本番環境の鍵を預かり、ビルドとデプロイの経路を握っています。今回のように未認証で届く穴が一つ開くと、影響はソースコードにとどまらず、そこにつながるクラウドや本番環境へ及びます。インターネットに公開する必要があるかを見直すこと、CI/CD変数に置く認証情報を必要最小限の権限と有効期限にすること、GitLabのパッチリリースを通知で受け取れるようにしておくことが、次の脆弱性のときの初動を短くします。

なお、ここで挙げたログ確認の観点は、自組織が管理する環境で侵害の有無を判断するためのものです。管理権限のないGitLabに対して脆弱性の有無を試す行為は、不正アクセス禁止法などの法令に触れるおそれがあります。検証は、許可を得た自組織の環境だけで行ってください。