セルフホスト型のGitホスティングサービス「Gitea」に、CVSS 9.8（緊急）の脆弱性 CVE-2026-59774 が公開されました。アカウントを持たない攻撃者が、公開リポジトリが1つでもあればサーバ上の任意のファイルを読み取れます。設定ファイル app.ini の内部トークンを抜かれると、そこからGitフックを仕込まれてコマンド実行まで到達し得ます。
影響を受けるのは Gitea 1.22.1 〜 1.27.0。修正版は 1.27.1（2026年7月27日公開）です。まず自社に「野良Gitea」が無いかの棚卸しから始めてください。
この記事でわかること
- Giteaとは何で、どういう経路で社内に入り込んでいるのか
- CVE-2026-59774 の成立条件と、なぜ「公開リポジトリ1つ」で足りるのか
- 執筆時点でNVD・OSV・CISA KEVのいずれにも登録されておらず、脆弱性スキャナが検知しないという実務上の落とし穴
- フォーク版のForgejoが同じ欠陥を3日後に修正していた事実と、そこから読み取れること
- 自社の該当判定と、侵害を疑う場合の確認手順
Giteaとは何か（「うちは使っていない」と即断する前に）
Giteaとは、社内サーバやクラウド上に自前で立てるGitホスティングサービスです。GitHubやGitLabと同じくソースコードのリポジトリ管理、Issue、プルリクエスト、CI（Gitea Actions）を提供します。
使うのは主に開発部門ですが、導入・運用は情シスが担っているケースが多いはずです。特徴は単一の実行ファイルで動く軽さで、Dockerコンテナ1つ、あるいはNAS上のパッケージとして数分で立ち上がります。ソースコードを社外に出せない企業が「とりあえず社内に置く」用途で選びやすいソフトウェアです。
ここが情シスにとっての急所です。Gitea公式ドキュメントが挙げるインストール経路は、Homebrew、Chocolatey、Snap、Alpine／Arch／Gentoo／openSUSE／FreeBSDの各コミュニティパッケージなど大半がサードパーティ製で、公式が配布しているのはバイナリとDockerイメージだけです。つまり導入経路がばらばらで、資産管理ツールの「インストール済みソフトウェア一覧」に素直に載ってきません。「開発チームが検証用に立てたまま忘れられたGitea」が、社内ネットワークやDMZに残っていないかを、まず疑ってください。
何が起きたのか
開発元のGiteaプロジェクトが2026年8月2日に公開したアドバイザリ（GHSA-6v53-hr58-556r）によれば、脆弱性はOrg-mode形式のマークアップをプレビューする機能にあります。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-59774 |
| アドバイザリ | GHSA-6v53-hr58-556r（2026年8月2日公開） |
| 深刻度 | CVSS v3.1 基本値 9.8（緊急）※開発元評価 |
| ベクタ | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 種別 | CWE-22（パストラバーサル） |
| 影響バージョン | 1.22.1 〜 1.27.0 |
| 修正版 | 1.27.1（2026年7月27日公開） |
| 悪用 | アドバイザリ・報道とも、執筆時点で実際の悪用の確認報告なし |
なぜ「公開リポジトリが1つあれば足りる」のか
Giteaは POST /{owner}/{repo}/markup というエンドポイントを持っています。これはマークアップをHTMLに変換して見せるためのAPIで、ログインは任意です。対象リポジトリが公開設定で、コード表示が有効になっていれば、匿名のアクセスでもこの権限チェックを通過します。
ここでファイル名を .org、本文にOrg-modeの #+INCLUDE ディレクティブを指定すると、Giteaは内部でOrg-modeレンダラを呼び出します。Giteaはこのレンダラ（Goのライブラリ go-org）を既定設定のまま初期化していました。go-org の既定のファイル読み込み処理は、絶対パスを渡せばそのままOSのファイル読み取り関数に流す実装です。結果として、Giteaの実行ユーザーが読めるファイルはすべて読み取れてしまいます。
アドバイザリが挙げる影響は、単なる情報漏えいにとどまりません。
- 設定ファイル
app.iniに書かれたINTERNAL_TOKEN、OAuth／JWTの鍵素材、デプロイ情報が読み取られる - 抜き取った内部トークンを使い、内部ロガー経由でGitフックを注入できる
- その後、誰かが（あるいは攻撃者自身が）匿名でcloneした瞬間に、Giteaを実行しているOSユーザーの権限でコマンドが実行される
「読み取りだけ」で終わらず、認証情報の窃取を挟んで実行権限まで繋がる。CVSSが9.8になっているのはこのためです。なお、この欠陥はGitea 1.22.1（2024年7月4日公開）から存在していたとアドバイザリは記しており、約2年間、修正されないまま稼働していたことになります。
いちばんの問題は「脆弱性スキャナに映らない」こと
この脆弱性の実務上の厄介さは、深刻度そのものよりもどの脆弱性データベースにも載っていない点にあります。筆者が2026年8月16日時点で各データベースを直接照会した結果は次のとおりです。
| 参照先 | 2026年8月16日時点の状態 | 実務への影響 |
|---|---|---|
| NVD（米国国立脆弱性データベース） | CVE ID Not Found（未登録） | CVSS基本値もCPEも取得できない |
| OSV.dev | CVE-2026-59774 は Vulnerability not found | OSVを参照するSCA／コンテナスキャナが検知しない |
| GitHub Global Advisory Database | 当該GHSAは未収載（APIで404） | Dependabotのアラート対象にならない |
| CISA KEV | 未登録（2026年8月14日版カタログで確認） | 悪用済みリストを起点にした運用では拾えない |
アドバイザリはGiteaのリポジトリ内には公開されていますが、GitHubのグローバルなアドバイザリDBには連携されていません。「スキャナが何も言ってこない＝影響なし」ではないという、ごく当たり前のことが露骨に出た例です。
スコアや自動検知に依存した脆弱性トリアージを運用している組織ほど、この種の「どこにも登録されていない緊急」を構造的に取りこぼします。判断材料は、スコアの有無ではなく①悪用時に取られる権限の高さ ②対象資産の重要度の2点です。Giteaは社内のソースコードと開発者の認証情報が集まる場所ですから、②は文句なく高いと考えるべきです。
修正版のリリースノートには「緊急」と書かれていなかった
もうひとつ、パッチ適用の判断を難しくした事情があります。時系列で並べると分かりやすくなります。
| 日付 | 出来事 |
|---|---|
| 2024-07-04 | Gitea 1.22.1 公開（アドバイザリが示す影響開始バージョン） |
| 2026-07-13 | Gitea 1.27.0 公開（未修正） |
| 2026-07-27 | Gitea 1.27.1 公開＝修正版。ただしリリースノートのSECURITY欄は「Fix: orgmode render include path (#38642)」の1行のみ |
| 2026-07-30 | Forgejo v15.0.6 / v16.0.2 が同種の欠陥を修正 |
| 2026-08-02 | GHSA-6v53-hr58-556r 公開。ここで初めてCVE番号とCVSS 9.8が示される |
| 2026-08-13 | JPCERT/CC Weekly Report が「Giteaにパストラバーサルの脆弱性」として掲載／同日 Gitea 1.27.2 公開 |
7月27日にリリースノートを見た管理者が「orgmodeのincludeパスの修正か、急ぎではないな」と判断したとしても、それを責めるのは酷でしょう。重大度の情報が出そろったのは6日後で、日本語で周知されたのはさらに11日後です。この17日間、修正版は存在したのに危険性が伝わっていませんでした。
教訓は単純です。ソースコード管理基盤のような「守る側の資産」については、リリースノートの表現が地味でも、SECURITY欄に項目が立った時点で適用計画に載せる。CVE番号が付くのを待つ運用は、この種のズレに毎回やられます。
Forgejoも同じ既定値を踏んでいた
GiteaのフォークであるForgejoも、まったく同じ欠陥を持っていました。Forgejoは2026年7月30日のセキュリティリリース（v15.0.6 / v16.0.2）で修正しており、そのリリースノートには次の趣旨が明記されています。「Org-mode描画時、描画ライブラリの既定設定がサーバ上のファイルの取り込みを許しており、Forgejoはその設定を変更していなかった。ライブラリをファイルシステムへのアクセス全面禁止に設定した」。
ここから読み取れることが2つあります。
1つめは、原因がライブラリの既定値にあること。GiteaとForgejoは同じ go-org の同じバージョン（v1.9.1）に依存しています。そして執筆時点でも、go-org のコンストラクタは既定でファイル読み取り関数をそのまま割り当てる実装のままです。これは今のところライブラリ側の仕様であり、利用側が明示的に上書きしなければ同じ穴が開きます。Gitea・Forgejo以外にも同じ地雷を踏んでいるGo製品がある可能性は否定できません。ライブラリの既定値が安全側に倒れていない場合、フォーク関係にある製品は揃って同じ欠陥を抱える――という、ソフトウェアサプライチェーンの分かりやすい実例です。
2つめは、Forgejoを使っている場合も無関係ではないこと。Forgejo v15.0.6 / v16.0.2 より前を使っているなら、同様に更新が必要です。なおForgejoは2026年8月20日にも次のセキュリティリリース（v15.0.7 / v16.0.3）を予告していますので、併せて確認してください。
現場目線の所感
この件で本当にしんどいのは、パッチ適用そのものではなく「うちにGiteaが何台あるか分からない」という状態だと思います。単一バイナリで動く手軽さは、裏を返せば申請なしで立てられるということです。開発者が検証用にDockerで立てたもの、部門サーバに残った旧プロジェクトのリポジトリ、NASのアプリ機能で有効化されたもの。どれも情シスの台帳には載っていません。
そして今回は、スキャナも当局のリストも助けてくれません。NVDにもOSVにも載っていないので、SCAツールもコンテナスキャナも沈黙します。自動化された仕組みが何も鳴らない中で、人が気づいて動くしかないという状況は、限られた人員で回している情シスにとって最も削られる形の作業です。
せめてもの救いは、成立条件が明快なことです。「公開リポジトリが1つでもあるか」「バージョンが1.27.1未満か」の2点だけで該当判定ができます。判定が速い脆弱性は、棚卸しのきっかけとして使う価値があります。今回を機に、社内のGitホスティングを一度洗い出してしまうのが結局いちばん効率的だと考えます。
情シスはどうすべきか
1. 該当判定（まずここから）
- バージョン確認：管理画面のフッタ、または
gitea --version。Dockerならdocker exec <コンテナ名> gitea --version - 存在の洗い出し：既定のWeb待ち受けポートは3000/TCPです。社内セグメントとDMZに対して、この番号を含めた開放ポートの棚卸しを行ってください
- 公開リポジトリの有無：1つでも公開設定のリポジトリがあれば成立条件を満たします。「社内限定だから大丈夫」ではなく、そのGiteaに到達できる範囲すべてが攻撃面だと考えてください
2. 更新
Gitea は 1.27.1 以降へ。2026年8月13日に 1.27.2 が公開され、そこでもマークアップ描画まわりの修正が続いていますので、可能なら 1.27.2 を選んでください。Forgejo は v15.0.6 / v16.0.2 以降へ更新します。
3. 侵害の可能性を確認する
実際の悪用は執筆時点で確認されていませんが、インターネットから到達可能な状態で長期間運用していたなら、更新だけで済ませず次を確認してください。
- アクセスログ：
POSTかつパス末尾が/markupのリクエスト。Gitea側のアクセスログが無効でも、前段のリバースプロキシ（nginx／Apache等）のログに残っています - Gitフックとグローバル設定：アドバイザリは、Giteaサービスユーザーが管理下のグローバルGit設定を書き換えられる点を前提条件に挙げています。リポジトリ配下の
hooks/と、Gitea実行ユーザーのGit設定に身に覚えのない記述が無いかを確認します - 鍵と資格情報のローテーション：
app.iniが読まれた前提に立つなら、INTERNAL_TOKEN・SECRET_KEY・JWT／OAuthの各シークレットを再生成し、個人アクセストークンとWebhookのシークレットも失効・再発行します。設定ファイルが読まれる脆弱性では、パッチ適用だけでは塞がりません
4. 恒久対策は「棚卸しの仕組み」に寄せる
個別のチェックリストを増やすより、公的機関の指針で自組織の運用そのものを点検するほうが結局効きます。中小規模の組織であれば、IPAの中小企業の情報セキュリティ対策ガイドラインが、資産管理と脆弱性対応の型を示しています。インシデントを想定した動きの確認には、IPAのセキュリティインシデント対応 机上演習教材が使えます。
あわせて、開発部門に対する「サーバを立てたら情シスに一報を」という地道な働きかけも欠かせません。今回のような資産管理の穴は、技術的な対策ではなく日々の啓発でしか埋まらない部分が残ります。
まとめ
- Gitea 1.22.1〜1.27.0 は、公開リポジトリが1つあれば未認証で任意ファイルを読まれ、内部トークン経由でコード実行に至る恐れがある。修正版は1.27.1（推奨は1.27.2）。
- 執筆時点でNVD・OSV・GitHubのグローバルDB・CISA KEVのいずれにも登録されておらず、脆弱性スキャナが鳴らない。自動検知に依存した運用では取りこぼす。
- 原因は共通ライブラリの既定値で、フォーク版のForgejoも同じ欠陥を7月30日に修正している。Forgejo利用組織も更新が必要。
関連記事
- TeamCity脆弱性が悪用中、侵害痕跡の確認手順
- GitLab 19.2.2公開、XSSなど脆弱性13件
- Bouncy Castleに脆弱性22件 証明書検証に欠陥
- LoadMaster脆弱性が悪用中、KEV登録は39日後
出典
- Gitea Security Advisory GHSA-6v53-hr58-556r: Unauthenticated Arbitrary File Read can lead to RCE（2026年8月2日）
- Gitea v1.27.1 リリースノート（2026年7月27日）
- Gitea v1.27.2 リリースノート（2026年8月13日）
- JPCERT/CC Weekly Report 2026-08-13
- Forgejo: 2026-07-30 security patches（#13681）
- Forgejo security-announcements
- go-org（Org-mode描画ライブラリ）
- Gitea 公式ドキュメント: Installation from package
- CISA Known Exploited Vulnerabilities Catalog（2026年8月14日版で未登録を確認）
- IPA 中小企業の情報セキュリティ対策ガイドライン
