Gogsのプルリクエストのマージでの引数注入の脆弱性CVE-2026-52806

カテゴリ
脆弱性の悪用
タグ
国外
目次
  1. 脆弱性の内容
  2. 時系列
  3. 対象の製品と版
  4. 悪用の状況
  5. 修正と回避策
  6. 未公表の事項
  7. 注
  8. 出典
  9. 更新記録

Rapid7の2026年5月28日の報告によると、Gogsでは認証済みの利用者が、悪意のあるブランチ名のプルリクエストをマージする際にgit rebaseへ引数を注入し、サーバー上でコードを実行できる⁠[5]。Gogsの保守者は修正版を公開し、脆弱性にはCVE-2026-52806が割り当てられた⁠[5]。Wizは、Kubernetesのクラスターを狙った攻撃でGogsの脆弱性が悪用されたと報告した⁠[6]。

脆弱性の内容

表1:CVE-2026-52806の評価
項目値資料
CVECVE-2026-52806(CNAはGitHub_M)⁠[3]
CVSS 3.1(CVE記録)9.9(CRITICAL)〔注1〕、AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H⁠[3]
NVDの記録状態はDeferred、CVSSの値はsecurity-advisories@github.comによるSecondaryの評価⁠[4]
弱点の分類CWE-77(CVE記録)、CWE-88(Rapid7)⁠[3、5]
悪用されたときの影響Gogsのサーバープロセスの利用者の権限での任意のコマンドの実行⁠[5]
CISAのADPによるSSVCの評価(6月25日)Exploitationはpoc、Automatableはno、Technical Impactはtotal⁠[3]

Rapid7の報告によると、原因はinternal/database/pull.goのMerge()関数にあり、プルリクエストのベースブランチ名を--の区切りなしでgit rebaseに直接渡している⁠[5]。git rebaseは--execフラグを受け付け、各コミットを再適用した後にシェルのコマンド(sh -c)を実行する⁠[5]。「Rebase before merging」はリポジトリごとの設定(PullsAllowRebase)で、既定では無効だが、所有者か管理者が「Settings > Advanced」で有効にできる⁠[5]。

Rapid7は、悪用に管理者権限も他の利用者の操作も要らず、攻撃者は自分のアカウントの中だけで操作すると説明した⁠[5]。Gogsは既定で利用者登録を開いており(DISABLE_REGISTRATION = false)、リポジトリの作成数にも上限が無い⁠[5]。そのため未認証の攻撃者も、既定の設定のインスタンスでアカウントとリポジトリを作れる⁠[5]。リポジトリを作った登録利用者は、自動でその所有者になる⁠[5]。

Rapid7の報告では、攻撃者はサーバーの侵害、インスタンス上の全リポジトリ(他の利用者の非公開リポジトリを含む)の読み取り、認証情報の取り出し、他のシステムへの横展開、ホストしたリポジトリのコードの改変ができる⁠[5]。取り出せる認証情報には、パスワードのハッシュ、APIトークン、SSH鍵、2FAの秘密を挙げた⁠[5]。利用者が2人以上いるGogsのインスタンスは実質的にマルチテナントで、この脆弱性は1人の認証済み利用者に下層のサーバーの全面的な制御を与えるとした⁠[5]。

Rapid7は、Gogsが過去にもCVE-2024-39933、CVE-2024-39932、CVE-2026-26194、CVE-2024-39930の勧告で引数注入を修正してきたと説明した⁠[5]。今回の脆弱性は同じ種類で、修正されてこなかった別のコード経路(Merge())にある⁠[5]。git-moduleライブラリはv1.8.7で--end-of-optionsにより強化されたが、Merge()はexec.Commandを直接包むprocess.ExecDirを使い、その保護を通らない⁠[5]。

目次へ

時系列

