Critical Gitea Flaw Lets Unauthenticated Attackers Read Server Files and Execute Code

A critical vulnerability in Gitea has been identified, potentially allowing unauthenticated remote attackers to read arbitrary files on vulnerable servers and escalate to remote code execution (RCE).

This vulnerability is tracked as CVE-2026-59774 and GHSA-6v53-hr58-556r, affecting Gitea versions from 1.22.11.22.11.22.1 to 1.27.01.27.01.27.0.

It has been assigned a critical CVSS score of 3.1, with an attack vector classified as network-based, low complexity, and requiring no privileges or user interaction.

Gitea has addressed this vulnerability in version 1.27.11.27.11.27.1. Organizations using the affected versions should update immediately, especially if their Gitea instances host publicly accessible repositories.

Critical Gitea Flaw

The vulnerability is present in Gitea’s repository markup rendering endpoint:

POST /{owner}/{repo}/markup

Although this endpoint applies repository assignment and reader checks, unauthenticated users can still meet these conditions when targeting a public repository with its code unit enabled.

An attacker can submit markup directly to the endpoint without needing to commit a file, obtain write permissions on the repository, or authenticate with the Gitea instance.

By setting the rendering mode to “file” and providing a filename that ends in .org, they can invoke the Org-mode renderer.

According to the advisory, Gitea version 1.27.01.27.01.27.0 initializes the go-org library using `org.New()`. However, it does not replace its default `ReadFile` callback.

In go-org version 1.9.11.9.11.9.1, this callback resolves to `ioutil.ReadFile`. The Org-mode renderer supports the `#+INCLUDE` directive, which can accept absolute file paths.

Since the application does not restrict included paths to a designated directory, attackers can request files accessible to the Gitea service account.

This behavior is classified as CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as path traversal.

The immediate impact is the arbitrary disclosure of files. Attackers may retrieve sensitive files such as Gitea’s `app.ini` configuration file, internal bearer tokens, OAuth or JWT-related secrets, deployment metadata, and other files that the Gitea operating system user can read.

The advisory warns that exposure of Gitea’s `INTERNAL_TOKEN` can enable a more severe attack chain. An attacker could use the token to interact with internal functionality, inject a malicious Git hook via the internal logger, and trigger command execution when an anonymous user clones a repository.

Successful exploitation requires at least one publicly readable repository with a configuration that allows access to the markup route. A standard public repository with the code unit enabled satisfies this requirement, making internet-exposed Gitea deployments a priority for review.

Administrators should upgrade to Gitea version 1.27.11.27.11.27.1 or any later patched release. Until updates are applied, organizations should restrict public repository access when operationally feasible and monitor Gitea logs for suspicious requests to repository markup endpoints.

Security teams should also rotate `INTERNAL_TOKEN` values and other credentials stored in Gitea configuration files if exposure is suspected. Additionally, review Git hooks, global Git configurations, and recent repository activity for any unexpected changes.

This vulnerability was discovered by xbow-security, triaged by Guido Leo of Xbow, and independently reported by the researcher known as NightRang3r.

ALERT: 20+ government sites delivered malware to businesses and citizens. See full attack research to check your own exposure.