この脆弱性は自己管理型のCEおよびEEインスタンスに影響し、認証なしで任意のファイルを読み取れる経路を提供します。すでに実環境で探索行為が確認されています。
GitLabのインフラで、またしてもセキュリティ脆弱性が発見されました。今回は深刻度が満点の10という重大なものです。
CVE-2026-85706は、GitLabがわずか1か月の間に公表した2件目の脆弱性で、攻撃者が1回のHTTPリクエストで任意のファイルを読み取れてしまう最大深刻度の脆弱性です。同社の報告によると、このパストラバーサルの脆弱性は、GitLabのリポジトリコミットAPIにおける不適切な制限と認証強制の欠如に起因しています。
脅威アクターは「特定の条件下」でこれを悪用し、脆弱なGitLabサーバー上の任意のファイル(認証情報、シークレット、その他の機密データ)を読み取ることが可能です。
GitLabはこの脆弱性を修正済みで、影響を受けるのはGitLab Community Edition(CE)およびEnterprise Edition(EE)です。同社は、インターネットに公開された自己ホスト型GitLabインスタンスを運用している顧客に対し、直ちにサーバーへパッチを適用するか、公開アクセスを遮断するよう勧告しています。
専門家は、GitLabのDevSecOpsプラットフォームがFortune 100企業の約50%で使用され、推定5,000万人以上の登録ユーザーを抱えていることから、この脆弱性は憂慮すべきものだと指摘しています。
Info-Tech Research Groupのアドバイザリーディレクターを務めるSafayat Moahamad氏は、「GitLabは単なるソースコードリポジトリではありません」と指摘します。多くの企業では、ビルドパイプラインやデプロイプロセス、アプリケーションセキュリティのワークフロー、その他の信頼されたシステムと連携しているといいます。
その結果、GitLabサーバー上の設定ファイルやシークレット、認証情報への不正アクセスは、「影響を受けたインスタンスをはるかに超える結果を招く」可能性があると同氏は述べています。
通常のパッチサイクルを待つべきではない
GitLabは近頃、ハッカーに好んで狙われる標的となっています。1月には、標的のアカウントIDを持つ攻撃者が二要素認証を回避できてしまう深刻度の高い脆弱性を修正し、8月には、認証されていないユーザーがコードリポジトリ内を改変したり、1回のHTTPリクエストで完全に削除したりできてしまう重大な脆弱性を修正しています。
今回の最大深刻度の脆弱性であるCVE-2026-85706は、GitLabのHackerOneバグ報奨金プログラムを通じて報告されました。影響を受けるのは、CEおよびEEのバージョン18.7から19.1.8より前、19.2から19.2.6より前、そして19.3から19.3.2より前です。
米国サイバーセキュリティ・インフラセキュリティ庁(CISA)は、CVE-2026-85706を既知の悪用された脆弱性(KEV)カタログに追加し、この種の脆弱性は悪意あるサイバー攻撃者が頻繁に用いる攻撃経路であり、特に連邦政府機関に重大なリスクをもたらすと指摘しています。watchTowr Intelは、すでに「実環境でのプローブ(探索行為)」を確認していると報告しています。同社は「これまでのGitLabの脆弱性の傾向から見て、無差別な悪用が始まるまでそう時間はかからないだろう」と警告しています。
Moahamad氏は、これは組織が通常のパッチサイクルに任せて放置してよい脆弱性ではないと強調します。「ソースコードやビルド、デプロイのワークフローの中心に位置することが多いプラットフォーム上で、認証なしに任意のファイルへアクセスできる経路を与えてしまうものです」と同氏は述べています。
企業は直ちにパッチを適用し、リポジトリコミットAPIへの不審なアクセスがないか調査するとともに、流出したファイルに認証情報やシークレットが含まれていて、それらのローテーション(再発行)が必要になっていないかを確認すべきだと同氏は助言しています。
watchTowr Intelチームは、パッチ適用に加えて、防御側はログファイルを調べ、「file.path」パラメータを含む「/api/v4/projects/{id}/repository/commits/」URIへのHTTP POSTリクエストがないかを確認することで、悪用の試みを特定すべきだと述べています。
CI/CDプラットフォームは重要な信頼基盤
Moahamad氏は、影響を受ける自己管理型のGitLab CEまたはEEインスタンスを運用している組織が最も懸念すべき対象だと指摘します。GitLabが機密性の高いリポジトリやCI/CDパイプライン、クラウド環境、本番デプロイのプロセスと連携している場合、リスクはさらに高まります。
攻撃者が取得しうる情報やアクセス権限は、GitLabのサービスが読み取れる範囲と、組織がサーバー上に何を保存しているかによって決まると同氏は説明します。設定ファイルやシークレット、認証情報、その他の機密性の高いサーバー側データが含まれる可能性があります。もしこれらのファイルに利用可能なトークンや鍵、認証情報が含まれていれば、攻撃者は連携するインフラへのアクセスを試みる可能性があります。
「この脆弱性は、不正なファイルアクセスのリスクを直接的に生み出します」と同氏は述べています。認証情報の窃取や横展開、ソースコードの流出、サプライチェーン侵害といった二次的な事態も起こり得ます。
ソースコードとCI/CDプラットフォームは「重要な信頼基盤」として管理されるべきだと同氏は述べています。パッチ適用は依然として不可欠ですが、レジリエンスを確保するには、プラットフォームがどこで露出しうるかを把握し、アクセスできる範囲を制限し、異常なAPIの挙動を検知し、認証情報を調査・ローテーションするための検証済みプロセスを備えておくことが求められます。
Beauceron SecurityのDavid Shipley氏は、2つの要因が重なり合い、GitLabユーザーにとって「最大級の痛手」を生み出していると説明しています。
1つ目は脆弱性そのものです。「これが10段階評価で10とされるのには理由があります。GitLabのクライアントソースコードに、認証なしで読み取りアクセスができてしまうのですから」と同氏は述べています。
2つ目として、これが特に痛手となるのは、開発者たちに依然として悪い習慣が残っているためだとShipley氏は指摘します。SSHキーやクラウドのシークレット、トークンなど、攻撃者がインフラへの侵入に利用できる貴重なデータが埋め込まれたまま、あまりにも多くのコードが出荷されたり、本番環境で稼働し続けたりしているといいます。
「つまり攻撃者にとっては、お決まりの手口がそろっているのです」と同氏は指摘します。データの窃取と恐喝、ランサムウェア、暗号資産マイニングのためのクラウドインフラの乗っ取り、そして他の犯罪活動を可能にするAIトークンやインフラの窃取などです。
「このレベルの脆弱性は、コードとクラウドの世界でいえば、クレジットカード番号や有効期限、セキュリティコードを丸ごと入手できてしまうようなものです」とShipley氏は述べています。「これにより、犯罪者にとってのデータの闇市場が大きく開かれてしまいます」
結論として、同氏は「本番コードからそうしたシークレットを排除し、最新のコーディング認証のベストプラクティスを取り入れるべきです」と助言しています。