時系列
日付主体内容資料
2026年3月16日Rapid7脆弱性を発見し、検証した⁠[5]
2026年3月17日Rapid7GitHub Security AdvisoryでGogsの保守者に報告した⁠[5]
2026年3月28日Gogsの保守者受領を確認した⁠[5]
2026年4月21日Rapid7保守者に状況を問い合わせたが、応答は無かった⁠[5]
2026年5月6日Rapid7予定していた開示日を保守者に改めて伝え、必要なら延長すると申し出たが、応答は無かった⁠[5]
2026年5月28日Rapid7脆弱性を開示した⁠[5]
2026年5月29日Rapid7パッチをプルリクエスト#8301で提出した⁠[5]
2026年6月6日Gogsの保守者プルリクエストを受け入れ、GitHubにCVEの割り当てを求めた⁠[5]
2026年6月7日Gogsの保守者0.14.3を公開し、この脆弱性をほかのセキュリティの問題とあわせて修正した⁠[5]
2026年6月8日GitHubCVEを予約した⁠[5]
2026年6月13日〜23日-Realm C2のフレームワークを使った攻撃で、数千のLinuxホストが侵害された⁠[6]
2026年6月19日-GitHub Security Advisoryが公開された⁠[5]
2026年6月24日GitHub(CNA)CVE記録を公開した⁠[3]
2026年6月24日NVDCVEの記録を公開した⁠[4]
2026年6月25日Wizクリプトジャッキングの攻撃の項目を公開した⁠[6]

目次へ

対象の製品と版

Rapid7は、GogsをGoで書かれた軽量のセルフホスト型Gitサービスと説明し、GitHubのスターは約5万、フォークは5,000超とした⁠[5]。

CVE記録によると、影響を受ける版は0.14.3より前で、0.14.3で修正された⁠[3]。Rapid7は、調査した際の最新版である0.14.2と0.15.0+dev(commit b53d3162)で影響を確かめた⁠[5]。「Rebase before merging」に対応する以前の版も、すべて脆弱である可能性が高いとした⁠[5]。

影響は、対応するすべてのプラットフォーム(Linux、macOS、Windows)に及ぶ⁠[5]。インストール方法も、ビルド済みバイナリ、Docker、ソースのすべてが対象になる⁠[5]。

Rapid7は、Shodanでの検索で、報告の公開の際にインターネットに面した1,141のインスタンスが見つかったと説明した⁠[5]。多くはVPNや内部ネットワークの内側にあり、実際の導入数ははるかに多いとした⁠[5]。

目次へ

悪用の状況

Rapid7は、悪用は完全に自動化でき、数秒で終わると説明した⁠[5]。Rapid7が提供したMetasploitのモジュールはLinuxとWindowsの両方を対象にし、攻撃者のアカウントに一時リポジトリを作る既定のモードと、書き込みとマージの権限を持つ既存のリポジトリを狙うモードを持つ⁠[5]。攻撃者が自分のリポジトリを作って消した場合、痕跡はサーバーのログのHTTP 500だけになる⁠[5]。

