速報
CVE-2026-60004 — Gitea のコードインジェクションでサーバー側のコマンド実行（解説と対応策）
CVE-2026-60004は、セルフホストGitサーバー Gitea の diffpatch エンドポイントに存在するコードインジェクション（CWE-94）です。CVSS 9.8、CISA KEV掲載＝実際に悪用中。厄介なのは権限条件で、CVSSは『権限不要』、CISAは『リポジトリ書き込み権限が必要』としています。矛盾ではなく、公開登録が有効なら誰でもその権限を取れるからです。修正版と、更新後に確認すべきことを防御目線で解説します。
実際に悪用が確認されている脆弱性（CISA KEV掲載）の速報解説です。何が起きるのか・影響範囲・対応策を、攻撃の再現手順は伏せて防御目線でまとめます。
- CVE
- CVE-2026-60004
- 重大度
- Critical（CVSS 9.8 / v3.1。NVDに登録された評価の出典は CVE番号機関）
- 種別
- コードインジェクション（CWE-94）
- 影響
- 悪意ある Gitフックの設置 → Gitea のOSユーザーとしてコマンド実行
- 対象
- Gitea 1.17 〜 1.27.0（ベンダーのアドバイザリによる）。修正版は 1.27.1
- 悪用状況
- CISA KEV 掲載（2026年8月25日追加・是正期限 8月28日）。ランサムウェアでの使用は「不明」と記載
- 悪用されやすさ
- EPSS 0.868（当サイトのフィードで2026-09-05時点）＝ 上位クラス
「権限が必要」を安心材料にしない
読み方A（CISAの記述）
「リポジトリ書き込み権限を持つ攻撃者」＝条件があるように見える
読み方B（CVSSベクター）
PR:N＝権限不要
↓ ベンダーのアドバイザリが両方を説明する
公開登録が有効なら
登録 → 自分のリポジトリを作成 → 必要な書き込み権限を自分で用意できる
脆弱性情報を読むとき、「〜の権限が必要」で安心してしまうのはよくある失敗です。問うべきは「その権限は誰が持っているか」ではなく、「その権限は、外から取得できるか」。公開登録、招待なしのサインアップ、デフォルトで付与される権限——取得経路がある権限は、実質的に条件ではありません。
この読み替えは よくある失敗は「前提」の失敗 の②「使っていないものは危なくないはず」とも重なります。登録経路を閉じ忘れていないかは、設定ファイルではなく実際のHTTPで確かめてください（認証と認可の違い）。
どんな脆弱性か
- 経路
diffpatchエンドポイントにおける、共有された一時クローン上でのパッチ適用の扱いに問題がある- 結果
- 悪意ある Gitフック（
hooks/post-index-change） が設置され得る - 実行のきっかけ
- Git がインデックスを書き込むときに、そのフックが Gitea のOSユーザーとして実行される
- 到達し得るもの
- アプリケーションの秘密、データベースの認証情報、OAuthトークン、マウントされたリポジトリ
- 成立の前提
- ベンダーは、悪用には Git 2.32以降、
diffpatchルートが有効であること、書き込み可能かつ実行可能な一時ファイルシステムが必要だと記しています
最後に残るのは「仕掛け」——だから更新だけでは終わらない
このCVEの終着点はサーバー上に置かれた、実行される仕掛けです。更新はその設置経路を塞ぎますが、すでに置かれたものを消しはしません。
Gitフックは「正規のリモート実行の口」として設計されたものなので、置かれてしまえば不審には見えません。正規の保守口とバックドアの違いは「誰が・記録に残る形で・許可して作ったか」だけです。穴をふさいだら、居座りの足場まで見る——この順番を省かないでください。
対応策
1.27.1 以降へ更新する（本命）
ベンダーのアドバイザリは、影響範囲を 1.17 〜 1.27.0、修正版を 1.27.1 としています。まずここです。セルフホストは誰も更新してくれません——/learn の CVE対応の実務手順 のとおり、稼働中のバージョンを実測してから当ててください。
公開登録の設定を、実際に確かめる
上に書いたとおり、公開登録が有効かどうかが権限条件を実質的に無効化します。設定値を読むのではなく、ログアウト状態で登録ページを開いて挙動を見る。内部向けのインスタンスなら、登録を閉じたうえでネットワーク側でも到達を絞る（認証だけに頼らない）。
身に覚えのないフックやファイルが無いか点検する
更新後に、リポジトリのフックディレクトリに置かれた覚えのないスクリプト、想定外の実行ファイル、Giteaのプロセスが出している見慣れない外向き通信を確認します。「更新したから大丈夫」ではなく「置かれていないか」を見るのが要点です。
侵害が疑わしいなら、到達先を漏れた前提で扱う
ベンダーが挙げている到達先はアプリケーションの秘密・DB認証情報・OAuthトークンです。点検で判断がつかない場合、「分からない」は「無かった」ではありません——これらを失効・再発行してください。鍵の扱いは .envとAPIキーの基礎 に。
そもそもの選択を見直す（急がなくてよい）
自前運用は「自分で更新する責任」とセットです。判断材料は 自前GitサーバーとGitHub、どちらが安全か にまとめています。乗り換えろという話ではなく、更新を回せる体制があるかで決める話です。
当サイトの視点：CVSSとKEVは「別のことを言っている」ので、両方読む
この件は、当サイトが CVEトリアージ で書いたことの実例になりました。CVSSは「技術的にどれだけ悪いか」、CISAの記載は「現場でどう悪用されているか」、EPSSは「悪用される確率の推定」——3つは別のことを測っています。
今回、CVSSのPR:NとCISAの「書き込み権限が必要」は一見矛盾して見えました。片方だけ読んでいたら、「権限が要るなら急がなくていい」と誤読していたはずです。食い違いを見つけたら、それは情報の誤りではなく、読み落としている前提がある合図——今回はベンダーのアドバイザリに答え（公開登録）が書いてありました。
出典（一次情報）
- Gitea セキュリティアドバイザリ GHSA-rcr6-4jqh-j84m — github.com（影響範囲 1.17〜1.27.0／修正版 1.27.1／権限条件と公開登録の関係／到達し得るもの／成立の前提）
- NIST NVD「CVE-2026-60004」 — nvd.nist.gov（CVSS v3.1 9.8・ベクター・CWE-94。状態は Analyzed）
- CISA Known Exploited Vulnerabilities Catalog — cisa.gov（2026年8月25日追加・是正期限 8月28日・ランサムウェアでの使用は「不明」）
- Gitea「Release of 1.27.1」 — blog.gitea.com
いずれも2026-09-05に確認。攻撃の再現手順および実証コードへのリンクは掲載しません。
次に読む
- 判断材料：自前GitサーバーとGitHub、どちらが安全か
- 手順：CVE対応の実務手順 ／ CVSS・EPSS・KEVの読み分け
- 用語：バックドアとは（置かれた仕掛けをどう見るか）
よくある質問
QCVE-2026-60004 で何が起きますか？
ベンダーのセキュリティアドバイザリによれば、diffpatch エンドポイントにおけるパッチ適用の扱いに問題があり、結果として悪意ある Git フック（hooks/post-index-change）が設置され得ます。そのフックは Git がインデックスを書き込むときに Gitea のOSユーザーとして実行されます。ベンダーは、そこから到達し得るものとしてアプリケーションの秘密、データベースの認証情報、OAuthトークン、マウントされたリポジトリを挙げています。
Q認証は必要なのですか？ CVSSは『権限不要』ですが、CISAは『書き込み権限が必要』と書いています。
両方とも正しく、矛盾していません。ベンダーのアドバイザリは、攻撃にはリポジトリへの書き込み権限が必要だとしたうえで、公開登録が有効な環境では未認証の利用者がアカウントを登録して自分のリポジトリを作れば、その権限を得られると説明しています。つまり『必要な権限』が誰でも取得できる状態では、実質的に権限は不要になります。CVSSの『権限不要』はこの経路を評価したものです。
Qどのバージョンが対象で、どう直しますか？
ベンダーのアドバイザリは、影響を受けるのは 1.17 から 1.27.0 まで、修正版は 1.27.1 としています。対応は 1.27.1 以降への更新です。自前で運用している Gitea は自動更新されないため、放置されている環境ほど危険が続きます。
Q更新すれば終わりですか？
更新が本命ですが、それだけで終わりにしないでください。この脆弱性が最終的に行き着く先は『サーバー上に仕込まれた実行される仕掛け（Gitフック）』であり、更新はその設置経路を塞ぐだけで、既に置かれたものを消しません。更新後に、身に覚えのないフックやファイルが無いか、そして公開登録の設定が意図どおりかを確認してください。侵害が疑わしい場合は、ベンダーが挙げている到達先（秘密・DB認証情報・OAuthトークン）を漏れた前提で失効・再発行するのが安全側です。