/00 — boot sequence

Hello.

Article

Gitea CVE-2026-59774: Unauthenticated File Read and RCE

August 7, 2026•7 min read
security gitea cve-2026-59774 rce path-traversal devops

Introduction

The Gitea CVE-2026-59774 vulnerability lets unauthenticated attackers read arbitrary server files on the self-hosted Git platform and chain the bug into remote code execution. Rated critical with a CVSS score of 9.8, the flaw affects Gitea versions 1.22.1 through 1.27.0 and is fixed in 1.27.1. No login, no repository write access, and no prior interaction is required. A public repository and a crafted Org-mode markup payload are enough to read any file the Gitea service account can access.

Gitea is one of the most widely deployed self-hosted Git forge platforms in the developer world, so a file read primitive that requires no authentication is an immediate call to action for every administrator running an affected build. The advisory was formally published on August 2, 2026, and the fix landed in the Gitea 1.27.1 release. This article explains the root cause, the escalation path to code execution, and the exact steps teams should take to protect their instances.

Vulnerability Details

CVE-2026-59774 is an improper limitation of a pathname to a restricted directory weakness, better known to developers as path traversal. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which captures a network reachable, low complexity, no privilege, no interaction flaw that can fully compromise confidentiality, integrity, and availability.

The affected versions span Gitea 1.22.1 through 1.27.0. The issue was discovered by the autonomous offensive security system XBOW Security, triaged by Guido Leo, and independently reported by Shai Rod, who is known online as NightRang3r. Gitea assigned the advisory GHSA-6v53-hr58-556r.

The vulnerability resolves around the repository markup rendering endpoint, which accepts a POST request to the path /owner/repo/markup. The route allows optional sign in, resolves the target repository, and checks reader access. A fully anonymous request passes that reader check against any public repository with its code unit enabled. The practical consequence is that an instance that hosts no public repositories has no anonymous attack path through this endpoint, while an instance with a single public repo is exposed by default.

Root Cause: The Org Renderer Reads Files

The actual break lives in Gitea's Org-mode renderer, the plain text format popular in the personal knowledge management community through tools like Emacs and org-roam. When Gitea introduced version 1.27.0, it initialized the go-org library with org.New() and did not override the library default ReadFile callback.

In go-org 1.9.1 that default callback is ioutil.ReadFile, a function that reads a file straight from the server filesystem. Org-mode supports a number of macros and directives, and one of them, the #INCLUDE directive, accepts absolute filesystem paths and passes them directly to that callback. The result is that an anonymous attacker can submit Org-mode markup, select the file rendering mode, and retrieve any file the Gitea service user can read.

Here is a simplified illustration of the vulnerable include path:

markup

Because the renderer passes that absolute path to ioutil.ReadFile without any path normalization, the include silently returns the file contents as rendered markup. Nothing in the code limits the path to an allowed directory, which is exactly why the advisory classifies the bug as path traversal.

Escalation to Remote Code Execution

The file read is not a one request remote code execution, but Gitea documents a realistic chain that turns it into command execution. An attacker that can read files for the service account can target the Gitea configuration file, usually named app.ini, and extract the INTERNAL_TOKEN secret. Gitea's advisory explains the full sequence:

  1. Read the configuration file to obtain INTERNAL_TOKEN and other embedded secrets.
  2. Use that token to reach an internal logger that Gitea maintains.
  3. Inject a Git hook through that internal logger.
  4. Trigger the hook during an anonymous clone, which causes command execution as the Gitea operating system user.

The escalation path demonstrates that the file read primitive is a serious threshold on any internet reachable instance. Even if a team dismisses it as a read only issue, the token to hook chain can turn disclosure into full control of the server and, depending on deployment, the surrounding environment.

