自社に立てたGitサーバーが乗っ取られると、失うのはソースだけではない｜Gitea CVE-2026-60004

結論：発注者が確認すべきは「バージョン」と「誰が上げるのか」の2つ

米国CISAは2026年8月25日、CVE-2026-60004を悪用が確認された脆弱性のカタログ（KEV）へ追加しました。米国連邦政府機関向けの是正期限は2026年8月28日です。対象は、自社サーバーに設置して使うタイプのGitホスティングソフトウェア、Giteaです。

Gitea公式のセキュリティアドバイザリ（GHSA-rcr6-4jqh-j84m）は2026年7月28日に公開されており、影響範囲は1.17以上1.27.1未満、修正版は1.27.1です。CVSS 3.1のBase Scoreは9.8。実証コード（PoC）もアドバイザリに添付されています。

この記事は、システム開発を外部に委託している中堅企業の経営者と、内製化に踏み出したIT責任者に向けています。技術的な修正作業そのものは開発側の仕事ですが、「自社の開発に使われているGitサーバーが、誰の管理下にあり、いま何のバージョンで動いているか」を把握する責任は発注者側にあります。その理由を、公式アドバイザリの記載にもとづいて説明します。

公表内容の要点

何が起きるのか

公式アドバイザリの説明を、必要な範囲だけ整理します。

Giteaには、パッチ（差分）を適用するdiffpatchというエンドポイントがあります。アドバイザリによれば、この処理は共有された一時的なベアクローン上で、攻撃者が用意したパッチを適用します。同じパッチを2回送るとadd/addの衝突が起き、--cachedを指定しているにもかかわらず、Gitの三方向フォールバックがインデックス上のパスを実体としてチェックアウトします。

ベアクローンではリポジトリのルートが$GIT_DIRにあたるため、hooks/post-index-changeという名前の実行可能なファイルが、そのまま生きたGitフックになります。Gitはインデックスを書くときにこのフックを呼び出すので、リポジトリ側が用意した内容が、Giteaサービスアカウントの権限で実行されることになります。

成立には3つの条件が必要だとアドバイザリは明記しています。

1. Git 2.32以降であること
2. diffpatchのルートが有効であること
3. 一時ファイルシステムが書き込み可能かつ実行可能であること

「未認証で攻撃できる」の正確な意味

この脆弱性については、必要な権限の説明が混乱しやすいので、公式アドバイザリの記述順に沿って正確に押さえます。

アドバイザリは、リポジトリへの通常の書き込み権限を持つ攻撃者が、GiteaのOSユーザーとして任意のシェルコマンドを実行できる、と説明しています（原文は英語。以下、この節の引用はいずれも筆者訳）。つまり本来の前提は、リポジトリの書き込み権限です。

そのうえで、既定でユーザー登録が開いている状態では、認証されていない訪問者がアカウントを登録してリポジトリを作成することで必要な書き込み権限を得られる、と続けています。さらに成立条件の説明では、オープンな登録が必要なのは事前の資格情報を持たない攻撃経路の場合のみである、と明記しています。

したがって、正しい理解は次のとおりです。

• 攻撃の直接の前提は「リポジトリ書き込み権限」である
• 既定設定のままユーザー登録を開放していると、外部の第三者がその権限を自分で取得できてしまう
• 登録を閉じていても、書き込み権限を持つ人物が関わる経路（協力会社の担当者、退職者の残存アカウント、漏えいした資格情報）は残る

「登録を閉じているから安全」という説明で終わらせてはいけないのはこのためです。登録の閉鎖は、最も広い経路を1つ塞ぐだけです。

露出しうるのは、ソースコードだけではない

発注者側にとって、この脆弱性の本質はここにあります。公式アドバイザリは「影響」の項で、デプロイの隔離状況とGiteaのOSユーザーの権限しだいで露出しうるものとして、次を列挙しています。

• app.iniとGiteaアプリケーションの秘密情報
• プロセス環境変数に含まれる秘密情報
• マウントされているリポジトリ
• データベースの資格情報とデータベースの内容
• OAuthおよび連携用の資格情報
• その他の、内部または外部から到達可能なサービス

