Critical Gitea Flaw Exposes Server Files and Can Escalate to RCE

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Java, JVM services and infrastructure security for US/EU teams

The short answer

What happened

On 2 August 2026 the Gitea project published a security advisory and shipped version 1.27.1, urging all users to upgrade as soon as possible. The headline issue, CVE-2026-59774, is an unauthenticated arbitrary file read reported independently by XBOW Security and by researcher Guido Leo (NightRang3r). It carries a CVSS score of 9.8 and affects every Gitea release from 1.22.1 through 1.27.0.

The flaw lives in Gitea's markup-rendering feature. A request to POST /{owner}/{repo}/markup renders content such as README files. The route includes repository-assignment and reader checks, but an anonymous user satisfies those checks against a public repository that has its code unit enabled — a very common configuration. When Gitea renders Org-mode content, it processes the #+INCLUDE directive, and in the affected versions that directive resolves absolute filesystem paths. The practical result: send crafted Org-mode markup and read back any file the Gitea service account can open.

The technical root cause is small and instructive. Gitea 1.27.0 initialised the go-org parsing library with org.New() but did not replace the library's default file-reading callback, which maps to a plain ReadFile. Nothing constrained #+INCLUDE to the repository, so the include mechanism became a path-traversal read primitive. The patch overrides that callback; the fix is version 1.27.1 or later.

How a file read becomes code execution

An arbitrary file read is already serious on a source-control server, because the very first file worth reading is Gitea's own configuration. According to the project's advisory, the exposure escalates in a short chain: read app.ini to extract the INTERNAL_TOKEN, use that token to inject a Git hook through the internal logger, and then trigger the hook during an anonymous clone. The end state is command execution on the host. Gitea 1.27.1 also fixes a directly related flaw, CVE-2026-60004, described as remote code execution via the diffpatch API through Git hook installation — reported by the same researcher.

As of the first public write-ups on 5 August 2026, CVE-2026-59774 had not appeared on CISA's Known Exploited Vulnerabilities catalog and no independent proof-of-concept exploit had been published. That is cold comfort. The file-read behaviour was previewed publicly before the formal advisory, the endpoint is trivial to reach, and the escalation path is documented. For a vulnerability this cheap to exploit on infrastructure that holds source code and secrets, "not yet in KEV" is a scheduling detail, not a reprieve.

Found partly by an AI

One detail sits at the intersection of two themes we track. One of the two independent reporters of CVE-2026-59774 was XBOW, an autonomous offensive-security system that finds and validates vulnerabilities without a human driving each step. It is a concrete example of a broader shift: AI tooling is compressing the time it takes to discover, confirm and weaponise bugs. When the same class of tools is available to defenders and attackers alike, the safe assumption is that a freshly disclosed, easy-to-reach flaw will be probed quickly.

That does not call for panic; it calls for cadence. Teams that keep an inventory of their self-hosted developer tooling, subscribe to its security advisories, and treat "critical, unauthenticated, internet-reachable" as an accelerated-patch trigger will close this window in hours. Teams that discover which internal services they run only when one is breached will not. A periodic security audit that includes the developer supply chain — Git servers, CI runners, artifact registries — is where these blind spots surface before an attacker finds them.

What it means for US & EU software teams

Gitea is attractive precisely to teams that want control: keep repositories on your own infrastructure, inside your own network, away from third-party SaaS. That instinct is sound, but it moves the patching and hardening burden onto you. A self-hosted Git server is not a passive file store; it holds source code, deploy keys, webhook secrets and the tokens that let CI push to production. An unauthenticated read of that server's configuration is a foothold into the whole delivery pipeline.

The compliance framing is familiar. Under SOC 2, DORA and the GDPR, an unpatched, remotely reachable flaw that can lead to code execution and secret exposure is a control gap with change-management and, potentially, breach-notification implications. "It was our internal Git server" is not a mitigating factor if that server was reachable and the secrets it held touched customer data or production systems. The pragmatic move is to fold self-hosted developer tooling into the same patch-SLA and secrets-hygiene discipline you already apply to production services.

What to do right now

This is a patch-then-assume-exposure incident. The order matters: upgrading stops new exploitation, but rotating the secrets a vulnerable build could have leaked is what makes any earlier read worthless.

1. Upgrade to Gitea 1.27.1 or later. This closes CVE-2026-59774 and the related RCE flaw CVE-2026-60004. Patch every instance, including staging and forgotten internal servers.
2. Check exposure first. Review access logs for requests to the /{owner}/{repo}/markup endpoint on affected builds, and note whether your Gitea was reachable from untrusted networks or the internet.
3. Rotate what the config reveals. Regenerate the INTERNAL_TOKEN in app.ini, then rotate database passwords, OAuth application secrets, JWT signing keys, SMTP credentials and any integration tokens stored in the config or filesystem.
4. Hunt for planted hooks. Because file read can chain to code execution via Git hooks, inspect repositories and the Gitea data directory for unexpected or recently modified hooks, and treat a confirmed exposure as a host compromise.
5. Get it off the open internet. Put Gitea behind a VPN or allowlist where feasible; developer tooling rarely needs to be publicly reachable, and reducing exposure shrinks the blast radius of the next flaw.
6. Wire in the advisory feed. Subscribe to Gitea release notes and add "critical self-hosted dev tooling" to an accelerated patch SLA so the next 9.8 is a same-day event.

The durable signal from CVE-2026-59774 is not about one library callback. It is that self-hosted developer infrastructure carries production-grade privilege and deserves production-grade operations: a known inventory, an advisory feed, an accelerated patch path, and secrets scoped tightly enough that reading one config file does not unlock the pipeline. Teams that treat their Git server like the crown-jewel system it is will patch this in an afternoon and move on.

Frequently asked questions

Sources

Gitea — Release of 1.27.1 (security advisory)
The Hacker News — Critical Gitea Flaw Let Unauthenticated Attackers Read Server Files via Org-Mode Markup
Cyber Security News — Critical Gitea Arbitrary File Read Vulnerability Enables RCE