Gitea 28.3.0で19件修正、1.27系は28系へ上げる

自社のサーバーでGiteaを動かしているなら、28.3.0へ上げたい。11月1日に公開されたセキュリティの勧告19件は、どれも28.2.0までの版が対象で、修正は28.3.0にだけ入った。8月の1.27.3を使い続けている環境も対象に含まれ、1.27系の修正版は出ていない。

Giteaの版の番号は9月に変わり、1.27.3の次が28.0になった。1.27系から上げるときは、28.0で変わった設定を先に見直すことになる。更新の間隔や、ほかのGitサーバーとの違いは社内に置くGitサーバー4件の比較で読める。10月に公表された28.1.0より前の脆弱性は、情シスの相棒の記事にある。

19件の多くは、トークンとActionsの権限

19件のうち6件は深刻度が「高」とされた¹。対象ごとに分けると次のとおり。

対象	件数	うち「高」
公開だけに絞ったトークン	10	3
Actionsのトークンと実行	4	2
アーカイブの保護ほか	5	1

一番多いのは、公開のリポジトリだけを扱うように絞ったトークン（public-only）が、その制限を越えて動けた問題だ。たとえば、組織のリポジトリをまとめて消すAPIでは、絞ったトークンでも、非公開のものを含む組織の全リポジトリを元に戻せない形で消せた。

また、管理者のトークンを絞っていても、管理者のAPIでは制限が外れていた。全利用者のメールアドレスを一覧で引くことも、新しいサイト管理者を作ることもできた。そのため、CIなどに渡すために絞ったトークンは、その範囲を超えて使える状態だったことになる。

Actionsでは、読むだけの権限しか持たない利用者が、自分の書いたワークフローを承認なしにリポジトリのランナーで動かせた。同じリポジトリにある枝から出たプルリクエストに、自分のコミットを指したレビューを出すと起きる。その実行はリポジトリと持ち主のシークレットに加え、コミットできるトークンも受け取る。成果物（アーティファクト）のアップロードを使って、Giteaのドメインでスクリプトを動かせる問題もあった。

アーカイブしたリポジトリでも、リリースとマイルストーン、ラベルはAPIから書き換えられた。書き込みの権限がある共同作業者なら、同じタグとURLのまま、リリースのファイルを差し替えられた。

勧告とは別に、外部のIDでログインするときの修正もある。設定の[oauth2_client]でACCOUNT_LINKINGをautoにしていると、外部のIDで初めて入るときの画面で、既にある利用者名かメールアドレスを入れれば、そのアカウントにつながってログインできた。持ち主かどうかは確認していなかった。28.3.0では、外部のIDのメールアドレスか利用者名が一致するときだけ自動でつなぎ、それ以外はそのアカウントのパスワードを求める。ただし、既定値はloginなので、変えていなければ当たらない。

1.27系から上げる前に見直す2つの設定

まず、外へつなぐ先の制限が変わった。28系ではWebhookと、外部のID（OAuth2）を提供する側への接続を、[security]のALLOWED_HOST_LISTで絞る。ただし、既定のlaxのモードでは、この一覧は社内のアドレスなど公開されていない先にしか効かない。インターネット上の先は、一覧に無くても通る。そのため、一覧で公開の先まで絞っていたなら、EGRESS_MODEをstrictにしないと、その制限は外れる。このときは起動時に警告が出る。

リポジトリの移行とミラーにも、[migrations]に同じ形の設定がある。また、BLOCKED_HOST_LISTに正しくない書き方があると、Giteaは起動しない。IPアドレスのワイルドカードや、「*」だけの指定も使えなくなった。

次に、Actionsの実行の記録が消えるようになった。28.0で、完了した実行の記録を消す設定RUN_RETENTION_DAYSが足された。既定は400日で、それより古い完了済みの実行は、夜0時に動く定期の処理で消える。それまでの版では、実行の記録は消えずに残り続けていた。全部残したいなら、上げる前に0にしておく。あわせて、ログの保存の日数（LOG_RETENTION_DAYS）と、成果物の保存の日数（ARTIFACT_RETENTION_DAYS）も、0の意味が「ずっと残す」に変わった。前は、次の掃除ですべて消す設定だった。

注

1. CVE-2026-118386、CVE-2026-113429、CVE-2026-116296、CVE-2026-119441、CVE-2026-117635、CVE-2026-117685。CVSSの値は7.1〜8.7。 ↩