トップ/記事一覧/Gitサーバ「Gitea」に乗っ取りの穴、CVE-2026-20896など9件、1.26.4へ更新を
gitea-cve-cover-ja

Gitサーバ「Gitea」に乗っ取りの穴、CVE-2026-20896など9件、1.26.4へ更新を

自分でサーバを立てて使うソースコード管理ツール「Gitea」に深刻な脆弱性が9件見つかり、修正版1.26.4が公開されました。最も重い穴はDocker版で特定の設定を使っている場合、パスワードなしで管理者になりすませるもの。自前でGiteaを運用している企業や個人は今すぐ更新を。

ニュース2026年7月4日公開 本日更新
目次
この記事のポイント

自分でサーバを立てて使うソースコード管理ツール「Gitea」に深刻な脆弱性が9件見つかり、修正版1.26.4が公開されました。最も重い穴はDocker版で特定の設定を使っている場合、パスワードなしで管理者になりすませるもの。自前でGiteaを運用している企業や個人は今すぐ更新を。

自分でサーバを立ててソースコードを管理する開発向けツール「Gitea(ギテア)」に、深刻な脆弱性が9件見つかり、修正版の1.26.4が公開されました。最も重いCVE-2026-20896は、危険度を10点満点で表す指標(CVSS)で9.8という最高クラス。特定の設定で使っている場合、パスワードもログインもなしに、管理者になりすませてしまいます。

GiteaはGitHubやGitLabのように、プログラムのソースコードを保管・共有するためのソフトです。違いは「自分たちのサーバにインストールして、社内や個人で完結して使える」点にあります。クラウドに預けたくないコードを手元で管理できる手軽さから、中小企業や社内チーム、自宅サーバ(ホームラボ)で広く使われています。今回の修正は、そうした自前でGiteaを運用しているすべての人に関わる話です。

開発元は2026年6月末に修正版を公開し、7月初めにかけて各脆弱性の詳細(CVE番号)が順次公開されました。現時点で実際の攻撃は確認されていませんが、機序が明快なぶん、放置は禁物です。まず結論から言うと、自前でGiteaを動かしているなら、できるだけ早く1.26.4へ更新してください

見つかった9件の脆弱性の一覧

今回の修正で塞がれたのは、合計9件です。危険度の高い順に並べると次のようになります。深刻なものほど「ログイン不要で外部から攻撃できるか」が効いてきます。

CVE番号内容危険度悪用の前提
CVE-2026-20896ヘッダ1つで
他人になりすまし
9.8(緊急)Docker版+
特定設定が有効時
CVE-2026-22874内部ネットワークへの
不正アクセス(SSRF)
9.6(緊急)要ログイン
(一般利用者権限)
CVE-2026-58426他リポジトリの
成果物を盗み読み
9.6(緊急)要ログイン
(一般利用者権限)
CVE-2026-58424承認ゲートの
恒久バイパス
8.9(重要)要ログイン
(一般利用者権限)
CVE-2026-287373Dファイル経由の
スクリプト混入(XSS)
8.7(重要)要ログイン
CVE-2026-27775一部権限が全リポジトリ
書き込みに昇格
重要要ログイン
CVE-2026-26231読み取り専用リポに
コミットできる
8.5(重要)要ログイン
CVE-2026-24451非公開後もフォーク
同期で内容が漏れる
重要要ログイン
CVE-2026-20779ワンタイムパスコードの
使い回し
7.1条件付き

このほかにも、権限のないトークンで非公開コミットが読めてしまう問題(CVE-2026-27761)など、細かな情報漏れの穴もまとめて塞がれています。数字だけ見ると9.8が並んでぎょっとしますが、大事なのは「自分の環境がその前提に当てはまるか」です。次でそこを整理します。

あなたのGiteaは危ないのか

最も重いCVE-2026-20896は9.8という数字ですが、すべてのGiteaが即座に乗っ取られるわけではありません。悪用には次の2つが両方そろっている必要があります。開発元のセキュリティ勧告が条件を明記しています。

