Gitea 28.2: Nine CVEs Patched, SSH Bypass — Upgrade Now

Gitea 28.2 landed on October 18 with nine CVEs patched, including an SSH authentication bypass that lets an attacker sign in as another user under a very common configuration, and an OpenID flaw that hands over an account to anyone who tricks the victim into clicking a link. If you run self-hosted Gitea, this is the upgrade you do today — not next maintenance window.

SSH Authentication Bypass (CVE-2026-109553)

This is the one that should get your immediate attention. When Gitea trusts a user certificate authority via SSH_TRUSTED_USER_CA_KEYS and is configured with SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything, an attacker who holds a certificate signed by that CA can register another user’s public key line as their own principal. Gitea was resolving certificate principals by searching the content of all stored public keys — not just dedicated principal keys — so the lookup matched and the authentication succeeded.

The practical result: the attacker authenticates as the victim through Gitea’s built-in SSH server or HTTP signature API. No brute force, no zero-day exploit chain — just a misplaced trust in the principal resolution logic. The exploitation difficulty is rated “easy” in the official security advisory. There is no public exploit at the time of disclosure, but that window closes quickly once a patch is out and the diff is visible.

If your instance does not use a trusted SSH CA, you are not affected by this specific CVE. You should still upgrade for everything else on this list.

OpenID Account Takeover (CVE-2026-104627)

A crafted link is all it takes. Gitea’s OpenID association callback did not verify that the signed-in user had actually initiated the linking process. An attacker running a malicious OpenID provider sends the victim a link; the victim opens it; the attacker’s identity attaches to the victim’s account. The attacker then signs in as the victim through OpenID — and because this goes through the OpenID path, Gitea’s TOTP and WebAuthn checks do not apply.

The fix is a short-lived, user-session-bound state parameter that must be present and valid for the association to complete. It is the kind of fix that makes you wonder why it was not there from day one.

The Rest of the CVE List

The remaining CVEs cover a range of severities, but none of them are theoretical. All are the kind of vulnerability that gets found in bug bounties or quiet internal audits — and now that the advisories are public, they will be tested against unpatched instances.

• CVE-2026-110311 — The draft release API returned attachments from private repositories to anyone who queried it, because the endpoint fetched all unlinked attachments regardless of repository access. Classic IDOR.
• CVE-2026-105964 — The Actions artifact v4 API accepted request bodies of unlimited size. An attacker with workflow access and a runner token could exhaust server memory and crash the Gitea process. Request bodies are now capped at 1 MiB.
• CVE-2026-97859 — API route privilege escalation via improper permissions management.
• CVE-2026-107686 — Authenticated users could interact with locked issues via the reactions endpoint, bypassing the lock entirely.
• CVE-2026-107618 — CSRF on repository topic endpoints.
• CVE-2026-110324 — Private profile data (name, location, website, bio) was visible to any authenticated user. Patched in 28.1, disclosed now.

The VSCode OAuth Fix (Finally)

Not everything in 28.2 is damage control. Gitea now pre-registers a builtin OAuth2 application for the gitea-vscode extension. Previously, users who had already authenticated the tea CLI ran into a scope conflict when the VSCode extension tried to get its own grant — Gitea kept one grant per user per application, and the scopes did not match. The extension sign-in silently failed or errored out.

With 28.2, the gitea-vscode app is separate and pre-registered with loopback redirect URIs. OAuth sign-in from the extension works correctly on 28.2.0 and later. Check the official release notes for the full list of 40+ bug fixes included in this release.

How to Upgrade

For Docker deployments, pull gitea/gitea:28.2.0 and restart your container. For binary deployments, replace the binary and restart the service. The 28.2 release itself introduces no new breaking changes if you are already on 28.x.

If you are still on Gitea 1.27.x, read the full upgrade guide before proceeding — the 28.x series has several things to handle before you restart. Key pre-flight checks:

• Git 2.25 or newer is required — Gitea will refuse to start with older versions
• Set RUN_RETENTION_DAYS = 0 in your config before upgrading if you want to keep all Actions run history (the default becomes 400 days)
• Remove wildcard entries from [migrations] BLOCKED_DOMAINS — patterns like 192.168.1.* prevent startup in 28.x
• Back up your data before any major version hop

Nine CVEs, easy exploitability on the worst of them, and no reported active exploitation yet. The window to patch before someone else closes it for you is now.