Gitea, the self-hosted Git platform, has disclosed a critical security flaw that can lead to unauthenticated file reading. In vulnerable versions (1.22.1 up to and including 1.27.0), an attacker does not need a login and can read files that the Gitea service account can access. Even without repository write access, the right request and markup are enough to extract sensitive data.
The good news is straightforward: Gitea 1.27.1 fixes the issue. Because there are also potential follow-on steps if certain files are captured, administrators should not only upgrade, but also verify whether the vulnerable endpoint was reached and whether secrets may have been exposed.
What the critical flaw does
According to Gitea’s advisory, an attacker can read files accessible to the service account through the markup rendering functionality. The attacker does not need to be authenticated, and they do not need the ability to push to repositories.
The file-read problem is tracked as CVE-2026-59774 and carries a CVSS score of 9.8, which is why the issue is rated critical. The formal advisory was issued on August 2.
Why an attacker can do it without logging in
The vulnerable path runs through Gitea’s markup rendering endpoint: POST /{owner}/{repo}/markup. This route can accept optional sign-in, resolves the repository, and checks reader access. However, when the request is anonymous, the reader check is effectively cleared as long as the target repository is public and the relevant code unit is enabled.
That detail matters for risk assessment: if an instance has no public repositories, there is no straightforward anonymous attack route via this specific endpoint. In real-world deployments, though, many self-hosted systems do have at least one public repository, so the prerequisite is often satisfied.
The vulnerable mechanism: Org-mode rendering
The core of the issue lies in how Gitea renders Org-mode markup. Gitea uses a Go library for Org-mode processing. In affected versions, the default file-reading callback was not replaced as intended.
In the vulnerable setup, the Org-mode #+INCLUDE directive can accept an absolute path and pass it to the file-reading callback. An attacker can submit crafted markup that requests rendering with file mode, and the renderer returns file contents that the Gitea service account is allowed to access.
In other words, unauthenticated file reading is the immediate outcome. The flaw is not presented as “one request equals remote code execution.” Instead, it is a file disclosure primitive that could be used to build further impact under specific conditions.
CVE details and the separate RCE patch
While CVE-2026-59774 is the headline issue, Gitea 1.27.1 also patches CVE-2026-60004, which is a separate remote code execution bug. That RCE issue was covered earlier in a previous report, but the important operational takeaway is the same: upgrade to 1.27.1 as soon as possible to address both fixes.
How the disclosure could escalate (token-to-hook chain)
Gitea emphasizes that this vulnerability does not directly trigger remote code execution in a single step. However, the advisory describes a plausible escalation chain: if an attacker can read the app.ini file, they may extract an INTERNAL_TOKEN. With that token, an attacker could inject a Git hook by abusing the internal logging capability, and then trigger the hook through an anonymous clone.
Gitea’s advisory outlines this chain, but as reported in the article, there was no independently published exploit demonstrating the full sequence. Still, the mere possibility changes how administrators should respond: treat any potentially exposed secrets as compromised.
How to upgrade and who needs to act
Gitea states that cloud instances would be upgraded automatically during the release maintenance window. For self-hosted administrators, the recommendation is direct: move to Gitea 1.27.1 immediately.
Upgrading is necessary because it closes the unsafe file resolution behavior in the Org-mode renderer. Yet upgrading alone may not be sufficient if exposure already occurred.
What to check after updating
Gitea did not publish detailed detection guidance in its advisory, so your best approach is to correlate logs with the endpoint and payload patterns described in the disclosure.
Focus on anonymous POST requests to /{owner}/{repo}/markup, especially those that:
- Select Org-mode rendering or request file-mode output.
- Include absolute filesystem paths in the submitted markup.
Also consider the follow-on scenario. If the attacker successfully reached the vulnerable markup endpoint on an affected build, assume that anything readable by the Gitea service account could be exposed. That includes configuration material that might contain sensitive tokens and keys.
Incident response: rotate secrets and validate exposure
The article’s guidance is clear: if logs show the markup endpoint was accessed on an affected version, you should treat relevant secrets as exposed. Before declaring the instance clean, rotate the internal authentication and related credentials, including:
- The internal token used by the application.
- OAuth material.
- JWT signing material.
- Database credentials.
After credential rotation, also review hook-related directories for unexpected executable files if the escalation path described in the advisory might have been attempted. This helps catch artifacts that could persist beyond the initial disclosure.
Does this vulnerability appear to be exploited in the wild?
At the time of the report (as of August 5, 2026), Gitea’s advisory reported no exploitation in the wild for CVE-2026-59774. The article also notes that the CVE had not appeared on CISA’s Known Exploited Vulnerabilities catalog at that time.
Still, the file-read primitive had been publicly previewed before the formal advisory, according to a prior report. Even without confirmed widespread exploitation, the risk for self-hosted deployments remains because the flaw is readily actionable wherever prerequisites are met.
How the fix works in Gitea 1.27.1
The remediation was implemented via a code change that alters how Org-mode includes are handled. In the vulnerable versions, the renderer effectively resolved include paths against the server filesystem.
In Gitea 1.27.1, the Org-mode include path is overridden so that it is returned as plain rendered content rather than being resolved into a server filesystem read. A regression test was added to ensure include-path rendering behaves safely.
Who reported and tracked the issue
Gitea credits the discovery to XBOW Security, an autonomous offensive security system, with triage by Guido Leo. The same issue was independently reported by Shai Rod (online known as NightRang3r).
From an operational perspective, what matters most is the outcome: the same vulnerability has multiple lines of confirmation and a clear fixed version you can deploy.
Bottom line: act quickly, then validate
Gitea’s unauthenticated file reading vulnerability is serious because it can expose any file accessible to the Gitea service account—without login and without repository write privileges. Upgrade to Gitea 1.27.1 as the immediate mitigation.
Then validate. If your logs indicate that the vulnerable markup endpoint was hit on an affected build, rotate sensitive tokens and credentials and inspect for unexpected hook artifacts. That two-step approach—upgrade plus verification—reduces the chance that a disclosure turns into deeper compromise.
Source: https://thehackernews.com/2026/08/critical-gitea-flaw-let-unauthenticated.html