CVE-2026-20896の被害を受ける条件(両方に当てはまる場合)

  • Docker版(コンテナ)で動かしている。手動でビルドした版や、公式バイナリをそのまま入れた版は対象外です。
  • 「リバースプロキシ認証」を有効にしている。これは前段のサーバでログイン処理を任せ、Gitea側は「誰がログイン済みか」をヘッダで受け取る仕組みで、社内シングルサインオン(一度のログインで複数サービスを使える仕組み)などで使われます。

なぜこの2つがそろうと危険なのか。Docker版のGiteaは、内部の設定ファイルに「信頼するアクセス元」を示す項目がREVERSE_PROXY_TRUSTED_PROXIES = *(=すべてを信頼)と初期設定されていました。本来ここは、自分の立てた前段サーバ(多くはループバック、つまり自分自身)だけを信頼するべき値です。ところが「すべて」を信頼していたため、リバースプロキシ認証を有効にしていると、どこからでも届くX-WEBAUTH-USERというヘッダの中身をそのまま「ログイン済みユーザー」として受け入れてしまうのです。

逆に言えば、リバースプロキシ認証を使っていない(多くの標準的な構成がこれです)なら、このCVE-2026-20896は成立しません。まずは「Docker版か」「リバースプロキシ認証を入れているか」の2点を確認してください。当てはまるなら最優先で、当てはまらなくても他の8件があるため、いずれにせよ更新は必要です。

誰が、何のために狙うのか

狙うのは、インターネットに公開された自前のGiteaサーバを機械的に探し回る攻撃者です。企業の開発サーバや、個人が自宅で立てたサーバは、URLさえ分かれば世界中の誰からでもアクセスできます。攻撃者はまず、公開されているGiteaを片っ端から見つけ、上記の条件に当てはまるものを選び出します。

条件がそろったサーバに対して攻撃者がすることは単純です。通信に「あなたは管理者(admin)です」と書いたヘッダを1行足して、リクエストを1回送るだけ。パスワードもワンタイムコードも要りません。それだけでGiteaは相手を管理者として扱い、画面や操作の権限をまるごと開け渡します。

管理者を乗っ取られると失うものは大きい。サーバ上のすべてのリポジトリのソースコード、外部サービスと連携するためのSSH鍵、自動ビルド(CI/CD)に登録したパスワードやAPIキーといった秘密情報が、まとめて相手の手に渡ります。ソースコードには自社の設計や、うっかり書き込んだ認証情報が含まれることもあり、そこを足がかりに被害が本番システムへ広がる恐れもあります。開発の土台であるコード基盤を握られるのは、企業にとって最も避けたい事態のひとつです。似た構図は、Giteaの派生元にあたる『Gogs』の認証なし乗っ取りの脆弱性や、社内設置型のGitLabで繰り返し見つかる脆弱性でも起きています。自前でGitサーバを持つということは、その更新責任も自分で負うということです。

主な脆弱性を詳しく見る

CVE-2026-20896: ヘッダ1行で管理者になりすまし(9.8)

今回の目玉です。原因は前述のとおり、Docker用の設定テンプレートにREVERSE_PROXY_TRUSTED_PROXIES = *が埋め込まれていたこと。Giteaの本来の初期値は127.0.0.0/8,::1/128(自分自身だけを信頼)ですが、Docker版だけ「すべて信頼」にすり替わっていました。

Giteaのコンテナが受け付けるHTTPの入口に直接届けられる立場なら、誰でもX-WEBAUTH-USER: adminのようなヘッダを送るだけで、そのユーザーとして扱われます。攻撃条件は「外部から到達可能・認証不要・利用者の操作も不要」で、NVDの評価でCVSS 9.8がついたのはこのためです。修正版では、リバースプロキシ認証を「信頼プロキシ一覧に何が入っているか」で自動的に有効化するのをやめ、管理者が明示的にオンにしない限り動かない方式(オプトイン)に変更されました。報告は@rz1027、修正は@bircniによるものです。

CVE-2026-22874: 内部ネットワークを覗くSSRF(9.6)

