Gitea Patches 27 Security Flaws, Including Critical SSH Authentication Bypass and SSRF

Gitea has released security updates addressing 27 reported flaws across versions 28.0.0 and 28.1.0, including a critical SSH authentication bypass and server-side request forgery (SSRF) weaknesses.

The fixes cover account access, repository permissions, automated workflows, and connections to internal systems. Administrators should treat the update as an urgent priority for their development infrastructure.

Released on September 30, Gitea 28.0.0 lists 20 CVEs in its security notes. The reported total of 27 spans that release and the follow-up 28.1.0 update, rather than 28.0.0 alone. Gitea also dropped its historical “1.” version prefix, making this release 28.0.0 instead of 1.28.0.

The standout issue, CVE-2026-103059, carries a CVSS score of 9.1 and affects deployments using Gitea’s built-in SSH server. Its public-key lookup used an SQL LIKE comparison that ignores letter case on some databases, including the default SQLite database. This could cause a specially crafted RSA key to match another user’s registered key.

An attacker who constructs a suitable case variant of a victim’s public key and derives its matching private key could authenticate as that victim.

This is not a general bypass using any altered key; the attacker must meet those key requirements. Gitea now identifies presented keys through their fingerprints, removing the unsafe text comparison.

Gitea Patches 27 Security Flaws

Several patched flaws allowed repository migrations and mirrors to bypass outbound connection rules. CVE-2026-70357 involved a gap between hostname validation and the actual Git connection.

An attacker could change the hostname’s DNS response during that gap, directing Gitea toward an internal host after the initial security check passed.

CVE-2026-101027 allowed an approved domain to skip destination IP checks, while CVE-2026-101029 used multiple DNS answers to bypass the outbound allowlist.

Another flaw, CVE-2026-89430, let push mirrors connect to internal Git hosts after their saved addresses had passed an earlier check, potentially allowing forced pushes.

Gitea now routes Git network operations through an internal proxy that applies outbound access rules when connections occur. Administrators must review configuration changes before upgrading. For a deny-by-default policy, the release notes direct users to set EGRESS_MODE = strict and explicitly list allowed hosts.

The update also closes Gitea Actions approval gaps. CVE-2026-104632 allowed a canceled, approval-pending fork workflow to reach self-hosted runners when rerun.

CVE-2026-94205 checked only the event actor, allowing a maintainer-triggered event to run an untrusted contributor’s workflow without the required approval. Both checks are now tightened.

Other fixes address stored cross-site scripting in container blobs, duplicate Git tree entries that could hide malicious files from reviewers, and an installer flaw that issued an existing administrator’s session without checking the password. Permission fixes also remove lingering repository-transfer access and prevent deploy keys from inheriting repository-owner privileges.

Administrators should back up data, review breaking changes, and upgrade to 28.1.0. Gitea’s release notes explain the new network rules, Git 2.25 minimum, and changed workflow behavior.

Related reporting on private repository permission bypasses provides useful background on Gitea access risks. Previous coverage of Gitea RCE exploitation also shows why delayed patching matters. However, those attacks involved a separate vulnerability, not these newly fixed issues.

Stops threats before impact with a 21-minute faster MTTR. Integrate ANYRUN’s Sandbox in your SOC