Gitea 28.3.0 Fixes 21 CVEs, Most Tied to Restricted Access Tokens Acting Unrestricted

Gitea, the open-source, self-hostable alternative to GitHub and GitLab used by many university departments, research groups and independent developers to run their own Git servers, shipped version 28.3.0 on 1 November 2026. The release notes, published by the Gitea project, list 21 separate CVE entries, almost all of them variations on the same underlying problem: access tokens that administrators had scoped down to "public-only" access were, in one code path after another, treated as if they carried full account permissions.

Gitea's token system lets a user generate a personal access token restricted to public resources only, so that a script or integration holding the token cannot see a private repository, issue or package even if the account that issued it can. The 28.3.0 notes describe at least eight distinct places across the API, the web UI and Actions, Gitea's built-in CI system, where that restriction was not actually checked, so a public-only token ended up behaving like an unrestricted one.

One entry in the list is not a token-scope bug at all but a full account-takeover flaw. CVE-2026-120263 describes how, on instances running automatic account linking with open registration, the link-account sign-up form let a user who had signed in through an OAuth2 provider enter the user name or email address of an existing account, which was then linked to the external identity and signed in without a password, according to the Gitea release notes. Gitea now only auto-links the account that the external identity's own email or user name points to.

How a Restricted Token Stopped Being Restricted

Several of the other 20 entries show the same pattern recurring in different corners of the codebase. Per the release notes, a public-only token belonging to an organization owner could be used to create an organization-level Actions runner registration token (CVE-2026-116289); a public-only token with package-write access could mount a private package's blob into a public package in Gitea's OCI container registry (CVE-2026-117685); and a public-only token belonging to a site administrator could list the email addresses of every user on the instance (CVE-2026-117635). A separate bug, CVE-2026-116474, let a running Actions job use its automatically issued GITEA_TOKEN to attach an email address and a GPG key to the built-in "gitea-actions" bot account, so that commits signed with that key displayed as signed by the Gitea instance itself.

Other entries addressed exposure that did not depend on tokens at all. The release notes describe archived repositories whose release, milestone and label API routes did not reject edits (CVE-2026-116296), and a pull-request review workflow bug, CVE-2026-118386, in which a user with only read access to a repository could submit a pull request review whose commit ID pointed at their own commit on a pull request sharing that repository; doing so caused that commit's review-triggered workflows to run without any approval, using the repository's secrets and a token able to write to it. A stored cross-site-scripting flaw, CVE-2026-113429, came from the legacy Actions artifact upload accepting an attacker-controlled Content-Encoding header that was later replayed on download, letting crafted artifacts execute script in a victim's browser on the Gitea origin.

An Independent Read

Linuxiac, a Linux-focused news site that reviewed the release independently of the Gitea project, counted "20 security vulnerabilities" in the same update and summarized the bulk of them as stemming from "weak enforcement of access token permissions." Linuxiac singled out the OAuth2 account-linking flaw and the Actions approval-bypass bug, which it said could expose "repository secrets and a token with write permissions," as the two it judged most consequential for self-hosted instances. The discrepancy between Linuxiac's count and the 21 entries in Gitea's own notes was not explained by either source, and the Gitea release notes do not assign CVSS or other severity scores to any of the individual entries.

Why This Matters Beyond Gitea's Own Users

Gitea is a common choice for universities, labs and open-source projects that want to run their own code-hosting and CI infrastructure rather than depend on a third-party platform, often specifically because self-hosting is expected to keep private research code and credentials off outside servers. A pattern of token-scope checks that were added inconsistently across the API, the web frontend and the Actions runner integration undercuts exactly that assumption: a credential meant to be safe to hand to a read-only script or a CI job could, in several of the fixed cases, have been used to reach private repositories, user email addresses, or signing keys it was never supposed to touch.

The Gitea release notes state plainly that the project "strongly recommend[s] that all users upgrade as soon as possible." For anyone administering a Gitea instance, or depending on one for coursework, a lab's code, or a project's CI pipeline, that means checking the running version against 28.3.0 and rotating any access tokens that were scoped as public-only but may have been exposed through one of the affected endpoints before the update.