表2:Rapid7が示した侵害の痕跡
種別値示した組織資料
サーバーのログのERRORの行git checkout '--exec=<...>'Rapid7⁠[5]
サーバーのログのERRORの行`unknown option exec=<...>'``Rapid7⁠[5]
ブランチ名(既存のリポジトリが狙われた場合)--で始まる名前Rapid7⁠[5]
GogsのAPIトークン(Metasploitのモジュールが作る)msf_<hex>Rapid7⁠[5]

Rapid7の報告では、より巧妙に書かれた攻撃ではログの痕跡がこれほど明らかでないことがある⁠[5]。GogsにはトークンをAPIで削除する手段が無いため、モジュールが作ったトークンは手動で取り消すまで有効なまま残る⁠[5]。管理者には、--で始まるブランチ名が無いかリポジトリを点検するよう求めた⁠[5]。

Wizの6月25日の項目では、攻撃の種別はCampaign、初期侵入は「1-day vulnerability」、攻撃者は「Unknown」だった⁠[6]。影響には資源の乗っ取りとデータの持ち出しが、対象の技術にはGogs、Kubernetes、Argo Workflowsが挙がっている⁠[6]。参考文献の一つは、Rapid7の今回の報告だった⁠[6]。

Wizの項目は、研究者らがRealm C2のフレームワークを使った攻撃を特定し、この攻撃が主に大規模なマネージドKubernetesクラスターを狙ったと書いた⁠[6]。攻撃者は暗号資産の採掘プログラムを置き、盗んだKubernetesのサービスアカウントのトークンを使って、特権コンテナからの脱出により300を超える追加のノードに横展開した⁠[6]。The Hacker Newsは記事の更新で、この脆弱性が6月下旬の段階でKubernetesのクラスターを狙うクリプトジャッキングの攻撃の一部として悪用されたと、Wizの報告を引いて報じた⁠[8]。

目次へ

修正と回避策

Gogsプロジェクトは、GitHubのリポジトリにセキュリティアドバイザリを公開した⁠[1]。修正版のリリースのページも出した⁠[2]。

Rapid7の報告によると、修正はRapid7が提出したプルリクエストで実装された⁠[5]。Rapid7は、すべての利用者に直ちに更新するよう勧めた⁠[5]。すぐに更新できない場合の緩和策も挙げた⁠[5]。

  1. 利用者登録の制限(DISABLE_REGISTRATION = true)は、攻撃が1人の利用者のリポジトリの中で完結するため、最も効果が大きいとした⁠[5]。
  2. リポジトリの作成の制限(MAX_CREATION_LIMIT = 0)は、新しいリポジトリを作る最も容易な経路を塞ぐが、既存のリポジトリに書き込み権限を持つ利用者による悪用は防げない⁠[5]。
  3. 「Rebase before merging」のリポジトリごとの無効化は、所有者か管理者の権限を持つ悪意のある利用者が再び有効にできるため、効果的な防御ではないとした⁠[5]。全体や組織の単位でこれを制限する設定は無い⁠[5]。

runZeroの5月29日の更新では、この脆弱性にはCVE IDが無く、開発元はパッチを出していなかった⁠[7]。runZeroは、利用者登録を直ちに無効にし、Gogsのインスタンスのインターネットへの露出を制限し、該当すればリポジトリの作成も制限するよう勧めた⁠[7]。

Wizは、Argo WorkflowsかGogsを運用する組織に、直ちにパッチを当てて侵害の痕跡を確かめるよう求めた⁠[6]。

目次へ

未公表の事項

  • 3月28日の受領確認の後、Gogsの保守者がRapid7の問い合わせに応答しなかった理由
  • Wizが報告した攻撃のうち、Gogsの脆弱性を経由して侵害されたホストの数
  • Wizが報告した攻撃の攻撃者
  • Wizが報告した攻撃で、侵害されたホストから持ち出されたデータの内容
  • CISAの既知の悪用された脆弱性カタログ(KEV)への登録

注

  • 〔注1〕5月のThe Hacker NewsとSecurityWeekの記事は、CVSSの値を9.4と報じた⁠[8、9]。

出典

当事者

公的機関

調査・観測

報道機関

更新記録

  • 2026年5月31日:公開した。
  • 2026年6月7日:Gogsプロジェクトの修正版のリリース(出典2)を「修正と回避策」に加えた。
  • 2026年6月8日:Rapid7の報告の6月8日の改訂(出典5)で示された保守者によるパッチの受け入れと修正版の公開を「時系列」「修正と回避策」に加え、リードの第2文を改めた。
  • 2026年6月9日:Rapid7の報告の6月9日の改訂(出典5)で加わったCVE番号をリードと「脆弱性の内容」に加えた。
  • 2026年6月19日:Gogsプロジェクトのセキュリティアドバイザリ(出典1)を「修正と回避策」に加えた。
  • 2026年6月24日:CVE記録(出典3)とNVDの記録(出典4)の評価と影響を受ける版を「脆弱性の内容」「対象の製品と版」「時系列」に加えた。
  • 2026年6月25日:Wizの攻撃の項目(出典6)を「悪用の状況」「修正と回避策」「時系列」に加え、リードの最後の文を加えた。
  • 2026年6月26日:CVE記録とNVDの記録の6月26日の更新(出典3、4)で加わったCISAのADPによるSSVCの評価を「脆弱性の内容」に加えた。
  • 2026年6月28日:Wizの項目の6月28日の更新(出典6)に合わせて出典の行の更新日を改めた。
  • 2026年7月10日:Rapid7の報告の7月10日の改訂(出典5)でCVSSの値が改められたことから、5月の報道の値を「注」に加えた。
  • 2026年9月16日:The Hacker Newsの記事の更新(出典8)で報じられた悪用を「悪用の状況」に加えた。

目次へ