Source: cve@mitre.org
In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists.
Gitea versions prior to 1.25.2 are vulnerable to a user enumeration attack. Attackers can leverage this vulnerability to determine the existence of valid usernames on a Gitea instance, which can then be used to facilitate credential stuffing or other attacks targeting user accounts. This information leakage allows for more targeted and effective attacks, significantly increasing the risk of unauthorized access.
Step 1: Target Identification: The attacker identifies a Gitea instance running a vulnerable version (prior to 1.25.2).
Step 2: API Interaction: The attacker sends a series of requests to the /api/v1/user endpoint, attempting to authenticate with various usernames.
Step 3: Response Analysis: The attacker analyzes the responses received from the API for each username. Differences in the response (e.g., error messages, response times, HTTP status codes) indicate whether the username exists.
Step 4: Username Enumeration: Based on the response analysis, the attacker builds a list of valid usernames on the Gitea instance.
Step 5: Credential Stuffing/Attack: The attacker uses the enumerated usernames to attempt credential stuffing attacks, brute-force attacks, or other attacks targeting the identified accounts.
The vulnerability stems from a difference in the HTTP responses returned by the /api/v1/user endpoint in Gitea. When a user attempts to authenticate with an invalid username, the API returns a different error message (or potentially different response times) depending on whether the username exists in the system. This difference allows an attacker to enumerate valid usernames by systematically querying the API with different usernames and observing the response. The root cause is a lack of consistent error handling and response formatting across different authentication failure scenarios. Specifically, the code doesn't properly obfuscate the existence of a user during authentication failures, leading to information leakage.
While no specific APTs are known to be actively exploiting this vulnerability, the nature of the vulnerability makes it attractive to a wide range of attackers, including those seeking initial access or performing reconnaissance. This vulnerability could be used as a precursor to more sophisticated attacks. CISA KEV status: Not Applicable (as of this report's generation).
Monitor HTTP request logs for unusual patterns of requests to the /api/v1/user endpoint, particularly those with a high frequency or a large number of unique usernames.
Analyze response times from the /api/v1/user endpoint. Significant variations in response times for different username attempts could indicate enumeration attempts.
Implement intrusion detection system (IDS) rules to flag requests to /api/v1/user with a high number of failed authentication attempts.
Monitor for suspicious user login activity after a potential enumeration attempt (e.g., multiple failed login attempts from the same IP address).
Upgrade to Gitea version 1.25.2 or later.
Implement consistent error handling and response formatting for authentication failures. Ensure that the API returns the same error message and response time regardless of whether the username exists.
Rate-limit requests to the /api/v1/user endpoint to mitigate brute-force and enumeration attacks.
Implement account lockout policies after a certain number of failed login attempts.
Consider using a Web Application Firewall (WAF) to filter malicious requests and protect against enumeration attempts.