Gitea重大バグCVE-2026-20896——ヘッダー1つで管理者権限奪取

**オープンソースのセルフホスト型Gitホスティングソフトウェア「Gitea」の公式Dockerイメージに、CVSSスコア9.8（Critical）の認証バイパス脆弱性 CVE-2026-20896 が発見されました。**攻撃者はたった1つのHTTPヘッダー X-WEBAUTH-USER: admin を送りつけるだけで、パスワードもトークンも一切不要のまま管理者権限でログインできてしまいます。

GitHub公式のセキュリティアドバイザリ（GHSA-f75j-4cw6-rmx4）は2026年6月21日に公開され、Gitea開発チームはすでに1.26.3・1.26.4で修正版をリリース済みです。しかしSecurityWeekやSecurity Affairsの報道によれば、パッチ公開からわずか 13日後 に脅威アクターによる実際のスキャン・悪用試行が観測され、サイバーセキュリティ企業Sysdigはインターネットに露出した約 6,200台 のGiteaインスタンスが標的になり得ると分析しています。本記事では、脆弱性の技術的な仕組み、影響範囲、GitLab CE/Gogs/Forgejoとの比較、そして日本企業がセルフホストGitを運用している場合に今すぐ確認すべき対策手順まで、複数の一次ソースを突き合わせて包括的に解説します。

CVE-2026-20896とは何か——認証を丸ごとすり抜ける設計ミス

CVE-2026-20896は、Gitea公式Dockerイメージの「リバースプロキシ認証」機能に存在する認証バイパス脆弱性です。GitHubのセキュリティアドバイザリによると、根本原因は次の1行にあります。

[security]
REVERSE_PROXY_TRUSTED_PROXIES = *

Giteaには、Nginx や Apache などのリバースプロキシ側でSSO（シングルサインオン）認証を済ませ、その結果をGiteaに X-WEBAUTH-USER ヘッダーで伝える「リバースプロキシ認証」という機能があります。これは ENABLE_REVERSE_PROXY_AUTHENTICATION = true を有効化した組織で使われる正当な仕組みで、本来は「信頼できるプロキシ（通常はループバックアドレス 127.0.0.1 経由）から届いたリクエストだけ」がこのヘッダーを使って認証を主張できるはずでした。

ところが、Gitea公式Dockerイメージの設定テンプレート（docker/root/etc/templates/app.ini および docker/rootless/etc/templates/app.ini）には REVERSE_PROXY_TRUSTED_PROXIES = * というワイルドカードがハードコードされていました。これは「全てのIPアドレスを信頼済みプロキシとして扱う」という意味であり、ドキュメントに記載された本来のデフォルト値 127.0.0.0/8,::1/128（ループバックのみ信頼）から逸脱していたのです。

結果として、リバースプロキシ認証を有効にしたDocker環境では、Giteaコンテナに直接ネットワーク到達できる第三者なら誰でも X-WEBAUTH-USER ヘッダーに既存ユーザー名（admin など）を指定するだけで、そのユーザーとして完全にログインした状態になりすませます。

以下の図は、攻撃者がこの脆弱性を悪用して管理者権限を奪取するまでの流れを示しています。

CVE-2026-20896の攻撃フロー図。攻撃者がX-WEBAUTH-USER: adminヘッダーを送信し、REVERSE_PROXY_TRUSTED_PROXIES=*の設定ミスによりGiteaコンテナが認証を素通りさせ、最終的に全リポジトリとシークレットへの読み書きアクセスを獲得する5段階の流れを表示

この図が示すように、攻撃は驚くほどシンプルです。TCP/IPで到達できる経路さえあれば、curlコマンド一発で完結します。

curl -H "X-WEBAUTH-USER: admin" https://gitea.example.com/

これだけでadminとしてログインしたセッションが確立します。エクスプロイトコードすら不要で、脆弱性スキャナーというよりただの手動リクエストで再現できる点が、本脆弱性の恐ろしさです。

