Self-hosted Git "Gitea" hit by admin-takeover flaw: CVE-2026-20896 and 8 more, update to 1.26.4

"Gitea," the self-hosted tool developers use to store and manage source code on their own servers, has been patched for nine security flaws, with the fix shipping in version 1.26.4. The most serious, CVE-2026-20896, scores 9.8 on the 10-point severity scale (CVSS)—about as high as it gets. Under a specific configuration, an attacker can impersonate the administrator with no password and no login at all.

Like GitHub or GitLab, Gitea stores and shares program source code. The difference is that you install it on your own server and run everything in-house. That "keep the code in your own hands" appeal has made it popular with small companies, internal teams, and home-lab enthusiasts. This round of fixes matters to everyone who runs their own Gitea instance.

The developers published the fixed release in late June 2026, and the individual vulnerability details (CVE numbers) followed in early July. No active exploitation has been confirmed so far, but the mechanism is simple enough that ignoring it is unwise. The bottom line first: if you self-host Gitea, update to 1.26.4 as soon as you can.

The nine vulnerabilities at a glance

The release closes nine issues in total. Sorted by severity, they look like this. The more dangerous ones hinge on whether they can be triggered remotely without logging in.

Beyond these, smaller information-disclosure holes were also closed, such as reading private commits with an unscoped token (CVE-2026-27761). The row of 9.8s looks alarming, but what matters is whether your setup meets the precondition. That's what the next section sorts out.

Is your Gitea actually at risk?

CVE-2026-20896 scores 9.8, but not every Gitea is instantly at risk. Exploitation requires two conditions to be true at the same time, as spelled out in the official security advisory.

Why does the combination matter? The Docker image shipped with its "trusted sources" setting hard-coded to REVERSE_PROXY_TRUSTED_PROXIES = * (trust everything). That value should list only your own front-end server (typically loopback, i.e., itself). Because it trusted everything, an instance with reverse-proxy auth enabled would accept the contents of an X-WEBAUTH-USER header from anywhere as the "logged-in user."

Conversely, if you don't use reverse-proxy authentication (which covers many standard setups), CVE-2026-20896 doesn't apply. Start by checking two things: "Is this the Docker image?" and "Is reverse-proxy auth enabled?" If yes, patch first; even if no, the other eight issues still make updating necessary.

Who would target this, and why

The likely attacker is someone scanning the internet for self-hosted Gitea servers. Company dev servers and instances people stand up at home are reachable by anyone who knows the URL. An attacker sweeps for exposed Gitea instances and picks out the ones matching the conditions above.

Against a matching server, the move is trivial: add one header saying "you are admin" and send a single request. No password, no one-time code. Gitea treats the sender as an administrator and hands over the full run of the interface.

Losing the admin account is costly. Every repository's source code, the SSH keys used to connect to other services, and the passwords and API keys stored for automated builds (CI/CD) all fall into the attacker's hands. Source code can contain internal designs or credentials committed by mistake, giving attackers a foothold to move into production systems. The same shape has played out with the unauthenticated takeover flaws in 'Gogs' (the project Gitea was forked from) and the recurring vulnerabilities in self-hosted GitLab. Running your own Git server means owning the responsibility to patch it.

A closer look at the main flaws

CVE-2026-20896: admin impersonation with one header (9.8)

The headline issue. The cause, as above, is that the Docker config template embedded REVERSE_PROXY_TRUSTED_PROXIES = *. Gitea's real default is 127.0.0.0/8,::1/128 (trust only itself), but the Docker image swapped that for "trust everything."

Anyone able to reach the container's HTTP entry point directly can send a header like X-WEBAUTH-USER: admin and be treated as that user. The attack is remotely reachable, needs no authentication, and needs no user interaction—which is why NVD scored it CVSS 9.8. The fix stops reverse-proxy auth from switching on automatically based on the trusted-proxy list; now it runs only when an administrator explicitly opts in. The report came from @rz1027 and the fix from @bircni.

CVE-2026-22874: an SSRF into the internal network (9.6)

Incomplete allow-list filtering in webhooks (which notify an external URL when an event fires) and repository migration. Via SSRF (making the server reach internal addresses it shouldn't on your behalf), a logged-in user can have Gitea reach internal-only addresses. It needs a login (a regular user account suffices), but can enable internal network probing or theft of cloud metadata.

CVE-2026-58426: reading someone else's artifacts (9.6)

The download URLs signed by Gitea's build feature (Gitea Actions) had an ambiguity in signature verification, letting a user read another repository's artifacts or overwrite another task's state. This one was already fixed in 1.26.2. Build artifacts can include build-time configuration and outputs, so it leaks information across permission boundaries.

Other important fixes

CVE-2026-58424 permanently bypasses the approval gate for externally submitted changes (pull requests from forks), risking malicious code slipping into automated builds. CVE-2026-27775 escalates a single-branch write permission into all-repository write. CVE-2026-26231 is a permission-check flaw that lets someone commit to a repository that should be read-only. All require a login, but they become insider-abuse risks in multi-user organizations. The full set of nine is covered in the release announcement and this vulnerability database summary.

What to do now: update to 1.26.4

The fix is simple: update to the latest 1.26.4. The security patches are in 1.26.3 too, but the developers note that "1.26.3 still carries a regression on the repository code view, so move on to 1.26.4." If you already installed 1.26.3, bump to 1.26.4 soon.

If you can't update right away, and only for Docker instances that use reverse-proxy auth, you can close the most dangerous CVE-2026-20896 path by narrowing REVERSE_PROXY_TRUSTED_PROXIES from "everything" to just your front-end server's address, or by temporarily disabling reverse-proxy auth. That's a stopgap; the real fix is updating.

If you run "Forgejo," a project forked from Gitea, note that it is developed independently, so the same version number won't necessarily carry the same fix—check Forgejo's own advisories separately. That said, a Docker setup that trusts "all" proxies is dangerous there for the same reason.

Is it being exploited?

So there is no sign of widespread exploitation yet. Still, a flaw as simple and powerful as CVE-2026-20896 tends to draw follow-on attacks once details are public. "Not attacked yet" is a poor reason to delay patching.

Wrap-up

The appeal of Gitea—managing your own source code in-house—comes with the flip side that the call and the work of patching fall entirely on the operator. In this batch, the heaviest flaw, CVE-2026-20896, is conditional ("Docker image + reverse-proxy auth"), but when it applies it yields the worst case: password-free admin takeover. The other eight can lead to insider information leaks or privilege escalation by logged-in users.

The to-do list is clear. If you self-host Gitea, update to 1.26.4. If you run the Docker image with reverse-proxy auth, do it first. If you use Forgejo, check your project's advisories. Getting these done before attackers start probing is the smart play.

References

• ▸ Gitea Blog - Gitea 1.26.3 and 1.26.4 are released
• ▸ GitHub Security Advisory GHSA-f75j-4cw6-rmx4 (CVE-2026-20896)
• ▸ NVD - CVE-2026-20896
• ▸ NVD - CVE-2026-22874
• ▸ NVD - CVE-2026-58426
• ▸ Hive Security - One HTTP Header, Full Admin Access: Gitea's June 2026 Security Release Explained
• ▸ Cybersecurity Help - SB2026062240: Multiple vulnerabilities in Gitea