```html ```
top of page

On 31 July We Said Gitea's Login Wall Wasn't a Wall. On 25 August CISA Listed It as Actively Exploited. The Bug Needed an Account — and Gitea Hands Those Out at the Door.

  • Writer: Patrick Duggan
    Patrick Duggan
  • 1 hour ago
  • 5 min read

On 31 July we published a post with an argument in the title: "Gitea Shipped a 9.8 That Needs an Account. Gitea Also Ships With Anyone Being Able to Make One."


On 25 August, CISA added [CVE-2026-60004](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-60004) to the Known Exploited Vulnerabilities catalogue. Reported attacks are dropping a miner-like payload.


Twenty-five days. And more to the point: the thing we argued was the weak part is the thing that broke.



What the bug is


Git hook injection in Gitea, the leading self-hosted alternative to GitHub. CVSS 9.8. An attacker with repository write access sends a malicious patch to the diffpatch API endpoint, which plants an executable Git hook, which then runs shell commands as the Gitea service account — the identity that owns every repository on that host.


Everything from 1.17 through 1.27.0 is affected. The fix merged and was backported on 26 July, 1.27.1 shipped on 27 July, and the advisory followed on the 28th. Found and reported by Shai Rod, who publishes as NightRang3r, and the credit for finding it is entirely his.


If you run Gitea and you are not on 1.27.1 or later, stop reading and go do that.



The argument we made, and why it was falsifiable


The CVSS vector says this bug requires authentication and repository write permission.


That sounds like a real barrier. It is the sentence that moves a finding from internet-facing emergency to insider risk, and it is the sentence that decides whether a bug gets patched this week or next quarter.


Now put it next to the product's default configuration. Gitea ships with open registration. Anyone who can reach the box can create an account. Anyone with an account can create a repository. Anyone who creates a repository has write access to it — which is the entire precondition.


So the attacker's starting position is not "trusted contributor with commit rights on your codebase." It is "person who found a signup form."


That was not a prediction dressed up as analysis. It was a checkable claim about the distance between a severity vector and a deployment default, and the exploitation record has now tested it.





The receipts, with the comparator beside them


We do not ship a lead claim without the external wall printed next to our own timestamp. We published a false one in July and corrected it in public, and that correction is still on this blog.



Date

Source

Gitea backports the fix, ships 1.27.1, publishes the advisory

26–28 July 2026

vendor — they were first, we claim nothing here

Our exploit-harvester collects the first public PoC repository

29 July 2026, 12:00 UTC

exploit-harvesterfirst-party

We publish the analysis

31 July 2026

first-party

Four further independent PoC repositories collected

30 July – 4 August 2026

first-party

CISA adds CVE-2026-60004 to KEV, miner-like payload reported

25 August 2026

comparator


25 days from our published analysis to the KEV listing. 27 days from our first harvested proof-of-concept.


Both receipts are first-party. The PoC timestamps come from our own GitHub-harvesting cron, on a schedule, writing times we did not pick. The analysis is our own writing with a publication date anyone can check.


What this is not: a discovery. Shai Rod found the bug, Gitea fixed it, and the advisory existed before we opened a text editor. Our leads live at proof-of-concept weaponisation, at own-index pre-staging, and at cluster-naming — almost never at disclosure, because nobody reliably beats the field there. We say that every time and we are saying it again.


What this is: a call on severity that the world subsequently confirmed. Five independent people published working exploit code inside a week. The catalogue took another three weeks to agree it was being used.



The pattern worth taking away


We run a detector for weaponisation latency — the distance between a CVE appearing, the first public exploit landing, and CISA cataloguing it. Of 86 KEV entries we examined, 15 were already armed with public exploit code before CISA listed them. This is another.


But the more useful lesson here is not about timing. It is about what a severity vector cannot see.


A CVSS vector describes the attacker's starting position in the abstract. It has no idea what your deployment defaults are. On software whose out-of-the-box posture is anyone may sign up, "authenticated" and "unauthenticated" are the same sentence with extra steps — and a triage queue that sorts purely on the vector will file this one below bugs that matter considerably less.


That is not a criticism of CVSS, which is doing exactly what it was designed to do. It is a criticism of using it alone. The question that actually sizes a self-hosted bug is: given how this product ships, who satisfies the precondition? For Gitea on 31 July the honest answer was "anyone with a browser," and it stayed the honest answer right up until CISA wrote it down.


Go and check your Gitea instance's registration setting tonight, separately from patching. If DISABLE_REGISTRATION is not set and you are not deliberately running a public forge, you have been treating a front door as a wall — and that is true of the next authenticated-only Gitea bug as well as this one.



Sources


CVE-2026-60004, CVSS 9.8, Git hook injection via the diffpatch API endpoint in Gitea, affecting 1.17 through 1.27.0, fixed in 1.27.1 (27 July 2026), advisory published 28 July 2026, reported by Shai Rod / NightRang3r. Added to the CISA Known Exploited Vulnerabilities catalogue 25 August 2026, with reported attacks deploying a miner-like dropper.


Our proof-of-concept collection timestamps are from our own exploit-harvester in the iocs index under source=exploit-harvester (five repositories, 29 July – 4 August 2026). Our analysis post is dated 31 July 2026 and is on this blog.


Capped at 95 percent as always: we have no first-party telemetry of a compromise against a specific Gitea instance, the miner-payload detail is from the reporting rather than from our own observation, and our repository count is what one harvester pass saw — there may well have been more exploits published than we collected.




If you run a self-hosted forge, the ten-minute job tonight is not the patch — you will do that anyway. It is opening your config and reading what your registration setting actually says, then deciding whether that is what you meant. Tell me what you find. Rate this post below.




Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.



Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=on-31-july-we-said-gitea-s-login-wall-wasn-t-a-wall-on-25-august-cisa-listed-it-as-actively-exploit



Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page