Gitea CVE-2026-59774 — Unauthenticated CVSS 9.8 File Read Escalates to RCE on Every Self-Hosted Instance
On August 2, 2026, Gitea shipped a critical fix for CVE-2026-59774, a path traversal that lets an unauthenticated attacker read any server file via Org-mode markup rendering on a public repository. Worse: by reading the INTERNAL_TOKEN from app.ini, the attacker can escalate to remote code execution. Every self-hosted Gitea administrator must patch and rotate secrets immediately.
August 2, 2026, 10:00 UTC. The Gitea team published advisory GHSA-6v53-hr58-556r alongside version 1.27.1. The vulnerability — CVE-2026-59774 — scored a CVSS 9.8 (Critical). The attack vector is deceptively simple: an unauthenticated attacker sends a POST request to a public repository’s markup rendering endpoint, and Gitea’s Org-mode parser returns the contents of any file readable by the service account.
This is not a theoretical vulnerability. It is the third critical CVE affecting Gitea in 2026, and the pattern is now documented: each flaw is exploited in-the-wild within 13 days of the patch release. If you self-host Gitea, you cannot afford to wait for the next maintenance window.
The Mechanics: One Org-Mode Line Is Enough
The vulnerability lives in the repository markup rendering path. When a user — or an anonymous visitor — requests markup rendering via POST /{owner}/{repo}/markup, Gitea processes the content as Org-mode markup if the filename carries a .org extension.
The problem is in how Gitea initializes the go-org library. It does not replace go-org’s default file-reading callback. The result: a perfectly legitimate Org-mode directive —
#+INCLUDE: "/etc/gitea/app.ini" — is enough to read the instance’s complete configuration file. The app.ini typically contains:
- The INTERNAL_TOKEN, used for inter-service authentication
- OAuth secrets (GitHub, GitLab, OpenID Connect)
- JWT keys (LFS, signing)
- Database credentials
- SMTP credentials and integration tokens
The exploitation condition is nearly trivial: the repository must be public with its code unit enabled. No prior authentication, no user interaction, no account — just a well-formed POST request.
The RCE Escalation: INTERNAL_TOKEN as the Keys to the Kingdom
Reading app.ini is already catastrophic. But the GitHub advisory explicitly classifies the vulnerability as CWE-22 (path traversal) with an additional warning: the attacker can use the stolen INTERNAL_TOKEN to inject a Git hook into a repository.
The INTERNAL_TOKEN is the master secret Gitea uses to authenticate its own internal API calls. With this token, an attacker can call Gitea’s internal API and modify a repository’s Git hooks — for example, injecting a post-receive hook that executes an arbitrary system command.
The malicious hook then executes with the privileges of the Gitea service account (typically git or gitea) as soon as anyone pushes to the repository — or by simply triggering the operation via the API. The result is full remote code execution on the server hosting the Gitea instance.
Affected Versions and Fix
| Affected Versions | Fixed In |
|---|---|
| Gitea 1.22.1 through 1.27.0 | 1.27.1 (or later) |
The flaw was introduced in version 1.22.1 — meaning every instance updated since early 2025 is potentially vulnerable. The fix in 1.27.1 replaces go-org’s default file-reading callback with a version that rejects absolute paths and restricts reads to the repository directory.
Gitea provides no workaround. Upgrading is the only mitigation.
The Context: Third Critical Gitea CVE in 2026
CVE-2026-59774 is part of an alarming series. ByteIota documented the pattern: CVE-2026-20896 (one-header admin bypass) was actively scanned by threat actors within 13 days of disclosure. CVE-2026-27771 (private container image leak) followed the same trajectory.
The lesson is brutal but clear: self-hosted Gitea instances are now a priority target for automated post-disclosure scans. The grace period between patch publication and in-the-wild exploitation is measured in days, not weeks.
Verdict: Patching Is Not Enough — Rotate Your Secrets
Upgrading to Gitea 1.27.1 is the absolute priority — but it is not sufficient. If your instance was exposed before the patch, you must assume your app.ini may have been read. The post-patch actions are as critical as the patch itself:
- Upgrade all instances to Gitea 1.27.1+
- Regenerate the INTERNAL_TOKEN (
gitea generate secret INTERNAL_TOKEN) - Rotate all OAuth secrets (GitHub, GitLab, OpenID) registered with the instance
- Rotate JWT keys (LFS, signing)
- Change database passwords and SMTP credentials
- Audit logs for suspicious requests to
/markupwith.orgextensions or#+INCLUDEdirectives
If you self-host Gitea on an exposed network — even behind a reverse proxy — treat this CVE as a potential compromise of your instance, not as a vulnerability to patch “soon.” The INTERNAL_TOKEN is a master key: if someone read it, your instance is no longer yours.
References
- GitHub Advisory — GHSA-6v53-hr58-556r (CVE-2026-59774)
- Cyber Security News — Critical Gitea Arbitrary File Read Vulnerability (August 4, 2026)
- ByteIota — CVE-2026-59774: Gitea File Read Escalates to RCE
- The Hacker News — Critical Gitea Flaw Let Unauthenticated Attackers Read Server Files (August 2026)
- Gitea 1.27.1 Release Notes