CVSS 9.8の内訳

評価軸	値	意味
Attack Vector (AV)	Network	インターネット経由で攻撃可能
Attack Complexity (AC)	Low	特別な前提条件不要
Privileges Required (PR)	None	未認証で実行可能
User Interaction (UI)	None	ユーザー操作不要
Scope (S)	Changed	管理者権限奪取により影響範囲が拡大
Confidentiality (C)	High	全リポジトリ・シークレットの読み取り可能
Integrity (I)	High	コード改ざん・CI/CD設定変更が可能
Availability (A)	High	リポジトリ削除・アカウント停止も可能

CVSS最高値の10.0にほぼ匹敵する9.8という評価は、「攻撃条件がほぼゼロ、被害は最大」という最悪の組み合わせを反映しています。

影響を受ける範囲

項目	詳細
CVE番号	CVE-2026-20896
名称	Gitea Docker Image Reverse Proxy Authentication Bypass
CVSS v3.1スコア	9.8（Critical）
脆弱性タイプ	CWE-290: 代替パスによる認証バイパス
影響製品	Gitea公式Dockerイメージ 1.26.2以前
修正バージョン	1.26.3、1.26.4（1.26.4への直接アップグレード推奨）
前提条件	`ENABLE_REVERSE_PROXY_AUTHENTICATION = true` が有効な構成
影響なし	バイナリ配布版・セルフビルド版（標準設定ファイル使用時）
公開日	2026年6月21日（GHSA-f75j-4cw6-rmx4）
野生での悪用	公開13日後に実際のスキャン・悪用試行を確認

特筆すべきは「バイナリ配布版やソースからセルフビルドした環境は影響を受けない」という点です。今回の脆弱性はあくまで公式Dockerイメージの設定テンプレートに混入したミスであり、Gitea自体のコードロジックに欠陥があったわけではありません。それでもDockerはGiteaの最も一般的なデプロイ方法であるため、影響範囲は広範に及びます。

公開から13日で悪用開始——Sysdigが観測した攻撃活動

The Hacker Newsやセキュリティ企業各社の報道によれば、GHSA-f75j-4cw6-rmx4の公開（6月21日）からちょうど13日後、クラウドセキュリティ企業Sysdigのテレメトリが実際の悪用試行を検出しました。最初の観測活動は ProtonVPNの出口ノード（159.26.98.241） から発信されたもので、内容は以下のような自動化された偵察活動と一致していました。

開放されたHTTP(S)ポートのスキャン
Giteaデプロイメントのフィンガープリンティング（バージョン特定）
X-WEBAUTH-USER ヘッダーを使った実際の認証バイパス試行

Sysdigの分析では、この活動は特定の脅威グループに帰属付けられてはいないものの、明らかに自動化されたツールによる広範囲スキャンのパターンを示しています。Rescanaのレポートでは「執筆時点で本脆弱性に直接起因する侵害・データ漏洩の確定報告はない」としつつ、脅威研究ディレクターのMichael Clark氏は「攻撃者が偵察段階に入っている以上、実害が出るのは時間の問題」と警告しています。

インターネット露出台数——約6,200台が標的圏内

Sysdigの調査では、インターネットからアクセス可能なGiteaインスタンスは約 6,200台 と推計されています。ただし、このうちどれだけが実際にリバースプロキシ認証を有効化し、かつ未パッチのまま運用されているかは正確には把握されていません。Gitea自体はGitHub/GitLabと比べて小規模チーム・個人開発者による採用が多く、パッチ適用サイクルが企業のIT部門ほど厳格に管理されていないケースが多いことが、この不確実性の背景にあります。

「Giteaとは何か」——GitHub/GitLabとの違い

