Gitea 28.2.0 patches 12 CVEs, headlined by an OpenID account takeover
Gitea 28.2.0 ships twelve CVE fixes, led by a High-severity OpenID 2.0 flaw that let an attacker-controlled provider attach its identity to a victim's account and sign in as them, bypassing the local TOTP and WebAuthn checks.
Gitea 28.2.0 shipped on 2026-10-18 as the second maintenance release of the 28 series, and it carries twelve CVE fixes. The vendor describes it as a security maintenance release covering Actions, pull requests, authentication, and packages, and it strongly recommends that all users upgrade as soon as possible.
The flaw that leads the release is CVE-2026-104627, rated High. It sits in the OpenID 2.0 association callback in the security settings. When a user links an OpenID identity, that callback was supposed to confirm the signed-in user had started the linking. It did not. Because OpenID 2.0 permits unsolicited assertions, an attacker-controlled OpenID provider could attach the attacker's identity to a victim's account. Once that link existed, the attacker could sign in as the victim through the OpenID login path.
The fix requires a short-lived state value bound to the user before the callback will accept the assertion. That is the same class of defense you apply to CSRF: the callback now only honors a request the user actually initiated, rather than trusting a bare assertion that arrives out of the blue.
The victim's TOTP and WebAuthn do not protect against this path, because the OpenID login does not re-run those local second-factor checks. A single legacy authentication path can undercut the hardware 2FA you have configured. If you run Gitea and any account has an OpenID identity linked, that account was reachable this way until 28.2.0.
The remaining eleven CVEs are lower severity but cover a wide surface. A few are worth naming because they touch data you may not expect to be exposed:
- CVE-2026-110311: creating a draft release returned the attachments of the whole instance, including issue and comment attachments from repositories the caller could not read. That is a cross-tenant metadata disclosure.
- CVE-2026-105964: the Actions artifact v4 API read the request body with no size limit, so anyone holding a runner token could exhaust server memory. It is now capped at 1 MiB.
- CVE-2026-105661: the /{username}/-/repositories route for an individual user caused a nil-pointer panic, letting anonymous visitors trigger an error on every request. It now returns 404 for individual users.
- CVE-2026-109553: SSH certificate principals were looked up among all stored public keys instead of only principal keys, so a certificate listing another user's public key as a principal authenticated as that user when the trusted user CA accepts arbitrary principals.
The rest cover reactions on locked issues from users without write access, release-attachment cross-linking metadata exposure, private-profile info disclosure via a POST follow, stale watched-repo metadata after access loss, a repository-topics CSRF, seven API routes under /api/v1/users/{username} that were missing the visibility check, and organization-label deletion through an ID overlap.
The twelve CVEs all landed in NVD on 2026-10-18, aligned with the release. The NVD records carry no numeric CVSS scores for this batch, so the severity labels come from the vendor's GHSAs, with the headline rated High.
If you run Gitea at or below 28.1.0, the fix is a single upgrade to 28.2.0. The OpenID account takeover is the one to act on first.
Source links (named)
- Gitea 28.2.0 release blog (bircni, Technical Oversight Committee), 2026-10-18: https://blog.gitea.com/release-of-28.2.0/
- Gitea v28.2.0 GitHub release: https://github.com/go-gitea/gitea/releases/tag/v28.2.0
- GHSA-mf69-7pqq-86vx (OpenID account takeover, High): https://github.com/go-gitea/gitea/security/advisories/GHSA-mf69-7pqq-86vx
- NVD records for the 12-CVE batch (published 2026-10-18): https://nvd.nist.gov/vuln/detail/CVE-2026-104627
This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.