メインコンテンツへスキップ
Gitea CVE-2026-60004がCISA KEV入り:影響確認と初動対応
チュートリアル 中級

Gitea CVE-2026-60004がCISA KEV入り:影響確認と初動対応

チュートリアル 中級

CISA KEVに追加されたGiteaのCVE-2026-60004について、対象バージョンと修正版、セルフホスト環境の公開・登録・書込権限、ログ保全、リポジトリ・CI/CD資格情報・成果物への影響確認、更新後の復旧とエスカレーション基準を公式情報から整理します。

この記事の目次 9項目から選ぶ

冒頭要約

2026年8月25日、米国CISAはセルフホスト型Gitサービス GiteaのCVE-2026-60004 を、実際の悪用が確認された脆弱性の一覧であるKnown Exploited Vulnerabilities(KEV)へ追加しました。Gitea公式Security Advisoryでは、1.17以上1.27.1未満が影響対象で、1.27.1が修正版です。

この脆弱性では、Giteaのリポジトリへ通常の書込権限を持つ主体が、Giteaを動かすOSサービスアカウントの権限でコードを実行できる可能性があります。新規登録とリポジトリ作成を広く許可している環境では、外部の訪問者が必要な権限を得られる場合があるため、公開範囲だけでなく登録・承認・リポジトリ作成の設定も確認します。

最初に行うのは、Giteaの全環境とフルバージョンを特定し、1.27.1以降への更新計画を確定することです。更新前にログと構成を保全し、リポジトリへの書込経路、Giteaサービスアカウントが読める設定・資格情報、Actionsや成果物への影響を確認します。この記事は攻撃の再現方法ではなく、情シス、開発基盤担当、SRE、SaaS管理者、SOC・CSIRTが判断を進める順序を整理したものです。

CISAの期限と日本の組織の期限を分けて考える

CISA KEV JSONの2026年8月28日という期限は、米国連邦政府機関向けの運用期限です。日本の組織へ同じ法的期限が一律に適用されるわけではありません。一方、既知の悪用が確認された事実と公式修正版があることは、対応を前倒しする根拠になります。自組織では版、到達性、書込経路、サービスアカウントの権限、ログ保持状況を基に期限を決めてください。


何が起きたか:Gitea CVE-2026-60004とは

CVE-2026-60004は、Giteaのパッチ適用機能に関係するコードインジェクションの脆弱性です。Gitea公式Security Advisoryによると、リポジトリへ書き込める主体が、リポジトリで管理する内容を利用して、GiteaのOSサービスアカウントとして任意のコマンドを実行できる可能性があります。

確認項目2026年8月26日時点の公式情報
CVECVE-2026-60004
対象Gitea 1.17以上1.27.1未満
修正版Gitea 1.27.1
脆弱性の分類CWE-94: Improper Control of Generation of Code
Gitea公式CVSS v3.19.8 Critical
CISA KEV追加日2026年8月25日
CISA KEV期限2026年8月28日(米国連邦政府機関向け)
既知のランサムウェア利用Unknown(CISA KEV記載)

Gitea公式Advisoryは、影響の例として app.ini、アプリケーションの秘密情報、プロセス環境にある秘密情報、マウントされたリポジトリ、データベース認証情報と内容、OAuth・外部連携の資格情報、内部・外部サービスを挙げています。実際にどこまで影響し得るかは、Giteaの実行ユーザー、コンテナやVMの分離、マウント、ネットワーク、データベース、CI/CD連携によって異なります。

「書込権限が必要」と「CVSSの権限不要」は矛盾しない

公式Advisoryは技術上、リポジトリへの通常の書込権限が関係すると説明しています。同時に、GiteaのCVSS v3.1はPrivileges RequiredがNoneです。これは、新規登録が開かれ、一般ユーザーが自分のリポジトリを作成できる既定に近い構成では、外部の訪問者が登録後に必要な書込経路を得られる可能性を評価しているためです。

したがって、DISABLE_REGISTRATIONだけを見て対象外と判断してはいけません。既存ユーザー、外部協力者、漏えいしたアクセストークン、OAuth・連携アプリ、移行用アカウントなど、リポジトリへ書き込める経路も確認します。逆に、KEV入りしたことだけで、すべてのGiteaが侵害済みと断定してはいけません。


