FR
live

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.

A vault door slightly ajar in a dark server room, a single kraft envelope marked with an amber seal protruding from the gap, lit by harsh overhead light

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 —

plaintext
#+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 VersionsFixed In
Gitea 1.22.1 through 1.27.01.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:

  1. Upgrade all instances to Gitea 1.27.1+
  2. Regenerate the INTERNAL_TOKEN (gitea generate secret INTERNAL_TOKEN)
  3. Rotate all OAuth secrets (GitHub, GitLab, OpenID) registered with the instance
  4. Rotate JWT keys (LFS, signing)
  5. Change database passwords and SMTP credentials
  6. Audit logs for suspicious requests to /markup with .org extensions or #+INCLUDE directives

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

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

← Back to the feed

Type at least two characters.

navigate open esc dismiss