自社のサーバーで GitLab を運用しているなら、今日中にアップデートしてください。2026 年 10 月 12 日、GitLab は 24 件の脆弱性を修正する重大なセキュリティパッチを公開しました。最も深刻な CVE-2026-97229 は、考えうる最高の深刻度スコアである 10 点満点中 10 点と評価されています。この脆弱性により、あなたのサーバーにアカウントを持たない人物が、そのサーバー上で自分のコードを実行できてしまいます。19.2.8 より前の 19.2、19.3.5 より前の 19.3、または 19.4.2 より前の 19.4 を実行しているすべてのサーバーが影響を受けます。GitLab が示している唯一の修正方法は、19.4.2、19.3.5、または 19.2.8 へのアップグレードです。GitLab.com のクラウドサービスを利用している場合は、何もする必要はありません。

GitLab とは何か、そしてなぜ経営者が気にすべきなのか

GitLab は、技術チームが自社のシステムやアプリのソースコードを保管し、新しいバージョンをビルドしてサーバーへ配信する場所です。多くの企業は、コードとデータを組織内に留めるために、クラウドサービスではなく社内サーバーで GitLab を運用しています。そのサーバーには通常、経営者が想像する以上のものが保存されています。すべてのソースコード、データベースのパスワード、決済ゲートウェイや政府サービスと接続するための鍵、そして顧客が利用するサーバーへデプロイする権限です。このサーバーを支配した者はそれらすべてを読み取ることができ、コードが顧客に届く前に書き換えることもできます。

GitLab は具体的に何を発表したのか

GitLab の公式パッチリリース告知によると、この脆弱性はビルドおよびデプロイのパイプライン設定（CI/CD）内の正規表現を処理する部分に存在します。正規表現とは、検索パターンを記述する短いテキストのことです。告知によれば、これらの式の検証が不十分なため、認証されていないユーザーが細工した正規表現を使って GitLab サーバー上で任意のコードを実行できる可能性があります。この脆弱性は、ある研究者が HackerOne 上の GitLab のバグ報奨金プログラムを通じて報告しました。

告知では、この脆弱性が悪用されたとは述べられていません。しかしスコア 10 は、インターネット経由で、パスワードもなく、従業員の手助けもなしに悪用できることを意味します。攻撃者は通常、修正が公開されてから数日以内にこうした脆弱性を探し始めます。修正そのものが弱点の場所を示しているからです。

パッチには他に何が含まれているのか

同じパッチでは、さらに 23 件の脆弱性が修正されており、そのうち五件は深刻度「高」と評価されています。

  • シンタックスハイライトにおける悪意あるスクリプトの挿入（XSS）、スコア 8.7。
  • パイプライン作成時の認可の不備、スコア 8.5。
  • ファイルアクセスに影響する過度に許容的な正規表現、スコア 8.2。
  • 有料版のパイプライン実行ポリシーにおける認可の不備、スコア 7.7。
  • 有料版の GitLab Duo AI エージェントにおけるプロンプトインジェクションの脆弱性、スコア 7.3。

つまり、重大な脆弱性の影響を受けない 19.2 より古いバージョンが、必ずしも安全というわけではありません。GitLab の公式メンテナンスポリシーでは、セキュリティ修正がバックポートされるのは現行リリースと直前の二つの月次リリースのみとされています。それより古いバージョンのサーバーはもはやセキュリティ修正を一切受けられないため、いずれにしてもアップグレードが必要です。

対応が必要なのは誰か

  • GitLab.com のクラウド利用者：対応は不要です。GitLab によると、サービスはすでに修正済みのバージョンで稼働しています。
  • GitLab Dedicated の顧客：告知によれば、こちらも対応は不要です。
  • 自社サーバーで GitLab を運用しているすべての人：直ちにアップグレードしてください。これは、すべてのセルフマネージド環境に対する GitLab の明確な推奨事項です。
  • 自社の GitLab がどこで動いているかわからない人：今日中にチーム、またはシステムを構築したベンダーに確認してください。社内サーバーの多くは以前のベンダーが構築し、その後忘れられています。

今週の実践的なステップ

  1. バージョンを確認する：技術責任者に GitLab のヘルプ（Help）ページを開いてもらい、そこに表示されるバージョン番号を読み取って、上記の番号と比較してもらいましょう。
  2. アップグレードは月末ではなく今日予定する：GitLab の告知によれば、単一ノードのサーバーはパッチ適用中にデータベースの移行が完了するまで停止しますが、複数ノード構成は適切なゼロダウンタイム手順に従えば停止なしでパッチを適用できます。業務時間外の一時間の停止は、サーバーを乗っ取られるよりはるかに安上がりです。
  3. 19.3 を使っている場合：19.3.4 ではなく、直接 19.3.5 に上げてください。告知によると、19.3.4 には Ona 連携を有効にしているとマージリクエストのページに影響する不具合があり、19.3.5 で修正されています。
  4. インターネットへの露出を減らす：社外の誰も GitLab サーバーにアクセスする必要がないなら、社内ネットワークまたは VPN 経由の接続のみを受け付けるように設定してください。これはパッチ適用の代わりにはなりませんが、次回に備えて入口を狭めることができます。
  5. パッチ適用後に確認する：最近作成されたユーザー、鍵、アクセストークンを確認してください。誰にも心当たりのないものがあれば、サーバーに保存されているパスワードと鍵を変更してください。

インストール方法ごとのアップグレード手順は、GitLab の公式アップグレードガイドに掲載されています。

Origami の見解

私たちはリポジトリを GitLab に置いているため毎日使っており、そのセキュリティ告知を請求書と同じくらい注意深く追っています。この教訓は GitLab に限りません。データを社内に留めるために自前で運用するシステムには、修正が出たその日にパッチを当てる責任が伴います。私たちが最もよく目にする問題は、その判断自体ではなく、アップデートの担当者が決まっていないことです。三年前にベンダーが構築し、誰が保守しているのか誰も知らないサーバーこそ、攻撃者が最初に探すものです。Magento ストアの脆弱性についても同じことを述べました。パッチが遅れれば、パッチを当てるだけでは不十分です。サーバーの点検やアップデートの引き受けを任せられる相手が必要なら、お問い合わせください。

出典