影響を受ける可能性がある組織・担当者

Giteaはソースコードの保管だけでなく、Issue、Pull Request、Release、Package、Webhook、OAuth、Actions、Runner、外部Gitやデプロイ先との連携を担う場合があります。Gitea本体への影響が、開発・配布・本番運用の信頼へ波及し得るため、複数担当で確認します。

読者・担当まず確認すること見落としやすい点
情シス・資産管理Giteaの設置場所、版、公開範囲、所有者、保守方法検証、旧環境、子会社、委託先、DR側が台帳にない
開発基盤・SREバイナリ、コンテナ、Helm等の導入形態、実行ユーザー、マウント、DB、ネットワーク表示上の版と実際に稼働する複数レプリカの版が一致しない
開発者・リポジトリ管理者書込権限、外部協力者、トークン、Webhook、Actions、Release自分のリポジトリだけならサービス全体へ影響しないと思い込む
ID・SaaS管理者ローカルユーザー、SSO、OAuth、サービスアカウント、管理者、セッション登録停止だけで既存の書込経路も閉じたと判断する
SOC・CSIRTGitea、プロキシ、OS・コンテナ、IdP、ネットワーク、DBの証跡更新・再起動・コンテナ再作成で短期ログや実行状態を失う
リリース責任者対象期間のコミット、タグ、Release、Package、Actions成果物、デプロイ更新後にビルドが通れば過去成果物も信頼できると考える

Gitea Cloudやホスティング事業者が提供するマネージド版は、利用者が版を直接管理しない場合があります。OSS版の影響範囲をそのまま当てはめず、提供者の公式案内、修正状況、テナント側で確認すべきログと責任分界を記録してください。


まず確認すること:Gitea CVE-2026-60004チェックリスト

PoCや攻撃用リクエストは使わず、Giteaの管理画面、構成管理、イメージ・パッケージ情報、既存ログ、IdPやネットワークの監査記録で確認します。

1. 全環境とフルバージョンを確定する

  • 本番、検証、開発、旧環境、待機系、DR、子会社、委託先を含めてGitea資産を一覧にした。
  • バイナリ、OSパッケージ、Docker、Kubernetes、Helm、アプライアンス、マネージドの導入形態を記録した。
  • 表示、実行ファイル、コンテナイメージ、構成管理など複数の根拠でフルバージョンを確認した。
  • 1.17以上1.27.1未満、1.27.1以降、1.17未満、版不明、提供者確認中に分類した。
  • ロードバランサー配下の全レプリカ、ジョブ、待機系が同じ修正状態か確認した。
  • 1.27.1以降へ更新できない環境の所有者、理由、暫定制御、停止・移行期限を決めた。

1.17未満は今回の公式影響範囲外ですが、古い版を継続利用してよいという意味ではありません。Giteaのサポート方針と既知の別脆弱性を確認し、サポートされる版への移行を別課題として管理します。

2. 到達性、登録、リポジトリ書込経路を確認する

  • インターネット、VPN、社内、管理ネットワーク、リバースプロキシ経由の到達範囲を確認した。
  • 新規登録、メール確認、管理者による承認、既定ユーザー権限、リポジトリ作成可否を確認した。
  • 組織、チーム、外部協力者、移行用アカウント、bot、Deploy key、アクセストークンの書込権限を確認した。
  • OAuth・連携アプリ、Webhook、ミラー、CI/CD、移行ツールなど、利用者以外の書込経路を確認した。
  • 退職者、休眠、期限切れ委託、共有アカウント、不明なアカウントやトークンを特定した。
  • 更新までの暫定制御で登録・書込・公開範囲を狭める場合、業務影響と解除条件を記録した。

新規登録の停止は有効なリスク低減策になり得ますが、公式更新の代わりではありません。既存の書込権限や侵害済みアカウントが残る可能性もあるため、版の更新と権限確認を並行します。

