,

Gitea Security Update 1.27.1 Patches Two Critical Vulnerabilities

Padlock resting on a computer circuit board, illustrating self-hosted server security

If you run a self-hosted Gitea instance and haven’t touched it since July, go check your version number before you read the rest of this. Gitea 1.27.1 shipped on 27 July 2026 with fixes for two security bugs, but the formal advisory for the worse of the two only went public on 2 August. That week-long gap is a large part of why so many instances are still running vulnerable builds today.

The release is the first patch in the 1.27 series. It bundles 48 merged pull requests alongside the security work, and the maintainers were unusually direct about it: upgrade as soon as possible. Here is what actually broke.

The unauthenticated file read: CVE-2026-59774

CVE-2026-59774 has a CVSS score of 9.8, rated Critical. It affects every release from 1.22.1 through 1.27.0 and is fixed in 1.27.1. GitHub published the formal advisory as GHSA-6v53-hr58-556r on 2 August 2026.

The root cause is small and unglamorous. Gitea initialised the go-org library without overriding its default ReadFile callback. Org-mode supports an #+INCLUDE directive that pulls in the contents of another file, and with the default callback left in place, that directive would read whatever the Gitea service account could read.

No account is needed to trigger it. An attacker hits the markup rendering endpoint (/markup) on any public repository, submits Org-mode content containing an #+INCLUDE that points at an absolute path, and gets the file contents back. That last detail is the one worth sitting with: a single public repository on your instance is enough of an attack surface. There is no registration step, no token, no login.

It escalates past file reading, too. Read app.ini, extract the INTERNAL_TOKEN from it, use that token to inject a Git hook through the internal logger, then fire the hook with an anonymous clone. A file read becomes command execution on the host.

Pull requests #38642 and #38645 carry the fix. XBOW Security reported the bug, and NightRang3r found it independently; the patch came from @wxiaoguang and @TheFox0x7.

Remote code execution via the diffpatch API: CVE-2026-60004

The second flaw, CVE-2026-60004, allows remote code execution by installing a Git hook through the diffpatch API. It was fixed in pull requests #38637 and #38638, reported by NightRang3r and patched by @wxiaoguang.

This one requires write access to a repository, which puts it in a different bracket from CVE-2026-59774. If your instance is private and every account belongs to someone you’d trust with shell access anyway, the practical risk is lower. If registration is open, or you host repositories for contributors you don’t personally vouch for, the distinction stops being reassuring.

What the evidence says about exploitation

Gitea’s advisory states that no exploitation has been observed in the wild. As of 5 August 2026, CVE-2026-59774 was not listed in the CISA Known Exploited Vulnerabilities catalogue either. A few security news sites ran headlines describing active exploitation, and that claim is not supported by the primary source. Until Gitea or CISA says otherwise, treat it as unconfirmed.

None of which lowers the priority by much. A 9.8 with a trivial attack path, a public advisory, and a published patch is worth handling on its own merits, regardless of whether anyone has pulled the trigger yet.

The rest of what changed in 1.27.1

The other 46-odd pull requests are ordinary maintenance, but a few are worth knowing about:

  • Mandatory 2FA policy is now enforced on the OAuth2 authorize and grant endpoints (#38606).
  • HTTP clone with redirects works again. The restriction introduced in 1.27.0 was reverted (#38545).
  • Gitea keeps serving a valid ACME certificate when renewal fails at startup, rather than refusing to boot (#38583).
  • A sizeable batch of Gitea Actions fixes: jobs stuck in cancelling after a restart, multi-line run: blocks, and pull_request_target handling.

The ACME change is the sort of fix you only appreciate once it has saved you. Full details are in the official 1.27.1 release announcement.

What to do with your own instance

  1. Check the version your instance actually reports, not the one in your notes. Anything from 1.22.1 to 1.27.0 is affected by CVE-2026-59774.
  2. Upgrade to 1.27.1. If you deploy via Docker, pull the updated tag rather than relying on a cached image.
  3. If you can’t upgrade immediately, put the instance behind a VPN or a reverse-proxy auth layer so the /markup endpoint isn’t reachable anonymously.
  4. If your instance was publicly reachable while running an affected version, rotate INTERNAL_TOKEN and audit your repositories for Git hooks you didn’t install.

This is the second serious Gitea security story in as many months. In July we covered CVE-2026-20896, the authentication bypass in the official Docker image, which is a separate bug with a separate fix. Two unrelated critical findings in a short window says more about how much scrutiny the project is getting right now than about the code being unusually bad, though it does make a case for keeping upgrades on a schedule instead of doing them when something breaks. If you’re weighing alternatives, Forgejo is the community fork and worth a look, but it shares enough ancestry that it isn’t a way to opt out of this class of problem.

Related guides