Webhook(イベント発生時に外部URLへ通知する機能)や、他所からのリポジトリ取り込み(マイグレーション)で使う「アクセス先の許可リスト」の絞り込みが不完全だった問題です。SSRF(サーバに、本来アクセスできないはずの内部ネットワークへ代わりに通信させる攻撃)で、ログインした利用者が社内向けの内部アドレスへGitea経由でアクセスできてしまいます。こちらはログインが必要(一般利用者の権限で足りる)ですが、内部ネットワークの探索や、クラウドの管理情報の窃取につながり得ます。

CVE-2026-58426: 他人の成果物を盗み読み(9.6)

Giteaの自動ビルド機能(Gitea Actions)が発行する成果物のダウンロード用URLの署名検証にあいまいさがあり、別のリポジトリの成果物を読み取ったり、別タスクの状態を書き換えたりできる問題です。この穴は1.26.2ですでに塞がれています。ビルドの成果物にはビルド時の設定や生成物が含まれることがあり、権限をまたいだ情報の流出につながります。

その他の重要な修正

CVE-2026-58424は、外部から送られた変更提案(フォークからのプルリクエスト)に対する承認ゲートを恒久的に迂回できる問題で、悪意あるコードが自動ビルドに紛れ込む恐れがあります。CVE-2026-27775は、あるブランチだけの書き込み権限が全リポジトリの書き込みに昇格してしまうもの。CVE-2026-26231は、読み取り専用のはずのリポジトリにコミットできてしまう権限チェックの不備です。いずれもログインは必要ですが、複数人で使う組織では内部からの悪用リスクになります。9件の全体像は開発元のリリース告知と、脆弱性データベースのまとめで確認できます。

今すぐやること: 1.26.4へ更新する

対処はシンプルで、最新の1.26.4に更新することです。セキュリティ修正自体は1.26.3にも入っていますが、開発元は「1.26.3にはリポジトリのコード表示画面で不具合(リグレッション)が残っているため、1.26.4へ進んでほしい」と案内しています。すでに1.26.3を入れている場合も、できるだけ早く1.26.4へ上げてください。

更新までの間、すぐには上げられない場合は、Docker版でリバースプロキシ認証を使っている環境に限り、REVERSE_PROXY_TRUSTED_PROXIESの値を「すべて」から自分の前段サーバのアドレスだけに絞る、あるいはリバースプロキシ認証自体を一時的に切ることで、最も危険なCVE-2026-20896の経路は塞げます。ただしこれは応急処置で、根本対処は更新です。

なお、Giteaから枝分かれした別プロジェクト「Forgejo(フォージェオ)」を使っている場合は、独立して開発されているため同じバージョン番号で同じ修正が入っているとは限りません。Forgejo側の告知を別途確認してください。ただし、Docker運用で信頼プロキシを「すべて」にしている構成が危険なのは、こちらも同じ考え方です。

実際に攻撃されているのか

✓ 現時点で確認できている事実

  • 修正版1.26.3/1.26.4が公開済み(開発元告知
  • 脆弱性は開発元の調整プロセスを通じて報告・公開されたもので、攻撃コードの先行公開ではない
  • 米政府CISAが公開する「実際に攻撃が確認された脆弱性リスト」(KEVカタログ)には、今回の9件はいずれも未登録

つまり、いま大規模に悪用されているという情報はありません。とはいえ、CVE-2026-20896のように手口が単純で威力が大きい穴は、詳細が公開されたあと後追いで狙われやすい類型です。「まだ攻撃されていない」ことを、更新を先延ばしにする理由にしないほうがよいでしょう。

まとめ

自前でソースコードを管理できる手軽さがGiteaの魅力ですが、その裏返しとして、更新の判断と実行はすべて運用者に委ねられます。今回の9件は、最重量のCVE-2026-20896こそ「Docker版+リバースプロキシ認証」という条件付きとはいえ、成立すればパスワードなしの管理者乗っ取りという最悪の結果を招きます。残る8件も、ログインした利用者による内部からの情報漏れや権限昇格につながるものです。

やることは決まっています。自前でGiteaを動かしているなら、1.26.4へ更新する。Docker版でリバースプロキシ認証を使っているなら最優先で。Forgejo利用者は自分のプロジェクトの告知を確認する。この3つを、攻撃者が手口を試し始める前に済ませておくのが得策です。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go