, ,

Gitea CVE-2026-59774: Critical Arbitrary File Read Vulnerability

Christian Rakoot

3 min read

Abstract violet and amber illustration representing a critical security vulnerability in a code repository

Gitea, the lightweight Git hosting platform used by self-hosters and homelab enthusiasts, has a critical vulnerability (CVE-2026-59774) with a CVSS score of 9.8 that allows unauthenticated attackers to read arbitrary files from affected servers. The vulnerability is actively being exploited in the wild.

What’s at Risk

If you’re running Gitea versions 1.22.1 through 1.27.0 on your network—whether private or internet-facing—you need to patch now. This vulnerability could expose sensitive files: configuration files, SSH keys, database credentials, API tokens, anything stored on the same server.

How the Attack Works

The vulnerability comes from how Gitea initializes the go-org library. By default, go-org has a ReadFile callback function that reads files from disk. Gitea doesn’t override this behavior.

Attackers exploit this by creating repositories with malicious Org-mode files. Org-mode is a plain-text format; it supports a #+INCLUDE directive that’s meant to include other files. When Gitea renders the file for display in the web interface, it runs the #+INCLUDE directive, triggering the ReadFile callback. The server reads the included file and displays its contents to whoever is viewing the repository.

Here’s the attack in steps:

  1. Attacker creates a public repository (or compromises an existing one) on your Gitea instance
  2. Commits a file with Org-mode markup like #+INCLUDE "/etc/passwd" or #+INCLUDE "/root/.ssh/id_rsa"
  3. When someone views the repository in Gitea’s web interface, the #+INCLUDE directive executes
  4. The server reads the specified file and includes its contents in the rendered output
  5. The attacker gets the file contents

In the worst case, if you have shell scripts or application config files readable by the Gitea process, RCE is possible. But even without that, arbitrary file read is enough to steal secrets.

Why This Matters for Self-Hosters

Self-hosting Gitea means you’re responsible for security. No one else patches it for you. Many homelab users run Gitea as a central Git hub for personal projects, internal tools, or a small team. A breach here means:

  • SSH keys for your CI/CD pipelines compromised
  • Database credentials for other services exposed
  • API tokens and secrets leaked
  • Private source code accessible to attackers

If your Gitea instance is accessible from the internet, the risk is higher. Attackers actively scan for vulnerable Gitea instances.

Affected Versions

  • Versions 1.22.1 through 1.27.0 are vulnerable
  • Fixed in version 1.27.1 (released August 2, 2026)
  • Discovered by XBOW Security, triaged by Guido Leo
  • Active real-world exploitation confirmed

What to Do

  1. Upgrade to 1.27.1 or later. Most setups can pull a new Docker image or rebuild from source in under an hour.
  2. Review your logs. If you ran a vulnerable version, check access logs for suspicious activity. Look for Org-mode files with #+INCLUDE directives.
  3. Rotate your credentials. If you’re concerned about exposure, rotate SSH keys, API tokens, and database passwords.
  4. Buy time if needed. Can’t patch immediately? Temporarily restrict access to Gitea—pull it off the internet, firewall the port, or disable Org-mode rendering if your version supports it.

The Bigger Picture

This is a good example of why markup processors are dangerous. Any system that reads and renders untrusted markup (Org-mode, Markdown with includes, etc.) is an attack surface. The code looks simple—just process the format—but the callbacks and default behaviors can hide nasty surprises.

Gitea’s fix overrides go-org’s ReadFile callback to prevent arbitrary file access. It’s a reminder that even well-maintained projects can have subtle security gaps. Staying on top of updates isn’t paranoia; it’s the only real defense.

Resources

Related guides