CVE-2026-96404 in Gitea
Summary
by MITRE • 10/06/2026
When Gitea's web installer is 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 issued an authenticated session for that account without verifying its password. If the account is an administrator, the session grants full administrative access, including changing the account's password. Databases with a single user also did not require the reinstall confirmation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability in Gitea represents a critical authentication bypass within the web-based installation and reconfiguration workflow. This flaw specifically targets scenarios where the application is already initialized but the INSTALL_LOCK configuration flag has been manually reset to false, effectively allowing the system to accept new installation inputs despite existing data integrity requirements. The core technical failure lies in the logic governing user creation during this phase. When an administrator submits the install form with a username that matches an account already present in the database, the application fails to perform standard password verification or identity confirmation checks for that specific user. Instead of rejecting the request due to the duplicate name or requiring re-authentication of the existing credentials, the system proceeds to issue a new authenticated session token directly associated with the targeted account ID. This behavior indicates a fundamental flaw in how the installer handles state transitions and credential validation when interacting with pre-existing database records.
The operational impact of this vulnerability is severe, particularly for instances where administrative accounts are present. If an attacker can access the web installer interface and identifies or guesses an existing administrator username, they can submit that name through the installation form to instantly gain a valid session as that user. This bypasses all password-based authentication mechanisms, allowing immediate unauthorized access. For administrators, this grants full control over the Gitea instance, including the ability to modify system settings, manage repositories, and critically, change their own passwords or those of other users. The severity is compounded by the fact that databases containing only a single user did not require any additional confirmation steps for reinstallation, further lowering the barrier for exploitation. This means that even in minimal setups, an attacker with network access to the installer endpoint can hijack administrative privileges without needing prior credentials.
From a classification perspective, this vulnerability aligns closely with CWE-287, which describes Improper Authentication, as well as CWE-613, Insufficient Session Expiration, given that it results in an active session being established through improper validation of identity claims. In the context of the MITRE ATT&CK framework, this behavior facilitates Initial Access and Privilege Escalation techniques, specifically resembling Credential Stuffing or Account Manipulation where valid credentials are bypassed to gain unauthorized entry. The flaw exploits a trust assumption that the installation process is only relevant for fresh deployments, ignoring the security implications when applied to live systems with established user bases.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Administrators should ensure that the INSTALL_LOCK setting remains true in production environments and avoid resetting it unless absolutely necessary during controlled maintenance windows. If reconfiguration is required, manual database operations or supported upgrade paths should be used instead of relying on the web installer for existing instances. The vendor must enforce strict validation checks within the installation logic to detect duplicate usernames and either reject such submissions outright or require explicit confirmation that includes password verification for the affected account. Additionally, implementing multi-factor authentication adds a layer of defense against session hijacking attempts resulting from similar logical flaws. Regular audits of configuration states and access logs can help identify unauthorized installer interactions before they lead to full compromise.