脆弱性対応ウォッチ重大・クリティカル脆弱性のクラウド別対応まとめ
最新更新履歴CriticalHigh回避策のみパッチありAWSGCPAzureLinux
Critical CVSS 9.8 NEW KEV 悪用確認
CVE-2026-60004

Gitea の diffpatch から Git フックを仕込まれてサービス権限でコマンド実行(KEV・是正期限 8/28)

情報取得日: 2026/08/25・本ページは公開情報の非公式まとめです

CVE IDCVE-2026-60004
製品Gitea / Gitea(diffpatch API エンドポイント)
CVSS9.8(Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
種別 (CWE)CWE-94 コード生成の不適切な制御(コードインジェクション)
登録/公開日2026/08/25
KEV 期限2026/08/28 まで(米国連邦機関向け目安)
出典https://github.com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m

概要

セルフホスト型の Git サービス Gitea に、リポジトリへ書き込める利用者が Gitea のサービスアカウント権限で任意のシェルコマンドを実行できる欠陥がある。CISA は 2026年8月25日にこれを KEV(悪用が確認された脆弱性カタログ)へ収載し、是正期限を 2026年8月28日と、収載から3日という短さで設定した。成立の筋道はベンダのアドバイザリ GHSA-rcr6-4jqh-j84m が具体的に書いている。Gitea の diffpatch(ブラウザ上でパッチを当てる機能)は、攻撃者が用意したパッチを共有の bare な一時クローンの中で処理する。ここに同じパッチを二度投げると add/add の衝突が起き、Git の三方向マージへのフォールバックが走る。このフォールバックは --cached を指定していても索引上のパスを実際にチェックアウトしてしまう。そして bare クローンではリポジトリのルートがそのまま $GIT_DIR なので、hooks/post-index-change という名前で実行属性つきのエントリを置くと、それが生きた Git フックとして扱われる。Git は索引を書くときにこのフックを呼ぶため、リポジトリ側が制御する内容が Gitea のサービスアカウントとして実行される。アドバイザリは成立の前提を3つ挙げている。Git 2.32 以降であること、diffpatch のルートが有効であること、一時ファイル領域が書き込み可能かつ実行可能であることの3つである。影響範囲は 1.17 以上 1.27.1 未満で、9年ぶんの系列がまとめて対象になる。ひとつ注意して読む必要があるのは、権限の前提について2つの一次情報が食い違っている点である。CISA KEV の記述は「リポジトリへの書き込み権限を持つ攻撃者」と明記しているのに対し、ベンダが付けた CVSS 3.1 ベクタは PR:N(権限不要)で、そのぶんスコアが 9.8 になっている。実運用の判断としては KEV 側の記述、つまり「書き込み権限を持つ誰か」を前提に置くほうが安全側であり、社内利用者だけの Gitea であっても、その利用者アカウントが1つ乗っ取られれば成立すると考えるべきである。なお 2026年8月26日時点で NVD にはまだ本 CVE の項目が作られておらず、CVSS の主評価は NVD ではなくベンダのものである。

クラウド/OS 別の対応状況

各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。

AWS / GCP / Azure / Linux いずれも対応区分は同じです: パッチあり(アプリ更新) 参照先も共通です(一次情報)。 下の表は環境ごとの補足です。
環境対応状況対応方法・備考
AWS (ECS/EC2) パッチあり(アプリ更新)
EC2 / ECS / EKS のいずれで動かしていても、対象は利用者が持ち込んだ Gitea 本体である。1.27.1 以降のバイナリ、または公式イメージ 1.27.1 以降へ入れ替えてコンテナを作り直す
AWS はマネージドの Gitea を提供していないため、AWS 側の個別アドバイザリは存在しない(2026-08-26 時点で確認できていない)。ALB / セキュリティグループで管理画面の到達範囲を絞れるが、書き込み権限を持つ正規利用者からの操作なので到達制限だけでは塞げない。
参照リンク
GCP パッチあり(アプリ更新)
GKE / Compute Engine / Cloud Run 上の Gitea を 1.27.1 以降へ更新し、コンテナイメージを作り直す
GCP からの本 CVE 個別のセキュリティ速報は確認できていない(2026-08-26 時点)。Cloud Run で動かしている場合、Gitea のサービスアカウントに紐づく IAM 権限がそのまま攻撃者の手に渡ることになるため、更新と併せて付与している権限の見直しも行う。
参照リンク
Azure パッチあり(アプリ更新)
AKS / VM / Container Apps 上の Gitea を 1.27.1 以降へ更新する
Azure からの本 CVE 個別のセキュリティ速報は確認できていない(2026-08-26 時点)。
参照リンク
Linux パッチあり(アプリ更新)
ディストリのパッケージではなく公式バイナリで入れているケースが多いので、まず実体のバージョンを gitea --version で確認し、1.27.1 以降へ入れ替える。systemd ユニットで動かしている場合は入れ替え後に再起動する
Gitea は多くのディストリで公式リポジトリに含まれず、公式バイナリまたはコンテナで導入されている。そのため Ubuntu USN / Red Hat RHSA / Debian security tracker に本 CVE の項目は期待できず、2026-08-26 時点でも確認できていない。パッケージ管理の外にあるぶん、更新漏れが起きやすい点に注意する。
参照リンク

解決の方向性(パッチ/回避策/代替)

Gitea を 1.27.1 以降へ更新する。これが唯一の恒久対応で、アドバイザリは明示的な回避策の節を持っていない。是正期限が 2026年8月28日なので、インターネットに面している Gitea は最優先で扱う。更新までのあいだに被害面を下げる手当てとしては、成立条件のうち運用側で外せるものが2つある。ひとつは diffpatch のルートで、使っていないなら経路を塞ぐこと。もうひとつは一時ファイル領域で、Gitea が使う一時ディレクトリを noexec でマウントしていれば、実行属性つきのフックが置かれても実行されない。ただしどちらもアドバイザリが正式な回避策として提示したものではないため、更新の代わりにはならない。あわせて、これは KEV 収載=実際の悪用が確認されている区分なので、更新前に侵害の有無を見ておくこと。具体的には、各リポジトリの .git/hooks/ 配下に post-index-change が置かれていないか、Gitea のサービスアカウントから想定外の外部接続や子プロセスが出ていないか、diffpatch のエンドポイントへ同一パッチが短時間に二度投げられた記録が無いかを確認する。コンテナで動かしている場合、更新はイメージの入れ替えになるので、実行中のコンテナが古いイメージのままになっていないかも見る。

よくある質問(CVE-2026-60004)

CVE-2026-60004(Gitea)の影響は?

Critical(CVSS 9.8)に分類されるGitea Gitea(diffpatch API エンドポイント)の脆弱性です。セルフホスト型の Git サービス Gitea に、リポジトリへ書き込める利用者が Gitea のサービスアカウント権限で任意のシェルコマンドを実行できる欠陥がある。CISA は 2026年8月25日にこれを KEV(悪用が確認された脆弱性カタログ)へ収載し、是正期限を 2026年8月28日と、収載から3日という短さで設定した。成立の筋道はベンダのアドバイザリ GHSA-rcr6-4jqh-j84m が具体的に書いている。Gitea の diffpatch(ブラウザ上でパッチを当てる機能)は、攻撃者が用意したパッチを共有の bare な一時クローンの中で処理する。ここに同じパッチを二度投げると add/add の衝突が起き、Git の三方向マージへのフォールバックが走る。このフォールバックは --cached を指定していても索引上のパスを実際にチェックアウトしてしまう。そして bare クローンではリポジトリのルートがそのまま $GIT_DIR なので、hooks/post-index-change という名前で実行属性つきのエントリを置くと、それが生きた Git フックとして扱われる。Git は索引を書くときにこのフックを呼ぶため、リポジトリ側が制御する内容が Gitea のサービスアカウントとして実行される。アドバイザリは成立の前提を3つ挙げている。Git 2.32 以降であること、diffpatch のルートが有効であること、一時ファイル領域が書き込み可能かつ実行可能であることの3つである。影響範囲は 1.17 以上 1.27.1 未満で、9年ぶんの系列がまとめて対象になる。ひとつ注意して読む必要があるのは、権限の前提について2つの一次情報が食い違っている点である。CISA KEV の記述は「リポジトリへの書き込み権限を持つ攻撃者」と明記しているのに対し、ベンダが付けた CVSS 3.1 ベクタは PR:N(権限不要)で、そのぶんスコアが 9.8 になっている。実運用の判断としては KEV 側の記述、つまり「書き込み権限を持つ誰か」を前提に置くほうが安全側であり、社内利用者だけの Gitea であっても、その利用者アカウントが1つ乗っ取られれば成立すると考えるべきである。なお 2026年8月26日時点で NVD にはまだ本 CVE の項目が作られておらず、CVSS の主評価は NVD ではなくベンダのものである。

CVE-2026-60004 の対応方法・回避策は?

Gitea を 1.27.1 以降へ更新する。これが唯一の恒久対応で、アドバイザリは明示的な回避策の節を持っていない。是正期限が 2026年8月28日なので、インターネットに面している Gitea は最優先で扱う。更新までのあいだに被害面を下げる手当てとしては、成立条件のうち運用側で外せるものが2つある。ひとつは diffpatch のルートで、使っていないなら経路を塞ぐこと。もうひとつは一時ファイル領域で、Gitea が使う一時ディレクトリを noexec でマウントしていれば、実行属性つきのフックが置かれても実行されない。ただしどちらもアドバイザリが正式な回避策として提示したものではないため、更新の代わりにはならない。あわせて、これは KEV 収載=実際の悪用が確認されている区分なので、更新前に侵害の有無を見ておくこと。具体的には、各リポジトリの .git/hooks/ 配下に post-index-change が置かれていないか、Gitea のサービスアカウントから想定外の外部接続や子プロセスが出ていないか、diffpatch のエンドポイントへ同一パッチが短時間に二度投げられた記録が無いかを確認する。コンテナで動かしている場合、更新はイメージの入れ替えになるので、実行中のコンテナが古いイメージのままになっていないかも見る。

自分の環境が CVE-2026-60004 の影響を受けるか確認するには?

Gitea Gitea(diffpatch API エンドポイント) を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報(https://github.com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m)で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド/OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

CVE-2026-60004 は実際に悪用されている?

はい。CISA の既知の悪用された脆弱性カタログ(KEV)に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/08/28 です。早急な対応が推奨されます。

参考情報(出典)

本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください。

CISA KEV(悪用確認・対応期限・ランサム利用の出典)
免責: 本ページは CISA KEV・NVD・各ベンダー公式アドバイザリ等の公開情報をもとにした非公式まとめです。修正バージョンや対応可否は変更される場合があります。実際の対応は必ず 出典元および各ベンダー公式情報・自環境で確認してください。

« 一覧に戻る