ソースコードは、このリストの3番目に過ぎません。より重いのは4番目と5番目です。

開発用のGitサーバーには、周辺の連携情報が集まりやすい。CI/CDの設定、デプロイ先への接続情報、外部サービスのAPIキー、クラウドの認証情報。これらが同じ場所に置かれている構成であれば、Gitサーバーを起点に、そこから先の環境へ手が伸びうることになります。逆に、秘密情報を別の基盤で管理し、Giteaのサービスアカウントの権限を絞ってあれば、露出する範囲はその分だけ狭くなります。だからこそ、確認すべきは「侵害されたら何が漏れるか」ではなく「そのサーバーのサービスアカウントから、いま何に到達できるか」です。

また、アドバイザリはこのPoCについて、コマンドの出力をGitオブジェクトへ保存し結果を含むブランチを作るため外向きの接続を必要とせず、結果は認証付きのsmart HTTP経由で取得する、と説明しています（原文は英語、訳は筆者）。少なくともこのPoCの経路では、攻撃者のサーバーへ向かう通信が発生しません。外部通信の監視だけを頼りにしていると、この手口は捉えにくいということです。

発注者が確認すべき5つのこと

技術的な修正は開発側が行いますが、確認は発注者の仕事です。次の5点を、開発会社または社内の開発担当へ確認してください。

1. 当社のソースコードは、どこに置かれていますか

GitHub、GitLab、Bitbucketといったクラウドサービスなのか、開発会社の自社サーバーに立てたものなのか、当社の環境に立てたものなのか。この答えが即座に出てこないなら、まずそこが問題です。

2. Giteaを使っている場合、バージョンはいくつですか

1.17以上1.27.1未満なら対象です。1.27.1以降であれば、この脆弱性については修正済みです。

3. 対象だった場合、上げるのは誰の作業ですか。いつまでにやりますか

自社サーバーに設置するソフトウェアの更新は、誰かが意識的にやらないかぎり行われません。クラウドサービスとの最大の違いがここです。「開発会社が立ててくれたので、うちは触っていない」という状態そのものが問題なのではありません。問題は、委託先が更新しているのか、自動更新が効いているのか、それとも誰も見ていないのかを、発注者が確認できていないことです。確認しないかぎり、未更新の可能性を消せません。

4. ユーザー登録は開放されていますか

既定では開いています。設置時に閉じているかどうかを確認してください。これは今回の脆弱性に限らず、恒常的に確認しておくべき設定です。

5. そのサーバーには、どんな資格情報が置かれていますか

デプロイ用の鍵、DB接続情報、外部サービスのAPIキーが、リポジトリの中や環境変数、設定ファイルに含まれていないか。含まれている場合、それらは今回のアドバイザリが露出しうるとしている対象に当てはまります。実際に読み出せるかどうかは、Giteaサービスアカウントの権限と隔離の状況によります。

「7月28日公開、8月25日にKEV追加」という時間感覚

この一件で覚えておく価値があるのは、日付の並びです。

公開からKEV追加まで、およそ1か月です。しかも、この脆弱性のアドバイザリには実証コードが添付されています。

自社サーバーに設置するソフトウェアを使うということは、この時間との競争を自分で引き受けるということです。事業者が運用するサービスであれば、基盤側の更新は提供者の責任範囲に入るのが一般的です（具体的な分担は各サービスの規約で異なります）。自社設置であれば、更新の判断も作業も自社または委託先の責任になります。どちらが良い悪いという話ではなく、選んだ時点でどちらの責任を負ったのかを、発注者が認識しているかという話です。

ここで起きやすいのが認識のずれです。「開発会社に任せている」という言葉のなかに更新の責任まで含まれていると発注側が考え、開発側は「依頼されていない作業」と考える。今回のような場面で、その差が表面化します。

同じ構造のソフトウェアが、他にもないか

