Gitea:Docker の既定設定のため、HTTP ヘッダー 1 本で誰でも管理者になりすませた(CVE-2026-20896)

事案日
2026-06-20
公開日
2026-07-07
発行
Lemma Critical Team
関連 Pack
Pack CAgent Governance

TL;DR

セルフホスト型 Git サービス Gitea の公式 Docker イメージに、HTTP ヘッダー 1 本で誰でも管理者になりすませる脆弱性(CVE-2026-20896、CVSS 9.8)が公開された。イメージが REVERSE_PROXY_TRUSTED_PROXIES = *(すべての送信元を信頼された逆プロキシと見なす)を既定にしていたため、逆プロキシ認証が有効な構成では、任意の送信元が X-WEBAUTH-USER: admin を送るだけで管理者権限を得られた(修正は 1.26.3、逆プロキシ認証は明示的な opt-in に変更)。問題は認証アルゴリズムの強度ではなく、認可の根拠が「攻撃者が自由に付けられる HTTP ヘッダー」という表層シグナルに置かれ、その要求が本当に信頼された逆プロキシ由来かを実行の前に独立検証していなかったことにある。検出と事前証明は代替ではなく補完である。


事案概要

  • 対象: Gitea(セルフホスト型のオープンソース Git サービス)。ソースコード・CI/CD・開発者 ID を集約する開発基盤として広く用いられる。
  • 識別子: CVE-2026-20896。Gitea 1.26.3 のセキュリティ修正群の一つとして公開。
  • 深刻度: CVSS 9.8(Critical)。未認証のネットワーク上の相手が管理者権限を取得できる。
  • 公開日: 2026-06-20(Gitea 1.26.3 リリース)。報告は Tenable の Joshua Martinelle および @rz1027、修正は @bircni。
  • 根本原因: 公式 Docker イメージが同梱する app.ini テンプレートに REVERSE_PROXY_TRUSTED_PROXIES = * がハードコードされていた。この既定は「すべての送信元 IP を、信頼された逆プロキシとして扱う」意味になり、Gitea は誰から届いた X-WEBAUTH-USER ヘッダーでもそれを認証済み ID の主張として受理した。
  • 悪用の核心: 逆プロキシ認証が有効な構成では、攻撃者は X-WEBAUTH-USER: admin というヘッダーを 1 本付けるだけで、認証情報を一切持たずに管理者として認識される。
  • 影響の連鎖: 管理者到達後、全非公開リポジトリの閲覧、永続アクセス用の SSH 鍵注入、以後のコードプッシュを外部へ送る webhook の改ざん、CI/CD シークレットの窃取、webhook 経由の SSRF によるサーバー内部への横展開に拡大し得る。
  • 影響バージョン: Gitea Docker イメージの 1.26.2 以前。修正は 1.26.3、直後の 1.26.4 への更新が推奨(1.26.3 のコードページ regression を修正済み)。
  • 規模の目安: インターネットに露出した Gitea インスタンスは約 6,200 件(外部観測)。実環境での挙動は、開示 13 日後に初回の探索が検出された段階で、攻撃の進展には至っていないと報告されている。
  • 核心: 認可の判定が「X-WEBAUTH-USER ヘッダーの値」という攻撃者制御下の表層属性に置かれ、その要求が本当に信頼された逆プロキシから来たものかを実行の前に独立検証していなかった。

タイムライン

  • 2026-06-20: Gitea 1.26.3 が公開され、CVE-2026-20896 を含む複数のセキュリティ修正が提供される。逆プロキシ認証を明示的な opt-in に変更し、* ワイルドカードを既定から削除。
  • 2026-06-21: 1.26.3 で生じたコードページの regression を修正した 1.26.4 が公開。Gitea は 1.26.4 への直接更新を強く推奨。
  • 2026-07 上旬: クラウドセキュリティ企業 Sysdig が、開示から 13 日後に実環境での初回の悪用試行を検出したと報告。ただし当該活動は攻撃者による初期調査の段階であり、悪用や攻撃の進展には至っていないとされる。

注: 技術的事実は Gitea 公式のリリース告知(1.26.3/1.26.4)および NVD の登録に基づく。CVSS 9.8 は CNA である Gitea による評価で、NVD 自身の再評価は本稿時点で未提供。「開示時点で実環境悪用」と表現する二次報道もあるが、一次に近い Sysdig の観測は「開示 13 日後の初期調査」であり、本 Brief はこの精度で記述する。最新の一次情報を参照されたい。


