Technology1 min read

Release Of 28.0.0

By · Published by Everything Blog

In short

Gitea has officially launched version 28.0.0 after opting to drop the historical "1." prefix from its versioning format. Beyond tracking improvements like diff file filters and bot accounts, the release serves as an urgent security update for administrators. Specifically, the patch set resolves server-side request forgery risks alongside vulnerabilities in fork pull request workflow approvals and concurrency.

Key points

  • System administrators are strongly urged to upgrade their Gitea instances as soon as poss…: System administrators are strongly urged to upgrade their Gitea instances as soon as possible.
  • Patches resolve multiple security risks including stored cross-site scripting within the…: Patches resolve multiple security risks including stored cross-site scripting within the platform's container registry.
  • The update eliminates vulnerabilities tied to Git tree manipulation, SSRF exposures, and…: The update eliminates vulnerabilities tied to Git tree manipulation, SSRF exposures, and egress bypasses in repository migrations.

Sources checked by our analysis pipeline: 1

We are thrilled to announce the latest release of Gitea v28.0.0.

Gitea drops the historical 1.

prefix from its version numbers, so this release is 28.0.0 rather than 1.28.0.

Highlights include audit logging, bot accounts, HTTPS deploy tokens, user impersonation for administrators, code-owner approval rules, diff file filters, and an Actions queue view. See the changelog for everything else.

We are very thankful for the many people who have contributed to the project by sending code patches, reporting issues, translating, and supporting us in many other ways.

Security

Section titled “Security”This release addresses the following security vulnerabilities. Please upgrade as soon as possible.

- CVE-2026-104632: Cancelling and then re-running an approval-pending fork pull request run dispatched its workflow to runners while the run was still marked as needing approval, letting a first-time contributor run code on self-hosted runners without approval. An authorized re-run is now treated as an explicit approval and records the approver. Fixed by #39399. Thanks to @DshtAnger for reporting the issue, and to @bircni and @silverwind for the patch.

- CVE-2026-104626: Approving a fork pull request run…

Technology

More in Technology