セルフホスト型のGitサービス「Gitea」の公式Dockerイメージに、パスワードもトークンも一切使わずに任意のユーザー(管理者を含む)へなりすませてしまう、認証バイパスの重大な脆弱性が発見されました。この脆弱性はすでに実際の悪用が確認されており、脆弱性の開示からわずか13日後に、インターネット上での探索活動が観測されています。
サマリー
- Giteaの公式Dockerイメージに、認証バイパスの脆弱性CVE-2026-20896(CVSSスコア9.8、Critical)が発見された。バージョン1.26.2以前の公式Dockerイメージがデフォルト設定のまま使われている環境が対象で、リバースプロキシ認証(X-WEBAUTH-USERヘッダーによる認証)が有効化されている場合に悪用可能となる
- 原因は、公式Dockerイメージのapp.ini設定テンプレートが、信頼するリバースプロキシのIPアドレスを指定する「REVERSE_PROXY_TRUSTED_PROXIES」の値を、本来はループバックアドレスに限定すべきところ、ワイルドカード(すべてのIPアドレスを信頼)に設定した状態で出荷されていたこと
- この結果、リバースプロキシ認証を有効化している環境では、攻撃者がGiteaのHTTPポートに直接到達できさえすれば、X-WEBAUTH-USERヘッダーに任意のユーザー名(admin、gitea_admin等)を指定するだけで、パスワードやトークンなしにそのユーザーとして認証されてしまう
- セキュリティ企業Sysdigは、脆弱性の修正版公開から13日後にあたる2026年7月7日、実際の悪用の試みを検知したと公表した。ProtonVPNの出口ノードを経由した偵察・スキャン活動とみられ、現時点で侵害の完了を示す確定的な証拠は確認されていない
- 本稿執筆時点でインターネット上に公開されているGiteaインスタンスは約6,200件とされているが、そのうち何件が脆弱な状態にあるかは不明
- Giteaは2026年6月20日にバージョン1.26.3を、その後1.26.3で生じた別の不具合を修正する1.26.4を公開しており、いずれも本脆弱性を修正済み。同時に9件の追加の脆弱性も修正されている
- Giteaから派生したセルフホスト型Gitサービス「Forgejo」も、Giteaの1.26.3リリースと同時に協調してパッチが提供された
| 項目 | 内容 |
|---|---|
| 脆弱性ID | CVE-2026-20896 |
| CVSSスコア | 9.8(Critical) |
| 対象 | Gitea公式Dockerイメージ バージョン1.26.2以前(デフォルト設定かつリバースプロキシ認証有効時) |
| 発見者 | セキュリティ研究者 Ali Mustafa氏(@rz1027) |
| 原因 | app.ini内のREVERSE_PROXY_TRUSTED_PROXIESがワイルドカード(*)で出荷されていたこと |
| 悪用方法 | X-WEBAUTH-USERヘッダーに任意のユーザー名を指定するだけ、パスワード・トークン不要 |
| 修正版公開日 | 2026年6月20日(v1.26.3)、その後v1.26.4 |
| 実悪用の初観測日 | 2026年7月7日(修正版公開から13日後、Sysdigが検知) |
| 悪用元 | ProtonVPN出口ノード(IP: 159.26.98[.]241)、偵察・スキャンとみられる活動 |
| インターネット公開インスタンス数 | 約6,200件(脆弱な件数は不明) |
何が起きたか
Giteaは、GitHubやGitLabの代替として利用されるオープンソースのセルフホスト型Gitサービスで、ソースコードの保管、プルリクエストの管理、CI/CDの実行などに使われています。今回発見された脆弱性CVE-2026-20896は、Giteaのアプリケーションコード自体のバグではなく、公式に配布されているDockerイメージの設定テンプレートに起因するものです。
Giteaはリバースプロキシによる認証をサポートしており、これはプロキシがユーザーの身元を保証する形で、X-WEBAUTH-USERというHTTPヘッダーを通じてGitea側へユーザー名を伝える仕組みです。この仕組みが安全に機能するためには、Giteaがこのヘッダーを信頼できるプロキシからのリクエストに限って受け入れる必要があり、通常はIPアドレスの許可リストによって、ローカルマシンのみを信頼する設定がデフォルトになっているべきものでした。しかし、Giteaの公式Dockerイメージは、この許可リストの設定であるREVERSE_PROXY_TRUSTED_PROXIESの値を、あらゆる送信元IPアドレスを信頼するワイルドカード(*)に設定した状態で出荷されていました。この結果、管理者がリバースプロキシ認証を有効化(ENABLE_REVERSE_PROXY_AUTHENTICATION = true)している環境では、意図されたプロキシを経由せずGiteaコンテナのHTTPポートへ直接到達できる者であれば誰でも、X-WEBAUTH-USERヘッダーに任意のユーザー名を指定した偽装リクエストを送るだけで、そのユーザーとして認証されてしまいます。
脆弱性の技術的詳細
悪用の手口は極めて単純です。攻撃者は、curlコマンド等を使い、対象のGiteaサーバーへ「X-WEBAUTH-USER: admin」といったヘッダーを付与したHTTPリクエストを送信するだけで、パスワードもセッションクッキーも事前の認証も一切必要とせず、管理者としてアクセスできてしまいます。Giteaの公式アドバイザリでも「意図された認証プロキシを経由せず、Giteaコンテナのポートへ直接到達できるあらゆるプロセスは、ログイン名が判明または推測可能な任意のユーザーになりすませる。admin・gitea_adminといった管理者アカウントが明白な標的になる」と説明されています。この脆弱性が悪用された場合、非公開リポジトリ内のソースコード、APIキー、データベース認証情報、デプロイキーなど、リポジトリに保存されている機密情報へのアクセスや窃取につながる恐れがあります。
こうしたコンテナの脆弱な状態は、Giteaを直接インターネットへ公開している場合だけでなく、共有ネットワーク上に配置されていたり、設定不備のあるロードバランサーの背後にあったり、他のサービスとDockerネットワークを共有しつつ厳格なファイアウォールルールが設定されていなかったりする場合にも生じうると指摘されています。管理者が「プロキシの背後で運用しているから安全」と考えていても、コンテナのポート自体への直接到達を防げていないケースは少なくないとみられます。
実際の悪用状況
セキュリティ企業Sysdigの脅威リサーチ部門シニアディレクターであるMichael Clark氏は、脆弱性の修正版が公開されてから13日後にあたる2026年7月7日、実際の悪用の試みを初めて検知したと公表しました。この活動はProtonVPNの出口ノード(IPアドレス:159.26.98[.]241)を経由したもので、オープンなHTTPポートのスキャン、Giteaデプロイメントのフィンガープリンティング、そしてX-WEBAUTH-USERヘッダーを使った認証バイパスの試行といった、自動化された偵察活動に近い挙動だったとされています。本稿執筆時点で、この活動が実際の侵害の完了(データの窃取や管理者権限の奪取の成功)にまで至ったという確定的な報告はありませんが、開示からわずか13日という短期間でのスキャン活動の観測は、CVSS 9.8かつ実証可能な概念実証コードが存在する脆弱性としては、もはや珍しいことではなくなりつつあると専門家は指摘しています。シンガポールのサイバーセキュリティ庁(CSA)も、この脆弱性が実際に悪用されているとして注意喚起を行っています。
同時に修正されたその他の脆弱性
Giteaが2026年6月20日に公開したバージョン1.26.3、およびその後の1.26.4では、CVE-2026-20896とあわせて9件の追加の脆弱性が修正されています。具体的には、webhookおよびマイグレーションの許可リストにおけるSSRF回避の不備(CVE-2026-22874)、メンテナー権限相当のトークンがリポジトリへの完全な書き込み権限まで昇格しうるブランチ単位の権限昇格(CVE-2026-27775)、組織ラベルの情報漏えい(CVE-2026-25038)、スコープ付きトークンが非公開リポジトリのRSS/Atomフィード保護を回避できる問題(CVE-2026-27761)、TOTPパスコードのリプレイが可能な脆弱性(CVE-2026-20779)、フォーク同期の不具合(CVE-2026-24451)、LFSオブジェクトへのアクセス制御の不備(CVE-2026-28740)などが含まれています。1.26.3の適用後に生じた回帰(リグレッション)の修正や、無効化されたユーザーがOAuth2コールバック経由で密かに再有効化されてしまう問題への対応も、1.26.4で追加されています。これだけ多くの脆弱性がまとめて修正されている以上、1.26.2以前のバージョンを使い続けている組織は、今回の認証バイパスだけでなく、これら一連の脆弱性すべてに晒された状態にあったことになります。
情報システム部門への示唆
自組織でGiteaをDockerで運用している場合は、直ちにバージョン1.26.4以降へアップグレードすることを強く推奨します。即座のアップグレードが難しい場合の緊急対応としては、app.ini内のREVERSE_PROXY_TRUSTED_PROXIESの値を、ワイルドカードではなく実際に使用しているリバースプロキシのIPアドレス(ループバックのみで運用している場合は127.0.0.0/8および::1/128)に限定し、業務上どうしても必要な場合を除いてENABLE_REVERSE_PROXY_AUTHENTICATIONを無効化することが有効です。あわせて、Giteaコンテナへのアクセスを、信頼できるリバースプロキシからのみ許可するようネットワークレベルでの制御を強化することもお勧めします。
すでにインターネットへ公開された状態でリバースプロキシ認証を有効化していた、あるいはアクセスログにX-WEBAUTH-USERヘッダーを使った不審なリクエストの痕跡が見つかった場合は、侵害されたものとして扱い、CI/CDパイプラインの変更履歴の監査、主要ブランチ・本番ブランチへの最近のコミットに意図しない変更がないかの確認、存在するはずのない管理者アカウントの有無の確認を行ってください。あわせて、当サイトで以前紹介したGitLabにおけるAIトークン漏えい等の重大な脆弱性やDocker Hubイメージから1万件超の認証情報が漏洩していた事案でも指摘した通り、リポジトリを通じてアクセス可能な認証情報(APIキー、データベース認証情報、デプロイトークン、SSHデプロイキー等)は、具体的な侵害の証拠が見つからなかった場合でも、念のためすべてローテーションしておくことをお勧めします。セルフホスト型の開発基盤は、パッチ適用の判断が完全に自組織の裁量に委ねられている分、こうした重大な脆弱性への対応が遅れがちです。定期的な棚卸しとバージョン管理を、CI/CD運用の一環として組み込んでおくことが重要です。
出典
- Hackers exploit critical auth bypass in Gitea Docker image – BleepingComputer
- Critical Gitea Docker Bug Under Active Exploitation Exposes Repositories and Secrets – Security Affairs
- Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 13 Days After Disclosure – The Hacker News
- GHSA-f75j-4cw6-rmx4 – GitHub Security Advisory(一次ソース)
- Gitea Docker Flaw Now Actively Probed: One Header Grants Admin Access to Source Code – Tech Times
- GitLabにAIトークン漏えい等の重大な脆弱性(CVE-2026-1724) – セキュリティ対策Lab
- Docker Hub イメージから1万以上の認証情報や認証キーなどが漏洩の可能性 – セキュリティ対策Lab