Gitea（発音は「ギー」または「ギティー」）は、Go言語で書かれた軽量・オープンソースのセルフホスト型Gitプラットフォームです。2016年、当時開発が停滞していた同種のOSSプロジェクト「Gogs」からフォークする形で誕生しました。GitHubやGitLabと同様にリポジトリ管理・Issue・プルリクエスト・Wiki・CI/CD（Gitea Actions）を統合的に提供しますが、決定的に異なるのは圧倒的な軽さです。

特徴	GitHub	GitLab (SaaS/CE)	Gitea
ホスティング形態	クラウド専用（Enterprise Serverは別製品）	クラウド + セルフホスト可	セルフホスト専用（クラウド版なし）
ライセンス	プロプライエタリ	オープンコア（CEはMIT）	MIT（フルオープンソース）
実装言語	Ruby on Rails / Go	Ruby on Rails	Go
最小動作要件	―	4GB RAM以上推奨	512MB RAM程度でも稼働
データベース	独自	PostgreSQL必須	SQLite/MySQL/PostgreSQL選択可
単一バイナリ配布	不可	不可	可能
Actions/CI	GitHub Actions	GitLab CI/CD（フル装備）	Gitea Actions（軽量）

GitHubやGitLab.comのようなSaaS版は運営企業のクラウド上でホスティングされますが、Giteaは自社サーバー・VPS・Raspberry Piにすら構築できるほど軽量な点が最大の特徴です。単一バイナリとSQLiteだけで動作するため、Dockerコンテナ1つ、あるいはメモリ512MB程度のマシンでも十分実用に耐えます。この手軽さゆえに、個人開発者・スタートアップ・教育機関で「自社管理下に置きたいが、GitLabほど重厚な基盤は要らない」というニーズに応える形で急速に普及してきました。

一方でこの軽量さは諸刃の剣でもあります。GitLabのような大企業バックの製品は専任のセキュリティチームと厳格なリリースプロセスを持ちますが、Giteaのような小規模OSSプロジェクトは開発リソースが限られ、今回のようなDockerテンプレートの設定ミスが長期間見過ごされるリスクと隣り合わせです。

比較表——Gitea vs GitLab CE vs Gogs vs Forgejo

セルフホスト型Gitソリューションを検討する際、Gitea以外にも複数の選択肢があります。特に2022年、Giteaの商用化方針（Gitea Ltd.設立）に対するコミュニティの懸念から、非営利団体Codebergが主導する形でフォークプロジェクト「Forgejo」が誕生し、2026年時点では多くのセルフホスト系コミュニティでデフォルトの推奨先になっています。

以下の図は、主要な自己ホスト型Gitソリューション4製品を「リソース消費」「CI/CD」「ガバナンス」などの軸で比較したものです。

Gitea、GitLab CE、Gogs、Forgejoの比較表。最小RAM要件、CI/CD内蔵有無、ガバナンス体制、実装言語、2026年のCritical脆弱性件数、コミュニティ推奨度を4製品で並べて表示

項目	Gitea	GitLab CE	Gogs	Forgejo
開発元	Gitea Ltd.（商用法人）	GitLab Inc.	個人（Unknwon氏）主導	Codeberg（非営利）
最小RAM要件	約150MB	4GB以上推奨	約128MB	約150MB
CI/CD内蔵	Gitea Actions	フル装備（Runner別途）	なし	Forgejo Actions
コンテナレジストリ	対応	対応（フル機能）	非対応	対応
実装言語	Go	Ruby on Rails	Go	Go
ライセンス	MIT	MIT（CE部分）	MIT	MIT/AGPL混在
単一バイナリ配布	可能	不可	可能	可能
Gitea由来	―	―	Giteaの元祖	Giteaからのフォーク
開発ペース（2026年）	中程度	活発	停滞気味	活発
ガバナンスの透明性	商用法人主導で一部不透明	上場企業として高い	個人依存でリスクあり	非営利で高い

この比較から見える傾向

