Malwlab
  • Home
  • Podcast Archive
  • Methodology
  • About
Sign in Subscribe
security

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.

Glenn Fryklund

Glenn Fryklund

19 Oct 2026 — 3 min read
Share
A self-hosted git forge login page on a laptop screen in a dark server room, a second hand typing into the sign-in field
A self-hosted git forge login page on a laptop screen in a dark server room, a second hand typing into the sign-in field, rendered with AI.

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.

Topics:
  • security
  • vulnerability-disclosure
  • Gitea
  • account-takeover
  • openid
  • open-source

Read more

Next.js ships two unauthenticated RCEs in one release

Next.js ships two unauthenticated RCEs in one release

Vercel's 2026-10-14 security releases (v16.4.1 and v15.5.28) fix three vulnerabilities: two critical unauthenticated remote code execution bugs and one high-severity denial of service. One of the RCEs has no workaround.

By Glenn Fryklund 24 Oct 2026
PHP2Shell: Two Unauthenticated RCEs in PHP Core, Reachable Before Your Code Runs

PHP2Shell: Two Unauthenticated RCEs in PHP Core, Reachable Before Your Code Runs

The PHP project shipped fixes for two CVSS 9.8 core vulnerabilities that let an unauthenticated request execute code before any application code runs. If you run self-hosted PHP, update now. The partial mitigations are stopgaps.

By Glenn Fryklund 22 Oct 2026
Plex Media Server: Four Flaws Chain Into Unauthenticated Code Execution

Plex Media Server: Four Flaws Chain Into Unauthenticated Code Execution

Four separate vulnerabilities in Plex Media Server, chained together, let an unauthenticated remote attacker run code with the server process privileges. Plex says the flaws are being actively exploited; CISA added all four to KEV on October 20, 2026.

By Glenn Fryklund 22 Oct 2026
A self-hosted server on a desk with a laptop showing an open terminal prompt and no password field, rendered with AI.

A missing comma opens Mercury's terminal endpoint: two CRITICAL unauth RCEs

A single missing comma in a Python list silently disabled one rule of Mercury's endpoint blocklist, leaving /api/terminals open. Two CRITICAL unauthenticated remote-code-execution flaws let any reachable network client run code on the host with no credentials.

By Glenn Fryklund 20 Oct 2026

Malwlab

Deep dives into homelab infrastructure, cybersecurity findings, and threat intelligence analysis. Practical insights from self-hosted environments, security research, and real-world threat data.

Malwlab
  • Sign up
Powered by Ghost