A single #+INCLUDE line in a Gitea markup preview is enough for an anonymous visitor to pull your server's config file straight off disk, and from there, the path to running their own code is depressingly short.
If you self-host Gitea and it's reachable on the internet, anyone can currently read files off your server without an account, a password, or a single click from you — and Gitea's own advisory lays out a documented path from there to running their own commands. CVE-2026-59774 was disclosed August 2, patched in version 1.27.1, and it's rated 9.8 out of 10 for a reason: it needs nothing from the victim at all.
How a markup preview leaks your config file
The endpoint is POST /{owner}/{repo}/markup, normally used to render README and wiki previews. Gitea supports Org-mode through the go-org library, and the rendering path was wired up without the custom file-read callback that's supposed to sandbox what it can touch. That means an Org-mode #+INCLUDE directive pointed at an absolute path — say, the server's own app.ini — gets read and rendered straight into the preview output. The only requirement is a public repository with a readable code unit, which describes most default Gitea instances.
The documented path from file read to shell
1
Attacker sends a crafted markup request with an Org-mode #+INCLUDE pointing at app.ini.
2
The response leaks INTERNAL_TOKEN inside the rendered preview.
3
The stolen token is used to inject a malicious Git hook through Gitea's internal logging API.
4
The hook fires the next time anyone clones the repository anonymously, running as the Gitea OS user.
To be precise about what's actually confirmed: Gitea's own advisory lays out that escalation path, but as of publication, The Hacker News reported no independently published proof-of-concept demonstrating the full chain end to end. That distinction matters — the file-read half is trivial and unauthenticated on its own; the jump to code execution requires chaining three separate steps correctly.
This isn't Gitea's only rough month
We wrote up an earlier unauthenticated RCE in Gitea's diff-and-patch git-hook handling not long ago, and the pattern lines up with what's hitting other self-hosted dev tools right now — JetBrains' TeamCity had its own unauthenticated deserialization RCE, and Rails' Active Storage shipped a near-identical file-read-to-RCE shape a few weeks earlier. Self-hosted developer infrastructure — the stuff most exposed teams forget sits on the open internet — is having a rough few months.
Self-hosted git platforms are attractive targets precisely because teams treat them as internal tools, not internet-facing servers. · Unsplash
Quick answers
Is CVE-2026-59774 being actively exploited right now?
No confirmed in-the-wild exploitation had been reported as of this writing, but the bar to exploit the file-read half is low enough that treating it as urgent regardless is the right call.
Do I need a public repository for this to affect me?
Yes — the flaw requires an anonymous user to satisfy Gitea's reader checks, which happens on public repos with a readable code unit. Fully private Gitea instances with no public repos aren't reachable this way.
Does upgrading to 1.27.1 fix an already-compromised server?
It closes the hole, but if INTERNAL_TOKEN was already read, rotate it and your database credentials after upgrading — a patch doesn't invalidate a secret that already leaked.
Does this affect Gitea's hosted or cloud offerings?
This concerns self-hosted Gitea instances administrators run themselves. Check with any managed provider directly for their own patch timeline.
9/ 10
Verdict
Patch priority
Anyone self-hosting Gitea 1.22.1 through 1.27.0 with even one public repository should upgrade to 1.27.1 today and rotate INTERNAL_TOKEN as a precaution. This is about as close to "no excuse to wait" as CVEs get — no authentication required, no user interaction, and the fix is a version bump.
Best for: Anyone self-hosting Gitea with at least one public repository
If there's a lesson underneath the specific bug, it's the same one every self-hosted-tool CVE this year keeps teaching: the software you run because it feels safer than trusting a cloud vendor is only actually safer if you patch it as fast as that vendor would. Put Gitea's release feed somewhere you'll actually see it, not just the repo you forgot you starred.