RAM消費量で見るとGitea・Gogs・Forgejoはいずれも軽量級で、GitLab CEの4GB以上という要件とは一線を画します。GitLabは単なるGitホスティングではなく、CI/CD・コンテナレジストリ・脆弱性スキャン・Kubernetes統合まで含む「DevOpsプラットフォーム」であるため、この重さは機能の裏返しでもあります。

一方、GiteaとForgejoは技術的には非常に近い兄弟関係にありますが、2022年のガバナンス分裂を経て、Forgejoは非営利団体Codebergの下で透明性の高い開発体制を敷き、2024年以降は機能追加のペースでもGiteaを上回る場面が増えています。今回のCVE-2026-20896のような「公式Dockerイメージの設定ミス」は、リリースプロセスの厳格さやセキュリティレビュー体制と無関係ではなく、「軽量だから安全」ではないという教訓を突きつける事例だと言えるでしょう。Gogsは開発ペースが鈍化しており、長期的な採用にはやや不安が残ります。

筆者の所感——セルフホスト型OSSインフラの脆弱性はなぜ見過ごされやすいのか

筆者はこれまで複数の小規模開発チームの技術顧問として、GitLab CE・Gitea双方の運用に関わってきましたが、今回のCVE-2026-20896にはセルフホスト型OSSインフラ特有の構造的な弱点が凝縮されていると感じます。

**第一に、「設定ファイルのデフォルト値」は本来ソースコード以上に厳しく監査されるべきなのに、実際にはそうなっていないケースが多いこと。**今回の脆弱性はGiteaのGoコード自体にバグがあったわけではなく、Dockerイメージ用の設定テンプレート1行のミスに起因します。コードレビューはGitHub上でプルリクエストの差分として可視化されやすい一方、「デフォルト設定ファイルが本番相当の安全な値になっているか」を継続的にチェックする仕組みは、多くのOSSプロジェクトで手薄になりがちです。実際、ドキュメントに記載された正しいデフォルト値（127.0.0.0/8,::1/128）とDockerイメージの実際の値（*）が食い違っていたという事実は、「ドキュメントと実装の乖離」がどれほど危険かを物語っています。

**第二に、セルフホスト型ツールは「使う側の設定判断」に安全性が依存する設計になりがちなこと。**GitHub.comやGitLab.comのようなSaaSであれば、認証基盤はベンダー側が一元管理し、利用者が誤った設定をする余地はほぼありません。しかしセルフホスト型ソフトウェアは、利用者自身がリバースプロキシ構成・信頼するIPレンジ・認証方式を設定する必要があり、「デフォルトが安全側に倒れているか」が極めて重要になります。今回のケースは、まさにそのデフォルトが安全側ではなく危険側に倒れていた典型例でした。

**第三に、小規模OSSプロジェクトは「専任セキュリティチーム」を持たないことが多く、脆弱性の発見が外部の善意の研究者やユーザー報告に依存しがちなこと。**GitLabのような上場企業バックの製品はバグバウンティプログラムや専任のセキュリティエンジニアを抱えていますが、Giteaのような中規模OSSプロジェクトはコミュニティの目に頼る部分が大きく、今回のような「1行の設定ミス」が長期間放置されるリスクは構造的に高くなります。だからこそ利用者側は、「軽量で使いやすいから」という理由だけでなく、「このプロジェクトのセキュリティ対応体制はどうなっているか」を選定基準に含めるべきだと筆者は考えます。

日本ではどうなるか——国内Gitea利用企業が確認すべきこと

日本国内でGiteaは、大企業の基幹システムというよりもスタートアップ、受託開発企業、個人開発者、教育機関での採用が目立ちます。GitHub Enterpriseやオンプレミス版GitLabの導入コストが重い中小企業にとって、「無料かつ軽量なセルフホストGit」という選択肢としてGiteaは一定の存在感を持っています。

日本国内での大規模導入事例が大きく報道されるケースは多くありませんが、以下のような利用シーンが典型的です。