3. 更新前に証跡と構成を保全する

  • Giteaのアプリケーションログ、routerログ、accessログの有効状態、保存先、保持期間を確認した。
  • リバースプロキシ、WAF、ロードバランサー、DNS、FW、ネットワークフローの記録を保全した。
  • OS、コンテナ、Kubernetes、EDR、クラウド監査、IdP、データベースの対象期間を確定した。
  • Giteaの設定、起動方法、実行ユーザー、マウント、環境変数名、接続先、イメージ識別子を記録した。
  • 時刻同期、ログ欠損、ローテーション、複数レプリカの識別方法を確認した。
  • 更新・再起動・コンテナ再作成で失われる情報を先に保全し、取得者と保管先を記録した。

accessログはGiteaで常に有効とは限りません。存在しないログを後から取得できたことにせず、プロキシ、ネットワーク、IdP、OSなど別の証跡で補える範囲と、確認できない範囲を分けて残します。

4. サービスアカウントと開発資産への影響を確認する

  • Giteaを動かすOSユーザー、コンテナUID、Kubernetes ServiceAccount、クラウドIAMの権限を確認した。
  • app.ini、環境変数、Secret管理、データベース、リポジトリ、添付・Package・Release領域への到達範囲を確認した。
  • 想定外のプロセス、子プロセス、外部通信、ファイル・設定変更、権限変更、ログ欠損がないか確認した。
  • 管理者、一般ユーザー、外部協力者、トークン、SSH鍵、OAuth・連携アプリ、Webhookの変更履歴を確認した。
  • リポジトリ、ブランチ保護、コミット、タグ、Release、Package、ミラー、Actions設定の想定外変更を確認した。
  • Runner登録、Actions実行、成果物、デプロイ、署名・配布経路を対象期間と関連付けた。
  • 不審点がある場合は削除せず、時系列と証跡を保全してCSIRTとリリース責任者へ引き継いだ。

ログに単独の決め手がない場合でも、Giteaの実行ユーザーから到達できる範囲が広いほど確認優先度は上がります。特に、クラウド管理、パッケージ公開、署名、デプロイに使う資格情報がある場合は、Giteaだけで調査を閉じません。


推奨される初動対応

やること

  1. 環境を「1.27.1以降」「1.17以上1.27.1未満」「提供者確認中」「版不明」に分け、根拠と確認時刻を残す。
  2. 影響版または版不明の環境では、Gitea、プロキシ、OS・コンテナ、IdP、ネットワーク、DBの証跡と構成を更新前に保全する。
  3. Gitea公式の手順と自組織の変更管理に従い、1.27.1以降のサポートされる修正版へ更新する。
  4. 更新までの間は、外部到達性、新規登録、リポジトリ作成、不要な書込権限を業務影響の範囲で制限する。
  5. 更新後に全レプリカの版、Web・Git操作、認証、Webhook、ミラー、Actions、Runner、Package、Release、バックアップ、ログ転送を確認する。
  6. 不審点があれば、Gitea管理セッションと影響する資格情報を特定し、証跡を保全したうえで失効・ローテーションを判断する。
  7. 影響期間のコミット、タグ、成果物、Package、Release、デプロイを特定し、必要なものは信頼できる環境とソースから再検証・再生成する。

やってはいけないこと

  • 公開PoC、攻撃コード、細工したパッチを使って脆弱性を再現しない。
  • 証拠保全前に不審なユーザー、トークン、プロセス、ファイル、リポジトリ、ログ、コンテナを削除しない。
  • 新規登録を閉じただけで、既存ユーザー・トークン・連携アプリの書込経路を安全と判断しない。
  • 1.27.1へ更新しただけで、更新前の不審操作や資格情報・成果物への影響確認を省略しない。
  • GiteaサービスアカウントがOSのrootではないという理由だけで、リポジトリや認証情報への影響を低く見積もらない。
  • 影響範囲を確認せず全シークレットを無計画に変更し、復旧順序、証跡、業務継続を損なわない。
  • マネージド版を自己判断で対象外にせず、提供者の公式回答と責任分界を確認する。

記録すべきこと

