Critical Gitea Vulnerability: Reading Server Files via Org Markup Without Logging In

The developers of the self-hosted Git platform Gitea have patched a critical vulnerability that allowed arbitrary files on the server to be read without any authentication. The bug was assigned the identifier CVE-2026-59774 and the highest possible CVSS rating for its class — 9.8. The official advisory was published on August 2, and the fix is available in version 1.27.1.

Builds from 1.22.1 through 1.27.0 are affected. The attack requires neither an account nor write access to a repository — a single public repository with the code section enabled and specially crafted markup in Org-mode format is enough.

Where it broke

The file-reading path runs through the markup rendering endpoint POST /{owner}/{repo}/markup. The route allows optional authentication and checks read access — but an anonymous request passes this check successfully for any public repository. An instance with no public repositories is not exposed to an anonymous attack through this endpoint.

The heart of the problem lies in the Org-mode handler. In Gitea 1.27.0, the go-org library was initialized with a call to org.New(), and the default file-reading handler (ioutil.ReadFile in go-org 1.9.1) was not overridden. The Org-mode directive #+INCLUDE accepts absolute paths and passes them to this handler. All an attacker has to do is submit markup with Mode: file — and in response they receive the contents of files accessible to the service account. The patch (PR #38642, backported in #38645) now returns the include path as plain text rather than reading it from the file system.

From reading a file to executing commands

The bug on its own does not grant remote code execution in a single request. However, according to Gitea's advisory, the chain can be extended: read app.ini, extract the INTERNAL_TOKEN, use the internal logger to inject a Git hook, and trigger it during an anonymous clone. The Hacker News notes that no independently published exploit demonstrating this chain could be found — for now the scenario is confirmed only by the vendor itself.

What administrators should do

Gitea Cloud instances are updated automatically, while owners of local installations are strongly urged to move to 1.27.1 immediately. An update alone may not be enough: if the logs show a call to the markup endpoint on a vulnerable build, all data accessible to the service account should be considered compromised, and the internal token, OAuth and JWT material, and database credentials should be rotated. It is also worth checking the repository hook directories for stray executable files.

The vulnerability was discovered by the autonomous offensive-security system XBOW Security; the same issue was independently reported by a researcher going by the handle NightRang3r. As of August 5, no cases of exploitation in the wild had been recorded, and the CISA KEV catalog contained no such entry. This is not the first critical hole in Gitea in recent months: in June an authentication bypass via reverse proxy was fixed, and in May an access-control problem in the container registry.

Source: The Hacker News