5〜10名規模の受託開発チームが、顧客ごとに隔離したプライベートリポジトリ環境を自社VPS上に構築
大学・専門学校のプログラミング教育で、学生向けGit演習環境として運用
個人開発者がRaspberry PiやミニPCにDockerでGiteaを立て、Gitea Actionsと組み合わせて自宅CI/CD環境を構築

これらの環境では、GitHub/GitLabのような大規模SaaSと違ってIT部門による集中管理が及ばず、構築した本人しか設定内容を把握していないケースが少なくありません。特に「リバースプロキシ経由でシングルサインオンを組みたい」というニーズから ENABLE_REVERSE_PROXY_AUTHENTICATION = true を有効化しているチームは、今回の脆弱性の直撃を受ける可能性があります。

日本企業が今すぐ実施すべき確認・パッチ適用手順

以下の図は、Gitea利用者が実施すべき5つの対策ステップをまとめたものです。

CVE-2026-20896対策の5ステップ図。バージョン確認、設定ファイルのTRUSTED_PROXIES確認、1.26.4へのアップグレード、アクセスログの侵害痕跡調査、シークレットのローテーションまでの流れと推奨app.ini設定例を表示

ステップ1: バージョン確認

# Docker環境の場合
docker exec -it gitea gitea --version

# バイナリ版の場合
gitea --version

出力されたバージョンが1.26.2以前であれば、対象の可能性があります。

ステップ2: 設定ファイルの確認

app.ini の [security] セクションを確認し、REVERSE_PROXY_TRUSTED_PROXIES が * になっていないかチェックします。

grep -A2 "\[security\]" /data/gitea/conf/app.ini | grep TRUSTED_PROXIES

* が設定されている、または ENABLE_REVERSE_PROXY_AUTHENTICATION = true かつ信頼するIPレンジが広すぎる場合は要注意です。

ステップ3: 1.26.4への直接アップグレード

Gitea公式ブログは「1.26.3を経由せず1.26.4へ直接アップグレードすること」を推奨しています。1.26.3自体にも別の不具合（context deadline exceeded エラー）が含まれていたためです。

docker pull gitea/gitea:1.26.4
docker compose down
docker compose up -d

ステップ4: アクセスログの侵害痕跡調査

X-WEBAUTH-USER ヘッダーを使った不審なリクエストがなかったか、Webサーバー（Nginx等）とGiteaのアクセスログを確認します。

grep -i "X-WEBAUTH-USER" /var/log/nginx/access.log
grep -i "webauth" /data/gitea/log/gitea.log

心当たりのないIPからの管理者ログイン痕跡が見つかった場合は、侵害を前提とした対応に切り替える必要があります。

ステップ5: シークレットの総ローテーション

侵害の可能性が少しでもある場合、リポジトリに保存されたAPIキー・デプロイキー・CI/CD変数・SSH鍵をすべて再発行します。特にGitHub/GitLab連携用のPersonal Access Tokenや、クラウドプロバイダのIAMキーがリポジトリ内やGitea Actionsのシークレットとして保存されているケースは、影響範囲がGitea単体にとどまらずクラウド環境全体に及ぶ可能性があるため優先度高く対応してください。

なぜ日本の中小企業は特に注意が必要か

日本の中小受託開発企業や個人開発者コミュニティでは、「一度構築したら安定稼働している限り触らない」という運用文化が根強く残っています。Giteaのようなセルフホストツールは、大企業のような脆弱性管理プロセス（定期的なCVEスキャン、資産管理台帳との突合）が整備されていないケースが大半であり、今回のような脆弱性情報が現場に届くまでにタイムラグが生じやすい構造があります。GitHub Security AdvisoryのRSSフィードやメーリングリストを購読していない管理者は、そもそも本脆弱性の存在自体に気づいていない可能性が十分にあります。

筆者の見解・予測——OSSサプライチェーンセキュリティの今後

