社内Git「Gitea」の欠陥が悪用中、1.27.2へ更新を CVE-2026-60004

社内サーバーでソースコードを管理するソフト「Gitea（ギティー）」の欠陥「CVE-2026-60004」が、実際の攻撃に使われていることを米国のサイバーセキュリティ機関CISAが2026年8月25日に確認しました。米連邦政府機関に課された対応期限は8月28日で、収載から3日という極端に短い設定です。

Giteaは、GitHubのようなソースコード管理の仕組みを自社のサーバーに置いて使うためのソフトです。動作が軽く無償で使えるため、外部にコードを置けない事情のある企業や、社内の開発基盤として導入している例があります。

この欠陥を突かれると、攻撃者はGiteaが動いているサーバーの上で、Giteaと同じ権限のまま任意のコマンドを実行できます。深刻度は10点満点で9.8。修正版は2026年7月27日公開の1.27.1ですが、その後8月13日に出た1.27.2でさらに6件の欠陥が直っているため、上げるなら1.27.2が到達点です。

悪用される確率を機械的に予測する指標（EPSS）は0.824で、全CVEの上位0.4%に入ります。1.27.1より前のGiteaを社内で動かしているなら、この件は後回しにできる種類のものではありません。

何が起きるのか

CVE-2026-60004: 差分の取り込み機能から、サーバー上で動く仕掛けを仕込まれる

Giteaには、コードの変更内容をまとめた「パッチ」を画面から貼り付けて取り込む機能があります。この処理の入口が問題でした。

Gitには「フック」という仕組みがあります。コミットや取り込みといった操作の前後で、決められた場所に置かれたプログラムを自動的に実行するものです。本来これは管理者が設定するものであって、外部から書き込めてはいけません。

開発元の説明によると、同じパッチを2回送ると内部で衝突が起き、その処理の過程でファイルが実際のディスク上に書き出されます。書き出し先がフックの置き場所と重なるため、実行可能なファイルを送り込めば、それがそのまま生きたフックになります。あとはGitが通常の操作の中でそれを呼び出すので、攻撃者は何もしなくてもコマンドが動きます。

実行される権限は、GiteaというソフトをOS上で動かしているアカウントの権限です。そのアカウントが読める設定ファイル、データベースの接続情報、社内の全ソースコードが、そのまま攻撃者の手に渡ります。

必要な前提は、リポジトリへの書き込み権限を持っていることです。ここが重要な分かれ目になります。新規ユーザー登録を開いたまま運用している場合、攻撃者は自分でアカウントを作り、自分のリポジトリを作るだけで条件を満たします。開発元も「既定の設定である登録開放のままなら、認証を持たない訪問者が必要な権限を取得できる」と明記しています。社内からしかアクセスできない構成であっても、登録が開いていれば、内部に入り込んだ攻撃者が一段上がる道具として使えます。

CVE-2026-59774: ログインなしでサーバー内のファイルを読み取られる

同じ1.27.1で直ったもう1件も、深刻度9.8です。こちらは認証すら要りません。

Giteaには、文書の記法を画面表示用に整形する機能があります。対応している記法のひとつ「Org-mode」には、別のファイルの中身を差し込む指示が用意されており、この指示に絶対パスを書くと、そのまま読み込んでしまう状態になっていました。

整形処理の入口は、公開リポジトリが1つでもあれば、ログインしていない相手にも開いています。つまり外部から任意のファイルを読み出せます。開発元の説明では、そこからGiteaの設定ファイルにある内部用の認証情報を抜き出し、内部のログ機能を経由してフックを仕込むところまで進めるとされています。結果はCVE-2026-60004と同じ、サーバー上でのコマンド実行です。

この番号は2026年8月28日時点でNVDに登録されていません。脆弱性の一覧を機械的に取り込んで管理しているなら、この1件は網から漏れている可能性があります。

1.27.2でさらに6件が直っている

1.27.1を出した約2週間後の2026年8月13日、Giteaは1.27.2を公開しました。開発元は同日から翌日にかけて、6件の欠陥情報をまとめて出しています。1.27.1まで上げて安心していると、こちらが残ります。

この中で運用上いちばん効くのはCVE-2026-73535です。攻撃者が被害者のパスワードを知っている場合、通常のログイン画面ではなく外部ログインの入口からそのパスワードを送ると、二要素認証の確認をまるごと飛ばして本人としてのセッションを取れる、というものです。しかも同じ操作で攻撃者側の識別子を被害者アカウントに結び付けられるため、被害者がパスワードを変更しても、結び付けられた識別子は外れません。開発元は、インストーラで構築した環境では外部ログインが既定で有効になっている点も添えています。

CVE-2026-73800は、プルリクエストをきっかけに動く自動実行の仕組みに関するものです。本来は取り込み先のコードを使うべき場面で、提案元のコードを読んでしまうため、外部から送られてきた変更提案が、そのリポジトリの機密情報にアクセスできる状態で動きます。外部の協力者から変更提案を受け付けている構成では、優先度が上がります。

影響するバージョンと、直ったバージョン

