One Gitea Signup Now Buys Shell Access. Patch, Close Registration, Audit Hooks Before August 28.

The version bump is the easy part, and on its own it does not finish the job. Gitea 1.27.1 closes the vulnerable diffpatch endpoint ^[4], but that endpoint's whole trick was writing an executable hook into a repository's hooks directory and letting ordinary Git activity trigger it ^[3]. A hook planted before you patched is still there afterward, which is why the remediation carries a step that upgrades usually skip: audit every repository for hooks written before the patch ^[4]. Gitea published its own advisory a month before the KEV listing, and the flaw was reported by security researcher Shai rod, who works as NightRang3r ^[12].

The account an attacker needs costs nothing. The vulnerable call requires an authenticated user with write permission to a repository, but Gitea allows self-registration by default, so an unauthenticated visitor can register, create a repository, and hold write permission over content they fully control ^[6]. A developer writing as Causelof, who published an incident analysis on Habr last week after their own instance was hit, blamed four defaults: registration open, no email confirmation required, OpenID signup enabled, and pages reachable before any login ^[7]. All four are ordinary on instances stood up for internal convenience.

Perimeter habits do not help. In that incident SSH was never reachable from the internet at all; the attack arrived over HTTPS, on the web API the operator had deliberately published ^[8]. Blocking port 22 does nothing against this.

The owner found out the way cryptojacking victims usually do. HOSTKEY emailed to say the server had run above 70 percent CPU for an extended period against its terms of service, then throttled it, and working back from that notice led to the compromise ^[9]. The dropper cleared LD_PRELOAD and LD_LIBRARY_PATH, killed competing high-CPU processes, fetched an architecture-specific payload, ran it, and deleted the file ^[10]. The next stage was never analyzed ^[11].

The affected range starts at 1.17, roughly eight years of releases ^[5]. The real exposure is the long-running internal instance nobody has logged into since it was stood up, still answering on its published port and still running the shipped defaults ^[5].