CVE-2026-20896は単発の設定ミスに見えますが、筆者はこれを**「OSSのデプロイ手段そのものが攻撃対象になる」という近年の傾向を象徴する事例**だと捉えています。

予測1: 「公式配布物の設定監査」が新たなセキュリティ標準になる

XZ Utilsバックドア事件（2024年）以降、OSSサプライチェーンセキュリティの議論は主に「コードに悪意あるコミットが混入していないか」に焦点が当たってきました。しかし今回のケースは、悪意のない善意の開発チームが作った公式Dockerイメージの設定テンプレートそのものが攻撃経路になるという、また別の角度のリスクを浮き彫りにしました。今後は、SBOM（Software Bill of Materials）のようなコード資産の可視化に加えて、「公式配布されているコンテナイメージのデフォルト設定が安全側に倒れているか」を継続的に検証する仕組み——いわば「Configuration Bill of Materials」的な発想——が、OSSプロジェクトの信頼性評価に組み込まれていくと予測します。

予測2: 軽量セルフホストツールの「儀式的な安全性チェック」が普及する

GiteaやForgejoのような軽量ツールは、導入の手軽さゆえに「とりあえず動かして終わり」になりがちです。しかし今回のように、デフォルト設定の1行が管理者権限を献上してしまう事例が繰り返されれば、コミュニティ側は「デプロイ後に必ず実施すべきセキュリティチェックリスト」を公式ドキュメントに明記する動きを強めるでしょう。実際、Forgejoのようにガバナンスの透明性を重視するプロジェクトほど、こうしたチェックリストや自動セキュリティスキャンの整備が進む傾向にあります。

予測3: 開発者・IT管理者へのアドバイス

セルフホスト型Gitを運用する開発者・IT管理者に向けて、筆者から3点助言します。

「軽量・無料」だけを選定基準にしない。CVE対応の速さ、ガバナンスの透明性、コミュニティの活発さも含めて評価する
公式Dockerイメージの設定ファイルを鵜呑みにしない。特に認証・ネットワーク信頼に関わる設定は、ドキュメントの「推奨デフォルト値」と実際にインストールされた設定ファイルの中身を必ず突き合わせる
セキュリティアドバイザリの購読を習慣化する。GitHubの「Watch > Custom > Security alerts」機能を使えば、依存しているOSSプロジェクトの脆弱性情報をリアルタイムで受け取れる

まとめ——今すぐ取るべき3つのアクション

CVE-2026-20896は、Gitea公式DockerイメージのデフォルトHTTPヘッダー信頼設定ミスに起因するCVSS9.8の認証バイパス脆弱性で、X-WEBAUTH-USER ヘッダー1つで管理者権限を奪取できます。公開13日後には実際のスキャン・悪用試行が観測されており、約6,200台のインターネット露出インスタンスが潜在的な標的です。

読者が今すぐ取るべきアクションは次の3つです。

自社・個人のGitea環境がDockerイメージで、かつリバースプロキシ認証を有効化していないか確認する。該当する場合は app.ini の REVERSE_PROXY_TRUSTED_PROXIES の値を必ず確認する
1.26.4へ直ちにアップグレードし、アクセスログから X-WEBAUTH-USER を使った不審なリクエストの痕跡を調査する。侵害の疑いがあれば、リポジトリ内のシークレット・APIキー・デプロイキーを全てローテーションする
セルフホストツールを選定・運用する際は、軽量さや使いやすさだけでなく、CVE対応の速さとガバナンスの透明性を評価基準に加える。GitHubのセキュリティアラート機能を有効化し、依存する全OSSプロジェクトの脆弱性情報を継続的に監視する体制を構築する

セルフホスト型OSSインフラは「自分たちで完全にコントロールできる」という安心感がある一方、「自分たちで全ての設定を検証する責任を負う」という裏返しでもあります。今回のCVE-2026-20896は、その責任を怠った場合にどれだけ簡単に管理者権限が奪われるかを示す、教科書的な事例と言えるでしょう。