1.26系や1.25系といった古い枝に対して、この件の修正版は出ていません。Giteaは新しい枝にしか修正を入れない運用なので、古い版で止めている環境は1.27系へ上げる以外の選択肢がありません。1.26.4を最新だと思って止めている環境は、悪用が確認されている欠陥をそのまま抱えていることになります。

使っているGiteaのバージョンを確認する

画面からなら、管理者でログインして管理画面の最初のページを見るのが早いです。ログインせずに確認したい場合は、次の場所が版を返します。

curl -s https://<GiteaのURL>/api/v1/version

サーバーに入れる場合は、実行ファイルに引数を付けます。

gitea --version

コンテナで動かしている場合は、イメージのタグで判断できます。

docker ps --format '{{.Image}}' | grep -i gitea
docker exec <コンテナ名> gitea --version

タグが latest になっている場合、いつ取得したイメージかで中身が変わります。タグだけでは判断せず、実際に版を出して確かめてください。

あわせて確認しておきたいのが、新規ユーザー登録の設定です。CVE-2026-60004の成立条件に直結します。設定ファイルで次の項目を見ます。

grep -A2 '^\[service\]' /etc/gitea/app.ini | grep DISABLE_REGISTRATION

この値が true でなければ、誰でもアカウントを作れる状態です。更新が終わるまでのつなぎとして、ここを閉じる価値はあります。

攻撃されているのか

CVE-2026-60004については、悪用が確認されています。CISAは2026年8月25日にこの番号を、実際の攻撃で使われた脆弱性のカタログへ収載しました。同カタログは証拠のある案件だけを載せる運用です。

是正期限が8月28日に設定されている点も見逃せません。CISAは通常3週間程度の期限を与えますが、今回は収載から3日です。緊急度の判断が高く出ていることの表れです。ただし、身代金要求型ウイルスの攻撃活動で使われたかどうかは「不明」とされており、攻撃の主体や規模を示す具体的な情報は公開されていません。

悪用される確率の予測値であるEPSSは、8月27日時点で0.824です。これは全体の99.6パーセンタイルにあたり、機械的に見ても最上位の部類に入ります。開発元の説明文には、どこを叩けば成立するかがコードの引用付きで書かれているため、手口の再現に必要な情報はすでに公開の場にあります。

残る7件については、8月28日時点で悪用の報告は確認されていません。CISAのカタログに載っている案件はCISA KEV 日本語ダッシュボードで一覧できます。

何をすればいいか

1.27.2へ上げます。これで本稿で扱った8件はすべて塞がります。回避策として開発元が示しているものはなく、更新以外の道はありません。

更新までに時間がかかる場合、その場でできる縮小策が2つあります。ひとつは新規ユーザー登録を閉じること。CVE-2026-60004は書き込み権限を前提とするため、外部の人間がアカウントを取れなくなれば、成立条件のひとつが消えます。もうひとつは、Giteaをインターネットから直接届く場所に置いている場合、社内網や仮想私設網（VPN）の内側へ引っ込めることです。どちらも根治ではありませんが、期限までの数日を稼ぐ意味はあります。

更新の手順は導入方法で変わります。実行ファイルを直接置いている構成なら、サービスを止めて新しい実行ファイルに差し替え、起動し直します。コンテナなら、イメージのタグを1.27.2に指定して入れ替えます。いずれの場合も、データベースとリポジトリの保存先を作業前に控えておきます。Giteaは起動時にデータベースの構造を自動で更新するため、切り戻しが必要になったときに元の状態が要ります。

更新が済んだら、すでに仕掛けを置かれていないかを見ておきます。CVE-2026-60004の手口はGitのフックを仕込むものなので、各リポジトリの保存先にある hooks ディレクトリに、身に覚えのない実行可能ファイルが増えていないかが確認点になります。特に post-index-change という名前のファイルは、開発元の説明で名指しされているものです。

二要素認証を使っている組織では、CVE-2026-73535への後始末も要ります。この欠陥は、外部ログインの識別子を被害者アカウントへ結び付けたままにできるものでした。更新後に、利用者のアカウント設定で身に覚えのない外部ログインが結び付いていないかを確認し、あれば解除してもらう案内が要ります。パスワード変更だけでは外れません。

最後に、更新の受け取り方そのものを見直す機会でもあります。今回は7月27日の1.27.1と8月13日の1.27.2で、合わせて8件が2度に分かれて直りました。Giteaは公開後にまとめて情報を出す進め方をとるため、リリースの通知だけを追っていると、何が直ったのかが分かるのは後になります。開発元の欠陥情報ページを購読対象に入れておくと、この時間差が縮まります。

参照元

• ▸ CISA - Known Exploited Vulnerabilities Catalog（2026年8月25日追加）
• ▸ Gitea - Remote Code Execution via diffpatch Git Hook Installation（CVE-2026-60004）
• ▸ Gitea - Unauthenticated Arbitrary File Read can lead to RCE（CVE-2026-59774）
• ▸ Gitea - 2FA bypass and persistent account takeover via OpenID identity linking（CVE-2026-73535）
• ▸ Gitea - リリースノート v1.27.2（2026年8月13日）
• ▸ NVD - CVE-2026-60004
• ▸ FIRST - EPSS（2026年8月27日時点の値）