Gitea CVE-2026-96404

Exploitation is possible ONLY when Gitea's web installer is network-reachable while the backing database already contains user accounts - the described trigger is INSTALL_LOCK being reset to false (or otherwise unset) on an already-installed instance. The attacker must also know or supply a username matching an existing account, and for full compromise that account must be an administrator. A further limiting factor: this is not exploitable against a normal, locked (INSTALL_LOCK=true) production deployment, which is the default post-install state; the window exists only during operator-induced reinstallation/misconfiguration. Additionally, databases with only a single user also bypassed the reinstall confirmation prompt, slightly widening the condition for small single-admin instances.

This is a genuine high-impact authentication bypass (CWE-287) in Gitea's web installer that hands an unauthenticated attacker a valid session for an existing administrator account without any password check, yielding full administrative control (CVSS 8.1, C:H/I:H/A:H). However, the signals diverge sharply on urgency: the vendor-supplied CVSS vector uses AC:H, which correctly reflects that exploitation is NOT possible against a normal, fully-installed instance - it requires the installer to be reachable against a populated database (e.g. INSTALL_LOCK manually reset to false), a non-default and transient state. The EPSS score is very low (0.16%, 4th percentile) and there is NO CISA KEV listing and NO public exploit code identified, so there is no evidence of active or at-scale exploitation. The net picture is a high-severity-but-conditional flaw: a real priority for the specific population of operators who have re-exposed their installer, but a low real-world mass-exploitation risk otherwise. Note one tension to verify: the vector is AV:N/PR:N (remote, unauthenticated), yet the vulnerable window depends entirely on an operator-side misconfiguration (installer exposed against an existing DB), so realistic exposure is far narrower than 'remote unauthenticated' alone implies.

An operator re-exposes the Gitea web installer against an existing database (for example by resetting INSTALL_LOCK to false) without restricting network access. An attacker who can reach the installer submits the install form using a known or guessed administrator username; Gitea issues an authenticated session for that account without verifying the password, and the attacker then changes the admin password to lock in full control. No public exploit code is identified at time of analysis, and the high attack complexity reflects the required non-default installer-exposed state.