攻撃ベクター

  1. 既定設定による全送信元の信頼: 公式 Docker イメージが REVERSE_PROXY_TRUSTED_PROXIES = * を同梱し、すべての送信元 IP を「信頼された逆プロキシ」として扱う。
  2. ヘッダーの ID 主張としての受理: 逆プロキシ認証が有効な構成で、Gitea は届いた X-WEBAUTH-USER ヘッダーを、逆プロキシが検証済みの認証済み ID の主張として受理する。
  3. なりすましヘッダーの送信: 攻撃者は保護されたエンドポイントへのリクエストに X-WEBAUTH-USER: admin を付ける。認証情報は不要で、他の前提条件もない。
  4. 管理者としての認識: Gitea は当該リクエストを管理者からのものと認識し、特権操作を許可する。
  5. 永続化と横展開: 全非公開リポジトリの閲覧、SSH 鍵の注入による永続アクセス、以後のプッシュを外部へ送る webhook の改ざん、CI/CD シークレットの窃取、webhook 経由の SSRF によるサーバー内部への到達に拡大し得る。

構造的論点

本事案は Pillar 03(エージェント権限証明)の identity-auth カテゴリに属する。中心的な失敗 primitive は、認可の根拠が「攻撃者が自由に付けられる HTTP ヘッダーの値」という表層シグナルに置かれ、その要求が本当に信頼された経路(逆プロキシ)から来たものかを、行動の前に独立検証していなかった点にある。Gitea は「X-WEBAUTH-USER に admin と書いてあるから、この相手は admin だ」と判定したが、「このリクエストは、ID を検証する責を負う逆プロキシを実際に通過してきたのか」を確かめなかった。認可の根拠が、検証可能な権限の証明ではなく、リクエストの見た目に置かれていた。

本事案は Brief 003(Starlette / BadHost、MCP サーバーの認証が Host ヘッダー操作で回避された)と同型である。いずれも「認証の判定が、攻撃者の制御下にあるリクエストの表層属性(Host ヘッダー/X-WEBAUTH-USER ヘッダー)に依存し、行動の前に主体の権限が独立検証されなかった」構造だ。Brief 088(Kestra、パス末尾を /configs にするだけで認証が外れた)とは、認可が「攻撃者が選べるパス末尾/ヘッダー値」という表層で切り替わり、未認証の到達がそのまま特権操作になった点で連なる。Brief 091(Photo ZIP、認証ランダリングで SPF・DKIM・DMARC を全通過した「Calendly 発」メールが偽物だった)とは、形式的な認証チェック(ヘッダーの整合/DNS 認証)を正規に通過したこと自体が、送信元・主体の真正性の証明にならなかった点で通じる。Brief 046(ServiceNow、設定ひとつで認証が外れ未認証のまま顧客インスタンスが照会された)とは、既定・設定の一点が認証の有無を切り替え、到達=照会になった点で同じ系列にある。

Gitea のような開発基盤は、ソースコード・ビルドパイプライン・開発者 ID を集約する層であり、その認可が破られると、基盤が束ねるコード来歴と CI/CD 権限がまとめて攻撃者に渡る。管理者到達が SSH 鍵注入・webhook 改ざん・CI/CD シークレット窃取に直結する点で、secondary に code-provenance を併記する。以後のプッシュを窃取する webhook 改ざんは、正規の配送・保管経路を将来のコード窃取路に転用する点で、コード来歴の完全性に触れる。リポジトリ操作や CI 実行という「行動」ごとに、それを要求する主体の権限が独立検証されて初めて、開発基盤を実務に安心して載せられる。


検出と証明の落差

CVE としての早期開示、CVSS による深刻度評価、修正版(1.26.3/1.26.4)の提供、Sysdig による実環境の探索観測は、影響範囲の把握と緊急パッチ適用の判断に不可欠であり、本 Brief がその役割を否定するものではない。既知のなりすましヘッダーのパターンを WAF や IDS で観測することも、対応の助けになる。検出は確かに役割を果たす。