今回はGiteaでしたが、確認すべきは製品名ではなく構造です。次の3つの条件が揃うソフトウェアは、同じ位置づけになります。

1. 自社または委託先のサーバーに設置して運用している（提供事業者が自動で更新しない）
2. 業務や開発の中核データが集まっている
3. 導入時に構築した人以外、誰も触っていない

社内で使われがちなのは、課題管理、ドキュメント共有、チャット、ビルド自動化、監視、ファイル共有といった用途のソフトウェアです。いずれも「無料で入れられる」「便利だから使い始めた」という経緯で導入され、そのまま何年も動き続けている、という形になりやすい種類のものです。

ここで注意したいのは、これらの製品に脆弱性があると言っているのではない、という点です。問題は製品の品質ではなく、更新されないまま動き続ける運用にあります。どんなに品質の高いソフトウェアでも、脆弱性は見つかります。見つかったときに更新される仕組みがあるかどうかが、リスクの実体を決めます。

手順は難しくありません。次の3列だけの表を1枚作ります。

「決まっていない」と「不明」が並ぶ行が、そのまま次に手を打つべき対象です。この表は技術知識がなくても作れます。作れないとしたら、それは知識の問題ではなく、社内の誰も把握していないという事実の問題です。

契約で決めておく3項目

次の開発委託契約、あるいは現在の契約の見直しで、次の3点を明記しておくことをおすすめします。今回のような事態が起きるたびに交渉するより、あらかじめ決めておくほうが確実です。

3つ目は、開発委託が終わるときにこそ効きます。契約が終了しても失効されていない資格情報は、そのまま残り続けます。

納品されたコードが書き換わっていないことを、発注者はどう確かめるか

Gitサーバーが乗っ取られた場合に発注者が最も困るのは、流出そのものより、納品物の中身を信用できなくなることです。侵害の疑いが出た時点で、それ以降に納品されたコードが元の設計どおりのものか、誰かが手を加えたものかを区別する必要が生じます。

この確認は、事後には難しくなります。逆に言えば、平時に次の3つを取り決めておくと、事後の確認がやりやすくなります。侵害の有無を確定させるものではありませんが、照合の材料が残るかどうかで調査の重さが変わります。

1. 納品時点のコミットIDを、発注者側の記録に残す

「バージョン1.2をリリース」ではなく、「バージョン1.2はコミットID abc1234... である」という形で記録します。GitのコミットIDは内容から計算される値なので、後から中身だけを差し替えることができません。発注者側が独立に控えておけば、後日の照合に使えます。

2. リリース用のタグを、誰が付けられるかを決める

誰でもタグを付け替えられる設定のままだと、記録としての意味が薄くなります。リリースタグの作成・変更を特定の担当に限定し、その運用を契約または作業要領に書いておきます。

3. 本番への反映を、Gitサーバーだけに依存させない

Gitサーバーの中身がそのまま自動で本番へ流れる構成は、便利である一方、Gitサーバーの侵害が本番の侵害に直結します。承認の手順を1つ挟む、デプロイ用の資格情報をGitサーバー上に置かない、といった設計で、この直結を切っておきます。

いずれも高度な仕組みではなく、運用の取り決めです。技術的な実装は開発側が行いますが、「そう決めておいてください」と要求するのは発注者の仕事です。要求しなければ、開発の効率を優先した構成が選ばれます。それは開発側の怠慢ではなく、要求されていない品質にコストをかけないという、当然の判断の結果です。

「上げられない」理由を先に潰しておく

バージョンを上げるべきだと分かっていても、実際には上げられない状況があります。よくあるのは次の3つで、いずれも今回の対応が終わったあとに手を打っておく価値があります。

カスタマイズしてしまっている

導入時に独自の改修を加えていると、更新のたびに改修部分の作り直しが発生します。結果として更新が重い作業になり、後回しになります。開発基盤のような周辺システムについては、カスタマイズを避け、標準のまま使うという方針を先に決めておくほうが、長期的な運用コストは下がります。

動作確認をする環境がない

