Gitea released v1.27.3 on August 29, 2026 at 17:42 UTC, tagged “Latest” on the project’s GitHub repository from a signed, verified commit merged by maintainer lunny through the GiteaBot account. That alone wouldn’t be much of a story. What makes this release worth a look is the SECURITY section of its changelog, which runs to 18 separate fixes, none of them carrying a dedicated CVE identifier.
That’s a different shape of release than the one we covered on August 10, when 1.27.1 patched two named, numbered vulnerabilities: CVE-2026-59774, an unauthenticated file-read bug, and CVE-2026-60004, a remote code execution flaw via diffpatch handling that CISA later confirmed was being exploited in the wild. This time there’s no single headline flaw. Instead, Gitea’s maintainers went through the access-control layer with a fine comb and closed 18 separate gaps in one pass.
What the 18 fixes actually close
Read through the list and a pattern shows up fast: almost every fix narrows who can reach what. A batch of five separate pull requests, merged together as one packages fix, restricts package access and tightens API token scope. Attachments now enforce the owning repository’s path instead of trusting whatever path a request supplies. Rendering markup inside issues now enforces same-repository access. Actions verifies artifact signatures before using raw artifacts, rather than after.
- Limited users are now hidden from restricted accounts in the API, closing an information gap between account tiers.
- .gitignore template selection is now restricted to a defined set instead of accepting arbitrary input.
- GitLab version probing during migrations is disabled, removing a possible abuse path against third-party servers.
- Swift package manifests, Maven checksum uploads, and Alpine package metadata entries are all now size- or format-limited.
- OneDev version responses during migrations are similarly restricted.
- Actions now enforces trust boundaries for pull requests coming from forks, so a forked PR can’t run with more trust than it should have.
- Git hook permissions are restricted.
- Repository creation through the API now requires proper token authorization.
- The compare-heads API endpoint is scoped to public repositories only.
- Repositories owned by hidden accounts are no longer exposed.
- A fix closes a path that let someone enumerate every public repository through issue search, something that was never supposed to be a full repository listing.
- Several private endpoints were refactored as part of this cleanup.
Individually, most of these read like small permission tweaks. Taken together, they cover packages, attachments, Actions, migrations, repository visibility, and the API layer almost end to end. That’s a lot of ground for one release, and it reads less like a fix for a single reported bug and more like someone spent real time auditing how Gitea decides who gets to see and touch what.
Why none of this has a CVE number
It’s worth being straightforward about what “no CVE” does and doesn’t tell you. A CVE identifier usually shows up when a flaw is reported externally, through a bug bounty, a researcher’s disclosure, or a security audit with formal reporting. The absence of CVE numbers across all 18 fixes here points the other way: an internal review, not an external disclosure. Nothing in the release notes suggests any of these were caught being exploited.
That’s a reasonable thing to feel okay about. But the areas touched, package API scope, attachment paths, compare-heads responses, repository enumeration, are exactly the kind of access-control gaps that tend to matter most on multi-user instances or anywhere private repositories sit next to public ones. A quiet internal hardening pass is still worth applying promptly if your Gitea instance has more than one person with an account.
Enhancements and the rest of the bugfixes
Outside of security, 1.27.3 adds one enhancement: permalinks on pull request reviews, so you can now link directly to a specific review instead of scrolling to find it. The BUGFIXES section is long and mostly routine, covering Actions behavior, the Swift Registry package handler, migration edge cases, OpenPGP signature verification, and how merged pull request state gets tracked. None of it changes how you’d operate the server day to day.
The third Gitea security story in three weeks
If you’re keeping count, this is the third time Gitea security has landed in this space since early August. First came the 1.27.1 patch for CVE-2026-59774 and CVE-2026-60004, then the news, published the same day as this release, that CISA had confirmed active exploitation of that RCE flaw in the wild. Neither of those earlier posts covers what’s new in 1.27.3, so if you haven’t read them, they’re worth a look for background on what was already fixed in July and why the RCE bug in particular deserved urgency.
Three security-relevant releases in three weeks isn’t necessarily a sign anything is more broken than usual. It might just mean the maintainers are paying closer attention right now, which, after a confirmed active exploitation event, is exactly what you’d want to see.
Should you update
Yes, and there’s no real reason to wait. None of these 18 fixes are flagged as under active exploitation, so this isn’t an emergency patch-tonight situation the way the RCE story was. But the breadth of what’s covered, especially the package API, attachment path handling, and repository enumeration fixes, makes this worth rolling out on your normal update schedule rather than pushing it to the bottom of the list. If you’re running Gitea for a team, or with any private repositories alongside public ones, that’s reason enough to move soon. For setup details and what Gitea actually needs to run well self-hosted, see our Gitea application profile.
Source: the Gitea v1.27.3 release notes on GitHub.