一方で、検出は受信側(リクエストを処理する Gitea の認証層)が「どの要求を、誰の権限で accept するか」自体を変えない。本事案では、X-WEBAUTH-USER: admin を持つリクエストは認証層の判定を正規に通過したため、未認証の要求が管理者操作に到達した。欠けていたのは「このリクエストは、ID を検証する責を負う逆プロキシを実際に経由したのか」「この主体は本当に admin の権限を持つのか」を、ヘッダーの形式的判定とは別系統で独立検証する層である。異常検知が事後に発火しても、認証層が accept した時点の管理者アクセスは止まらない。監査で「この管理操作は正規の認可された主体によるものか」を立証する材料として、リクエストがヘッダーを含んでいたという事実は、主体の権限の独立した証跡にならない。

事前証明(pre-execution attestation)は、特権操作の前に、それを要求する主体の権限を、ヘッダーやパスの形式的判定とは切り離して独立検証可能な形で確認する。権限の証明が伴わなければ、リクエストがどんなヘッダーを持っていても実行を事前に block する。認証層の通過(detection 的な「このヘッダーは通る」)と、呼び出し側権限の事前証明(「この主体はこの管理操作を実行する権限を持つ」)は代替ではなく 補完 の関係にあり、両者が重なって初めて、開発基盤への集約された権限を安心して実務に出せる。


対応経緯と業界動向

  • Gitea(go-gitea): 1.26.3 で CVE-2026-20896 を修正し、逆プロキシ認証を明示的な opt-in(管理者が意図的に有効化する方式)に変更。既定の * ワイルドカードを削除した。1.26.3 のコードページ regression を修正した 1.26.4 への直接更新を強く推奨。同リリースでは SSRF(CVE-2026-22874)など複数のセキュリティ修正も併せて提供された。
  • NVD: CVE-2026-20896 を登録。CVSS 9.8(AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H)は CNA である Gitea による評価で、NVD 自身の再評価は本稿時点で未提供。
  • Sysdig: 開示 13 日後に実環境での初回探索を検出。ただし初期調査の段階であり、悪用や攻撃の進展には至っていないと報告。
  • 運用上の論点: 逆プロキシ配下で ID ヘッダーを用いる構成では、逆プロキシがヘッダーを確実に上書き・除去し、Gitea 側が信頼する送信元を最小化することが緊急対応として共有された。露出インスタンスの即時更新も推奨されている。
  • 業界横断の論点: 逆プロキシによるヘッダーベース認証(X-WEBAUTH-USER などの ID ヘッダー委譲)は広く使われる構成であり、「上流が検証済みである」前提が既定設定の一点で崩れると未認証の全権到達に直結する。ヘッダー由来の ID を、経路の真正性とともに独立検証する設計の必要性が再認識された。

Lemma による分析

本事案で露呈した検出と証明の落差(認可がヘッダー値という表層シグナルで判定され、行動の前に主体の権限と経路の真正性が独立検証されない)に対し、Lemma は以下の設計を提示する。

  • 行動ごとの権限の事前証明: 管理操作やリポジトリ操作のような特権操作の前に、それを要求する主体の権限を、HTTP ヘッダーやパスの形式的判定とは切り離して独立検証し、証明が伴わなければ実行を事前に reject する(proof-as-auth)。
  • 表層シグナルへの非依存: 認可の根拠を、攻撃者が自由に付けられるヘッダー・パス末尾などの表層属性に置かず、検証可能な権限の証明に置く。
  • 経路と ID 主張の真正性の結合: ヘッダーで委譲される ID の主張を、それを発行した経路(逆プロキシ)の真正性とともに検証し、任意の送信元が主張を偽装できないようにする。
  • 選択的開示: 主体の権限属性そのものを開示せずに、「この主体はこの操作を実行する権限を持つ」ことだけを最小開示で証明する。

検出(事後のパッチ適用・異常検知・深刻度評価)は被害の是正に、事前証明(特権操作の前の権限の独立検証)は開発基盤の信頼確立に、それぞれ相補的に働く。


Sources


Brief 配布について

本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。


(c) 2026 FRAME00, INC. — Built for decisions that matter.

Cite this Brief

この Brief を引用する

Lemma Critical Team. (2026).
"Gitea:Docker の既定設定のため、HTTP ヘッダー 1 本で誰でも管理者になりすませた(CVE-2026-20896)".
Lemma Critical Brief No.096. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/096-gitea-reverse-proxy-header-auth-bypass/