【ITニュース解説】Sizing a self-hosted forge: finding Gitea instances before you patch

自己ホスト型で運用されているGiteaという開発プラットフォームに関する重要なセキュリティ情報が発表された。Giteaは、ソフトウェア開発において欠かせない「ソースコード管理」を行うためのツールで、Gitという仕組みを使って、複数人での開発を効率的に進めることができる。多くの企業や開発チームが、自社サーバーやクラウド上にGiteaを構築し、利用している。今回のニュースは、Giteaのバージョン28.0.0と28.1.0で、合計27件ものセキュリティ上の問題が修正されたこと、そしてそれらの問題に対処するためにシステム管理者がまず何をすべきかを詳しく解説している。

特に注目すべきは、共通脆弱性識別子（CVE）として「CVE-2026-103670」など、複数の脆弱性が修正された点だ。CVEとは、世界中で発見されたサイバーセキュリティ上の欠陥（脆弱性）に付与される、共通の識別番号である。これにより、どのシステムのどの部分にどのような問題があるのかを正確に把握できる。今回の修正には、深刻度を評価するCVSS v3スコアで7.5と評価されたCVE-2026-103670が含まれている。これは、権限のないユーザーが、本来承認されていないフォーク（元のコードを複製して開発を進めること）のワークフローを停止させられる可能性があるという問題だ。さらに、最も深刻度が高いとされる9.1点の「CVE-2026-103059」は、Giteaに内蔵されているSSHサーバーの脆弱性に関わるもので、そして8.1点の「CVE-2026-96404」は、ウェブインストーラー（Giteaをウェブブラウザから簡単にインストールするための機能）がパスワードチェックなしに管理者セッションを発行してしまう可能性があるという、極めて危険な問題も含まれている。これらの脆弱性は、現時点では実世界での悪用は確認されていないが、いつ攻撃に利用されてもおかしくない状況である。

このようなセキュリティ問題が発覚した際、システム管理者が直面する最大の課題は、「自社でGiteaをいくつ運用しているのか、そしてそのうちいくつがインターネットに公開されているのか」という問いに答えることだ。Giteaのような自己ホスト型の開発プラットフォームは、通常、IT部門のプラットフォームチームではなく、個々の開発チームや開発者が、自分たちのニーズに合わせてサーバーを立ち上げることが多い。この運用パターンは、結果として、長期間運用され、あまり文書化されていない、小さなGiteaインスタンス（Giteaが動作しているサーバーや仮想マシンのこと）が多数存在することにつながる。中には、数年前にコンテナイメージでセットアップされて以来、一度も更新されていないものや、リバースプロキシと呼ばれる仕組みの背後で特定のホスト名で動作しているものなど、その形態は様々である。これらのインスタンスがインターネットに直接公開されているか、それとも内部ネットワークに閉じられているかによって、外部からの攻撃にさらされるリスクは大きく異なる。このリスクの違いは、個々の脆弱性の深刻度の違いよりも、はるかに重要だと記事は指摘する。

したがって、Giteaのアップグレードは、まず「自社のGiteaインスタンスがどこに、いくつ存在するのか」というインベントリ（資産管理）の問題であり、次に「どのようにパッチを適用するか」という問題となる。例えば、ロードバランサー（複数のサーバーにアクセスを分散させる機器）の設定からホスト名のリストを作成しても、開発者が予備の仮想マシン上に立ち上げて、トンネル経由でアクセスしているようなインスタンスはリストから漏れてしまう可能性がある。

インターネットに公開されているGiteaインスタンスを特定するには、「フィンガープリントデータ」という情報が役立つ。フィンガープリントとは、特定の製品がウェブサイトのタイトル、HTTPヘッダー、静的ファイルなどの部分に持つ、特徴的な応答のことだ。インターネット検索エンジンの中には、こうしたフィンガープリント情報を使って、世界中のインターネットに公開されているサーバーを検索できるものがある。これを使えば、Giteaの特徴的な応答を示すホストを特定し、それが自社の所有するIPアドレスやドメインと一致するかを確認することで、インターネットに公開されているGiteaインスタンスの候補リストを作成できる。しかし、ここで注意が必要なのは、インスタンスが見つかったとしても、それがすぐに悪用可能であるとは限らないという点である。例えば、CVE-2026-103670はフォークワークフローが有効になっている必要があるなど、それぞれの脆弱性には悪用するための特定の条件が存在する。これらの条件は、外部からは見ることができないため、内部での設定確認が不可欠となる。

未知のインスタンス、つまりどのチームが管理しているのか不明で、パッチが適用されていないGiteaインスタンスは、セキュリティ上の大きな脅威となる。なぜなら、Giteaが稼働するサーバーには、開発中のソースコード、CI/CDパイプライン（自動テストやデプロイを行う仕組み）で使われる認証情報（トークン）、そしてシステムを本番環境にデプロイするために必要な認証情報など、極めて機密性の高い情報が集約されているからだ。もし、これらの情報が攻撃者によって奪われてしまえば、ソースコードの改ざんや窃取だけでなく、企業全体のシステムが乗っ取られる、あるいは機密情報が外部に漏洩するといった重大な被害につながる可能性がある。特に、ウェブインストーラーやSSHキーに関する脆弱性が悪用され、管理者権限が奪われた場合、一つの見落とされたGiteaインスタンスが、企業内のあらゆるシステムへの侵入経路となりかねない。

今回のセキュリティ問題の影響を受けるのは、Giteaのバージョン1.27.3以前の全バージョンと、28.0.0で一部修正されたものだ。全てのGiteaインスタンスは、最新の28.1.0にアップグレードすることが推奨されている。どのように導入されたインスタンスであっても、このアップグレードは必須となる。

実際に、ZoomEyeというインターネットデバイス検索エンジンで「app="Gitea"」と検索すると、2026年10月7日の時点で、世界中に116,431ものGiteaインスタンスが確認されたという。この数字は、Giteaのフィンガープリントを持つホストの数であり、個々のバージョンや設定は含まれない。この公開されているデータと、自社のIPアドレス範囲や登録ドメイン情報を照合することで、自社が管理するインターネット公開インスタンスの候補リストを作成できる。ただし、特定のCVE番号で検索しても、公開されたばかりの脆弱性ではまだインデックス化されていないことが多く、検索結果がないからといって安全だと判断するのは危険である。

これらの問題に対する根本的な解決策は、まず自社内のGiteaインスタンスのリストを正確に作成し、その後、全てのインスタンスをGitea 28.1.0にアップグレードすることだ。インターネットに公開されているインスタンスには、前述の外部フィンガープリントデータを使った検索が有効だが、内部ネットワークにあるインスタンスについては、ネットワークスキャンや社内の資産管理記録を確認する必要がある。また、アップグレードの際には、GiteaのUIに表示されるバージョン文字列だけでなく、実際のビルド番号を確認することが重要だ。なぜなら、コンテナ環境などでは、古いバイナリが使われたまま、UI上のバージョン表示だけが新しくなっているケースもあるからだ。すぐにアップグレードできないインスタンスに対しては、一時的な緩和策として、ウェブインストーラーへの外部からのアクセスを遮断する、マイグレーション（データ移行）やミラー作成（複製）の機能を制限する、そしてフォークされたプルリクエスト（コード変更の提案）のワークフローには必ず承認を求める、といった対策を講じるべきである。

システムエンジニアを目指す上で、このようなセキュリティ問題への対応は避けて通れない。自社システムがどのような構成で、どこに何があるのかを常に把握し、最新のセキュリティ情報を追いかけ、迅速かつ適切に対策を講じる能力は、今後ますます重要となるだろう。