本番のサーバーが1台しかないと、更新は「壊れたら業務が止まる」賭けになります。賭けは誰も引き受けたがらないので、更新は先送りされます。開発基盤であれば、検証用のインスタンスを一時的に立てて確認するという運用が現実的です。

止められる時間帯が決まっていない

「いつなら止めてよいか」が決まっていないと、調整だけで数週間が過ぎます。開発基盤の停止可能時間を、あらかじめ月次または四半期で確保しておくと、この調整が不要になります。

この3つは、いずれも技術ではなく段取りの問題です。そして段取りは、脆弱性が公表されてから決めるのでは間に合いません。今回の対応を、段取りを決めるきっかけとして使ってください。

GXOに相談できること

• 開発基盤（ソース管理・CI/CD・検証環境）の所在と管理責任の棚卸し
• 開発委託契約における、基盤更新責任と資格情報管理の条項レビュー
• 自社設置型のソフトウェアを含む、更新対象の一覧化と運用設計
• セキュアな開発パイプラインの構築支援

開発基盤の管理体制を相談する

FAQ

社内ネットワークからしか見えないGiteaなら安全ですか

インターネット越しに直接叩かれる経路は塞がれます。ただし、この攻撃が求めているのは「リポジトリへの書き込み権限」であり、社内の利用者はその権限を持っているのが普通です。社内の1台がマルウェアに感染した場合、協力会社の担当者が権限を持っている場合、退職者のアカウントが残っている場合には、ネットワークが閉じていることは防御として働きません。到達経路の限定は、更新を先送りする理由ではなく、更新までの時間を確保する材料として扱ってください。

GitHubやGitLabのクラウド版を使っています。関係ありますか

CVE-2026-60004はGiteaの脆弱性なので、直接の関係はありません。ただし本記事で挙げた確認事項のうち、資格情報の保管場所、退職・契約終了時の失効、開発基盤の所有関係については、どのサービスを使っていても同じように確認する価値があります。

1.27.1に上げれば、他は何もしなくてよいですか

この脆弱性については修正されます。ただし、秘密情報がそのサーバーに集まっている構成であれば、その構造自体は更新後も残ります。将来、同じようにGiteaサービスアカウントの権限を奪える脆弱性が出た場合には、同じ範囲が再び露出しうるということです。更新とあわせて、そこに何が置かれ、サービスアカウントの権限がどこまで及ぶかを確認しておくことをおすすめします。

当社は開発を外注していて、社内に開発環境はありません

その場合でも、自社のソースコードはどこかに置かれています。外注先が管理する環境か、自社が契約しているクラウドか、第三者のマネージドサービスか。まずその所在と管理主体を確認してください。資格情報がどこまで同じ場所に含まれるかは構成によって異なり、顧客側で管理している、専用の秘密情報管理基盤に置いている、検証用のものしか置いていない、といった形もあります。だからこそ、保管状況とGiteaサービスアカウントから何に到達できるかを確認する必要があります。確認先が社内から社外に変わるだけで、確認すべき内容は同じです。本記事の「発注者が確認すべき5つのこと」は、そのまま外注先への質問として使えます。

関連記事・サービス

• DevSecOps
• セキュリティベンダー選定
• DX・システム開発
• 脆弱性診断
• セキュリティ運用伴走

参考情報

• GHSA-rcr6-4jqh-j84m Remote Code Execution via diffpatch Git Hook Installation（Gitea、2026年7月28日公開、2026年8月26日確認、一次情報）
• CISA Known Exploited Vulnerabilities Catalog（CISA、catalogVersion 2026.08.25、2026年8月26日確認、一次情報）

ここで示したのは、発注者の立場から開発基盤について何を聞き、何を契約に書くかという観点です。自社または委託先のGiteaが実際に成立条件を満たすかどうかは、稼働している環境を確認しなければ分かりません。更新の手順はGitea公式の案内と開発ベンダーの指示にしたがってください。なお、アドバイザリには実証コードが含まれています。これを動かしてよいのは、自分に権限のある検証環境だけです。他者の環境で試すことは、たとえ善意であっても認められません。