Giteaはバージョン28.0.0をリリースし、認証バイパス、不正なワークフロー実行、サーバーサイドリクエストフォージェリ（SSRF）、アクセス制御の不備にまたがる20件の脆弱性を修正しました。
2026年9月30日に公開されたこのリリースでは、従来のバージョン表記にあった「1.」の接頭辞が廃止されました。開発陣はユーザーに速やかなアップグレードを促しています。ただし、発表には深刻度スコアが示されておらず、悪用が確認されたという報告もありません。
認証に関する脆弱性の一つであるCVE-2026-103059は、Gitea内蔵のSSHサーバーに影響します。公開鍵の照合に大文字・小文字を区別しないSQLのLIKE演算が使われていたため、大文字・小文字だけを変えて偽造したRSA鍵が、別のユーザーのアカウントに一致してしまう恐れがありました。
修正パッチではこの比較方法をフィンガープリントによる識別に置き換え、アカウント照合の弱点を解消しました。CVE-2026-96404は、再インストール時に管理者の認証をバイパスできる別の脆弱性です。
既存のデータベースに対してインストーラーを実行すると、アカウントのパスワードを検証しないまま、既存の管理者のセッションが発行される場合がありました。ユーザーが1人だけのデータベースでは、再インストールの確認手順も省略されていました。
したがってこの脆弱性は、通常のログイン認証を無条件に回避できるものではなく、インストール処理のワークフローに関する問題です。コード実行のリスクは、Gitea Actionsの承認処理に集中しています。
CVE-2026-104632では、承認待ちのフォーク元プルリクエストのワークフローをキャンセルして再実行すると、承認が未完了のままジョブがランナーに割り当てられる状態になっていました。
その結果、初めて貢献する人物が、承認なしでセルフホストランナー上でコードを実行できてしまう恐れがありました。現在は、許可された再実行について、承認の事実と承認したユーザーが明示的に記録されます。
もう一つの脆弱性であるCVE-2026-94205では、イベントを起こした主体の身元しか確認していませんでした。このため、メンテナーが引き起こしたイベントを通じて、信頼できないフォークのワークフローが承認なしで実行される恐れがありました。
Giteaは現在、イベントの実行者とプルリクエストの作成者の両方を確認します。関連する修正として、キャンセル済みのジョブが承認によって再開しないようにしたほか、未承認のワークフローが共有の同時実行グループを通じて信頼できる実行をキャンセルすることも防ぎます。
複数の脆弱性は、外向きネットワークの制限を損なうものでした。CVE-2026-70357では、ホスト名の検証とGit接続の確立が切り離されていたため、DNSリバインディングによって内部ホストに到達できました。
そのほかにも、複数応答のDNS、HTTPリダイレクト、許可リスト入りドメイン、保存時にしか接続先を検査しないプッシュミラーに関する欠陥がありました。一部の経路では、内部リソースの読み取りや書き込み、強制プッシュが可能でした。
Giteaは現在、Gitのネットワーク操作を内部プロキシ経由にし、接続時にエグレスポリシーを適用します。管理者は変更された設定を確認する必要があります。strictモードは原則拒否（deny-by-default）で動作しますが、デフォルトのlaxモードでは、セキュリティ用ホスト許可リストが公開先に対して排他的にはなりません。
このリリースでは、コンテナレジストリのレスポンスに含まれていたストアドクロスサイトスクリプティングも修正しました。さらに、Gitツリーのエントリが重複することで、悪意のあるファイルをレビュー担当者から隠せる問題も解消しています。
このほか、リポジトリ権限が残り続ける問題、デプロイキーの認可エラー、インスタンスのクラッシュ、メモリを使い果たす恐れのあるワークフローマトリクスにも修正が入りました。
管理者はアップグレードを優先し、破壊的変更を確認したうえでデータをバックアップし、バイナリまたはコンテナを入れ替えて再起動してください。バージョン28.0.0にはGit 2.25以降が必要です。
監査ログは利用できますが、デフォルトでは無効です。また、完了したActionsの実行履歴は、アップグレード前に保持設定を変更しない限り、400日で期限切れになります。
1万6,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業の負担を減らしています。チームで試してみる
翻訳元: https://cyberpress.org/critical-gitea-vulnerabilities/