As of August 5, 2026, Gitea reports no confirmed exploitation in the wild, and the flaw had not yet appeared on the CISA Known Exploited Vulnerabilities catalog. The file read primitive was, however, publicly previewed in advance of the formal advisory, and threat actors previously probed a related Gitea Docker authentication bypass within days of disclosure, which points to an active interest in this codebase.

For context, in June 2026 Gitea patched a critical reverse proxy authentication bypass in Docker images that attackers probed roughly two weeks after disclosure. In May, a container registry access control flaw was estimated to affect more than 30,000 deployments across more than 30 countries. This latest disclosure keeps Gitea central to the open source Git security conversation.

Affected Systems

The following Gitea versions are vulnerable and should be patched, 1.22.1 through 1.27.0. The fixed version is 1.27.1. Gitea independently confirmed the fix and also documented that version 1.27.1 additionally addresses CVE-2026-60004, a separate remote code execution bug in the same release line.

Every self-hosted Gitea deployment that exposes a public repository is at risk from an unauthenticated perspective. Deployments that keep every repository private and restrict the reachable endpoints are at a lower exposure, because the anonymous POST to the markup route depends on at least one publicly readable repository with the code unit enabled.

Mitigation and Remediation

The first and most important action is upgrade Gitea to version 1.27.1 as soon as possible. Cloud instances are upgraded automatically during the release maintenance window, but self-hosted administrators must move on their own schedule and should treat the patch as urgent.

After upgrading, review the Gitea release notes and the advisory GHSA-6v53-hr58-556r to confirm the changes. The fix ships in PR #38642 and was backported in PR #38645. The patched code now overrides the ReadFile callback so that an Org-mode include path is returned as plain rendered content instead of being resolved from the server filesystem. A regression test was also added for include path rendering, which means the issue is covered against future regressions.

Upgrading is necessary but may not be sufficient after a suspected exposure. If logs show the markup endpoint was reached on an affected build, treat every credential readable by the Gitea service account as exposed. Rotate the internal token, OAuth material, JWT signing material, and database credentials before considering the instance clean. Rotating secrets is the only way to neutralize a token that an attacker may have already stolen through the file read primitive.

Detection

Gitea did not publish formal detection guidance in the advisory, which leaves administrators to monitor the relevant signals on their own. The strongest indicator is anonymous POST requests to the repository markup endpoint that select Org-mode rendering or submit absolute filesystem paths.

Review access logs for repeated requests to POST /owner/repo/markup from unauthenticated sources, especially when the body targets Org syntax with a #INCLUDE directive. If the advisory escalation path is attempted, check repository hook directories for unexpected executable files. Git hooks that appear without a corresponding legitimate change are a strong signal that an attacker injected a hook through the internal logger.

Teams that want richer detection should pipe the affected endpoint into their normal SIEM or log aggregation flow and set an alerting threshold on anonymous markup requests. Because the vulnerability is triggered without a login, any sustained pattern against the markup route to public repositories deserves manual triage.

Frequently Asked Questions

Is CVE-2026-59774 exploitable without authentication?

Yes. The file read requires no account and no repository write access. An anonymous request that a markup render path against a public repository is sufficient.

Which Gitea versions are affected?

Gitea 1.22.1 through 1.27.0 are vulnerable. Upgrade to 1.27.1 to receive the fix.

Key Takeaways

CVE-2026-59774 is a critical, network reachable path traversal with a CVSS score of 9.8 that lets an unauthenticated attacker read arbitrary server files on most Gitea instances.

The root cause is the Org-mode renderer passing absolute include paths to a default filesystem read callback without any path containment.

The file read can chain through the internal token and a Git hook into remote code execution as the Gitea service account.

Upgrade Gitea to 1.27.1 immediately, and if exposure is suspected, rotate internal tokens, OAuth, JWT and database credentials.


Sources: The Hacker News Advisory Coverage, Gitea Security Advisory GHSA-6v53-hr58-556r

Automated Transmission

This entry was synthesized and populated dynamically using native API integrations.

Resources & Links