事案ID / 対応責任者 / 確認時刻・タイムゾーン:
環境名 / 所有者 / 委託先 / 設置場所:
導入形態 / フルバージョン / 全レプリカの状態:
外部・内部到達性 / 登録・承認・リポジトリ作成設定:
書込可能なユーザー / bot / トークン / 連携アプリ:
Gitea実行ユーザー / マウント / DB / ネットワーク / IAM:
保全したGitea / proxy / OS・container / IdP / network / DBログ:
不審なプロセス / 通信 / ファイル・設定 / アカウント変更:
リポジトリ / tag / release / package / Actions / runnerの確認結果:
影響期間の成果物 / 配布先 / デプロイ先:
更新前後の版 / 作業時刻 / 暫定制御 / 復旧確認:
失効・再発行した資格情報 / セッション:
未確認事項 / 残リスク / 次回確認期限:
エスカレーション先 / 判断者 / 判断理由:

秘密値、アクセストークン、秘密鍵、個人情報を記録票へ貼り付けないでください。識別子、所有者、権限範囲、失効・再発行時刻、保管先だけを記録します。


危険度・優先度とエスカレーション判断

優先度判断の目安推奨する動き
緊急影響版で外部到達可能かつ登録・書込経路が広い、不審なプロセス・通信・アカウント・リポジトリ変更がある到達・書込経路を制限し、証拠保全、CSIRT招集、資格情報と成果物の影響確認へ進む
影響版または版不明で、サービスアカウントが重要リポジトリ、DB、CI/CD資格情報、デプロイ先へ到達できる当日中に更新・暫定制御・調査範囲・責任者を確定する
1.27.1以降で、到達性と書込権限が限定され、現時点で不審点がない更新後確認と監視を継続し、確認した期間と完了根拠を残す
要確認マネージド、旧環境、委託先、全レプリカの版、ログ保持、書込主体が不明対象外にせず、所有者と回答期限を決める

次の条件が一つでもあれば、通常の脆弱性更新だけで完了させず、インシデントレスポンスへ切り替えます。

  • Giteaサービスアカウント配下で、説明できないプロセス、ファイル、設定、外部通信、権限変更がある。
  • 管理者、一般ユーザー、トークン、SSH鍵、OAuth・連携アプリ、Webhookに想定外の追加・変更がある。
  • リポジトリ、ブランチ保護、コミット、タグ、Release、Package、Actions、Runnerに説明できない変更がある。
  • データベース、app.ini、環境変数、クラウドIAM、外部サービスの資格情報へアクセスされた可能性がある。
  • 対象期間の成果物が本番や顧客へ配布され、ソース・ビルド・署名の完全性を説明できない。
  • ログ欠損、時刻不整合、コンテナ再作成により、影響期間と操作主体を説明できない。

資格情報への影響が疑われる場合は、GitHub secret leak対応チェックリストをGitea環境へ読み替え、発行元での失効と利用ログ確認を進めます。成果物や配布経路へ影響する場合は、開発ツール・OSSサプライチェーン確認チェックリストを併用してください。


よくある誤解

「新規登録を無効にしているので影響しない」

新規登録を無効にすると外部から一般アカウントを作る経路は狭まりますが、既存ユーザー、外部協力者、漏えいしたトークン、連携アプリなどが書込権限を持つ場合があります。まず版を更新し、書込経路を別に棚卸しします。

「リポジトリ書込権限しかない一般ユーザーなら被害は限定的」

今回の公式Advisoryは、通常のリポジトリ書込権限からGiteaのOSサービスアカウントの権限へ境界を越える可能性を説明しています。サービスアカウントが読める設定、リポジトリ、DB、連携資格情報が影響範囲になります。

「1.27.1へ更新したので侵害確認は不要」

更新は今後の悪用を防ぐための対応です。更新前の期間に不審な操作があったか、既存資格情報や成果物へ影響したかは別に確認します。

「KEVに入ったので、自社のGiteaも侵害済み」

KEVは既知の悪用が確認された脆弱性であることを示しますが、個別環境の侵害を証明するものではありません。対象版、到達性、書込経路、サービスアカウントの権限、証跡を組み合わせて判断します。

「NVDにCVSSが見えないので公式評価はない」

2026年8月26日の確認時点では、NVD API 2.0はCVE-2026-60004のレコードを返しませんでした。一方、Gitea公式Security AdvisoryはCVSS v3.1 9.8を公開しています。この記事では版とCVSSをベンダー公式Advisoryから、既知悪用の事実をCISA KEVから確認しています。


関連用語・関連ページ


公式情報・参考情報

関連テーマを体系的に学ぶ 脆弱性管理(CVE・KEV)対応ガイド
ESC