CVE-2026-96404: Gitea Web Installer Auth Bypass Vulnerability

CVE-2026-96404 Overview

CVE-2026-96404 is an authentication bypass vulnerability in Gitea's web installer. When the installer remains reachable against a database that already contains users, such as after INSTALL_LOCK has been reset to false, submitting the install form with an administrator username matching an existing account issues an authenticated session for that account without verifying its password. If the account is an administrator, the session grants full administrative access, including the ability to change the account's password. Databases with a single user also did not require the reinstall confirmation. The flaw is tracked under [CWE-287: Improper Authentication] and was addressed in Gitea 28.0.0.

Critical Impact
Attackers with network access to an exposed installer endpoint can take over existing administrator accounts without credentials, gaining full administrative control over the Gitea instance.

Affected Products

Gitea self-hosted Git service (versions prior to 28.0.0)
Deployments where INSTALL_LOCK has been reset to false
Instances with the web installer reachable over the network

Discovery Timeline

2026-10-06 - CVE-2026-96404 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-96404

Vulnerability Analysis

The vulnerability resides in Gitea's web installer handler. The installer is designed to run once during initial setup and is normally disabled by the INSTALL_LOCK configuration flag. When this flag is reset to false, either by administrator action or through configuration drift, the installer becomes reachable again against a populated database.

Submitting the install form requires specifying an administrator account. The handler accepted any username supplied in the form and issued an authenticated session bound to that account. The password field was not validated against the stored credential for an existing account with the same username. Where the database contained only a single user, the installer did not prompt for the reinstall confirmation step either, further reducing friction for exploitation.

Root Cause

The root cause is missing authentication verification in the installer's administrator-provisioning path. The handler conflated two distinct flows: creating a new administrator account on a fresh database, and reaching an authenticated state during a reinstall. Instead of rejecting usernames that already existed, or requiring password verification when the account was present, the code issued a session for the matching account. This maps directly to CWE-287 (Improper Authentication).

Attack Vector

Exploitation requires network access to a Gitea instance where the installer endpoint is reachable and INSTALL_LOCK is false. The attacker needs to know or guess an existing administrator username, such as the common defaults admin or gitea. The attacker submits the install form with that username and arbitrary database and admin password values. Gitea returns an authenticated session for the matching administrator account. From there, the attacker can reset the account password, create repositories, exfiltrate source code, inject malicious commits, or pivot into connected CI/CD systems.

No verified public exploit code was referenced in the advisory. See the Gitea Security Advisory GHSA-9h7g-h754-c8x2 and Gitea Pull Request #39400 for the upstream fix.

Detection Methods for CVE-2026-96404

Indicators of Compromise

HTTP POST requests to /install on Gitea instances where setup was previously completed
New authenticated sessions for administrator accounts shortly after installer traffic appears in access logs
Unexpected administrator password changes or email address updates on existing admin accounts
Appearance of new SSH keys, access tokens, or OAuth applications tied to administrator accounts

Detection Strategies

Alert on any request to the /install endpoint on production Gitea deployments; this path should not be reachable after initial setup
Monitor the Gitea configuration file (app.ini) for changes to the INSTALL_LOCK value
Correlate installer page access with subsequent administrator-privileged actions originating from the same source IP

Monitoring Recommendations

Centralize Gitea web server access logs and audit logs in a SIEM for cross-source correlation
Track administrator account activity, including password resets, token creation, and permission changes
Monitor outbound Git clone and repository export activity from administrator sessions for signs of mass data exfiltration

How to Mitigate CVE-2026-96404

Immediate Actions Required

Upgrade all Gitea instances to version 28.0.0 or later
Verify that INSTALL_LOCK = true is set in app.ini for every production deployment
Restrict network access to the Gitea web interface, particularly the /install path, using a reverse proxy or firewall rule
Audit administrator accounts for unexpected password changes, new tokens, or new SSH keys since the installer was last reachable

Patch Information

Gitea addressed this vulnerability in version 28.0.0. Review the Gitea Release Announcement 28.0.0 and Gitea Release Tag v28.0.0 for upgrade guidance. The upstream code change is tracked in Gitea Pull Request #39400.

Workarounds

Ensure INSTALL_LOCK = true remains set and is enforced through configuration management
Block the /install route at the reverse proxy or ingress layer for post-deployment instances
Place Gitea behind an authenticated VPN or zero-trust access gateway so the installer cannot be reached directly from the internet
Rotate administrator credentials, personal access tokens, and SSH keys if there is any indication the installer was reachable while the database contained users

bash

# Example app.ini hardening
[security]
INSTALL_LOCK = true

# Example nginx rule to block the installer path
location = /install {
    return 404;
}