A file-read bug that needed nothing from the attacker
Gitea, the self-hosted Git service used widely by enterprises that want source control without ceding it entirely to a third-party cloud provider, disclosed CVE-2026-59774 on August 5. The flaw carries a CVSS score of 9.8, just short of the maximum possible rating, and for good reason: it required no authentication whatsoever, no repository access beyond a public repo with ordinary code viewing enabled, and no interaction from a victim at any point in the chain. An attacker simply needed network reach to the server's markup rendering endpoint to begin exploitation.
The vulnerable code lived inside Gitea's Org-mode markup renderer, reachable through the POST /{owner}/{repo}/markup endpoint that the platform exposes for rendering documentation content. Org-mode is a lightweight markup format popular in the Emacs community, and Gitea renders it through the third-party go-org library rather than a component built in-house. That library supports a `#+INCLUDE` directive intended for pulling in external content during rendering, and Gitea never overrode the library's default file-reading behavior to keep those includes safely scoped to rendered documentation rather than the raw filesystem.
What an attacker could actually pull off the server
Because Gitea failed to override go-org's default `ReadFile` callback before shipping, an `#+INCLUDE` directive pointing at an absolute file path resolved directly to the real filesystem rather than to safely rendered markup content. Anything the Gitea service account could read, an attacker could read too: configuration files, internal secrets stored on disk, SSH keys, or other sensitive material, depending entirely on how the instance had been deployed and hardened by its operators. Some Gitea installations run the service account with fairly broad filesystem permissions by default, which would widen the practical blast radius considerably beyond what most administrators would assume.
The attack path required only a public repository with code viewing enabled and a piece of crafted Org-mode content submitted to the markup endpoint. That is a remarkably low bar to clear. Most organizations running Gitea for open-source projects or public-facing documentation sites meet that condition by design, since keeping repositories public and code browsable is often the entire point of hosting them that way. The flaw effectively turned a feature meant to render lightweight documentation into a generic, reusable file-read primitive against the host machine running it.
Found by a machine, confirmed by humans
What distinguishes this disclosure from a routine bug report is who found it first. XBOW, an autonomous offensive security system that runs automated penetration testing without a human operator driving each individual step, identified the vulnerability on its own. Researcher Shai Rod, known in the community as NightRang3r, independently reported the same flaw around the same time, with fellow researcher Guido Leo assisting in triage and verification. The convergence of an AI system and independent human researchers landing on the same critical bug in the same narrow window is itself worth noting as autonomous security tooling matures from a novelty into a genuine part of the vulnerability discovery pipeline.
The project's own description of the impact was unambiguous and left little room for downplaying the severity: "An unauthenticated attacker can read any file the service account can access on Gitea...A public repository and crafted Org-mode markup are enough." The fix itself landed in pull request #38642, with a corresponding backport in #38645, overriding the `ReadFile` callback so that Org-mode include paths now resolve to rendered content instead of granting raw filesystem access to whoever crafts the request.
Five releases of exposure before detection
The vulnerable code affected Gitea versions 1.22.1 through 1.27.0, meaning the flaw persisted silently across five consecutive minor release cycles before anyone caught it. That gap matters enormously for any enterprise running a self-hosted Git platform: a feature shipped once, deemed stable after initial testing, and left largely unexamined afterward can carry a critical flaw for a year or more simply because markup renderers rarely receive the same ongoing security scrutiny that authentication or authorization code gets as a matter of routine practice.
Gitea is not a niche tool used only by hobbyists. Enterprises choose self-hosted Git specifically to keep source code and CI/CD pipelines off third-party infrastructure entirely, often for compliance reasons or to protect valuable intellectual property from external exposure. A file-read primitive against that server undermines the exact security rationale that led an organization to self-host in the first place, since it exposes the same class of internal secrets a cloud-hosted alternative would also need to protect, but now sitting behind a control the organization believed it fully owned and governed.
What self-hosted Git operators should do now
Organizations running any version between 1.22.1 and 1.27.0 need to upgrade to 1.27.1 without delay. There is no reasonable workaround short of disabling public repository access or turning off the markup rendering feature entirely, and both of those options defeat much of the purpose of running a collaborative Git platform in the first place. As of the disclosure date, researchers have confirmed no active exploitation in the wild, and the CVE has not yet appeared in CISA's Known Exploited Vulnerabilities catalog. Treating the patch as urgent regardless is the safer assumption, since a critical, no-authentication file-read bug rarely stays quiet for long once technical details start circulating publicly.
The broader lesson for platform security teams is to audit every markup or templating engine running inside their self-hosted tools for this exact class of issue: does the renderer restrict file-system access by default, or does it inherit whatever permissions the underlying third-party library allows unless someone explicitly locks it down first. Gitea is unlikely to be the only self-hosted platform carrying this gap somewhere in its dependency tree. It simply happens to be the one an autonomous pentesting system found first, ahead of every human researcher who had looked at the same code before it.
