CVE-2025-64175: 
Gogs vulnerability analysis and mitigation

CVE-2025-64175 is a 2FA authentication bypass vulnerability in Gogs, an open-source self-hosted Git service, that allows an attacker with knowledge of a victim's username and password to bypass two-factor authentication using any unused recovery code — including one from their own account. The flaw was discovered by OpenAI Security Research in August 2025 using GPT-5, reproduced via PoC, and reported to Gogs on August 6, 2025; it was publicly disclosed on February 6, 2026. All Gogs versions with 2FA support are affected (confirmed range: >= 0.11.19, <= 0.13.3), with the vulnerability introduced in commit a617d52 on April 5, 2017. The CVSS v3.1 base score is 8.8 (High) and the CVSS v4.0 base score is 7.7 (High) (Github Advisory, Gogs Advisory).

The root cause is improper authentication (CWE-287) in the UseRecoveryCode function within internal/database/two_factor.go. Despite accepting a userID parameter, the function ignores it entirely and performs a global database lookup for any unused recovery code matching only on the code value and is_used = false status — with no constraint binding the code to the authenticating user. The vulnerable query is: x.Where("code = ?", code).And("is_used = ?", false).Get(recoveryCode). The call chain is: web login handler → UseRecoveryCode(userID, code) → DB query without userID constraint. This means any attacker who has registered their own Gogs account and enabled 2FA can use one of their own valid, unused recovery codes to complete authentication as any other user whose primary credentials (username/password) they possess (Github Advisory, Gogs Advisory).

Successful exploitation results in full account takeover of any targeted Gogs user whose credentials are known, completely undermining the security guarantee of 2FA across all affected deployments. An attacker gains the same access as the victim — including access to private repositories, SSH keys, API tokens, and administrative functions if the victim holds elevated privileges. This creates significant risk of data exfiltration, unauthorized code modification, and downstream supply chain compromise, particularly in enterprise self-hosted environments or public Gogs instances where developer and maintainer accounts are targeted (Github Advisory, Gogs Advisory).

A proof-of-concept was developed and confirmed by OpenAI Security Research against the latest Dockerhub-hosted Gogs image, and the PoC steps are publicly documented in the security advisory. However, as of the disclosure date, there is no evidence of in-the-wild exploitation or weaponization in exploit kits. The EPSS score is approximately 0.013% (0.000130), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to already possess the victim's username and password, as well as their own valid Gogs account with 2FA enabled and at least one unused recovery code (Github Advisory, Gogs Advisory).

1. Reconnaissance: Identify a target Gogs instance (version <= 0.13.3) with 2FA enabled, using Shodan, Censys, or direct enumeration of known self-hosted Gogs deployments.
2. Obtain victim credentials: Acquire the victim's Gogs username and password through phishing, credential stuffing, or other means — this is a prerequisite for exploitation.
3. Create attacker account: Register an account on the same Gogs instance (or any instance sharing the same database, if applicable) and enable 2FA.
4. Generate and save recovery codes: During 2FA setup on the attacker's account, save at least one unused recovery code (e.g., abcde-fghij).
5. Initiate victim login: Navigate to the Gogs login page and authenticate as the victim using their username and password. The application will prompt for a 2FA code or recovery code.
6. Submit attacker's recovery code: When prompted for a recovery code, enter the attacker's own unused recovery code (e.g., abcde-fghij) instead of the victim's.
7. Achieve account takeover: The UseRecoveryCode function performs a global lookup, finds the attacker's code as valid and unused, marks it as used, and grants full authenticated access as the victim (Github Advisory, Gogs Advisory).

• Logs: Gogs authentication logs showing a successful login for a user account via recovery code, particularly where the recovery code used does not match any code generated for that specific user account; multiple recovery code authentication attempts across different user accounts from the same source IP.
• Database: The two_factor_recovery_codes table showing a recovery code marked as is_used = true that belongs to a different user than the one who authenticated with it; cross-referencing the user_id on the used code against the authenticated session's user ID will reveal a mismatch.
• Network: Unusual login activity from unfamiliar IP addresses for accounts with 2FA enabled, especially if followed by repository cloning, SSH key additions, or API token generation shortly after authentication.
• Application Behavior: A user's 2FA recovery code being consumed/marked as used without the user initiating a recovery login, which may surface as the user being unable to use their own recovery code later (Github Advisory).

Gogs has released patched versions 0.13.4 and 0.14.0+dev that fix this vulnerability by properly scoping recovery code lookups to the authenticating user. All administrators running Gogs <= 0.13.3 should upgrade immediately. For environments unable to patch immediately, the recommended interim workaround is to disable 2FA functionality in Gogs, as the current implementation provides no security benefit and may create a false sense of security. Additionally, administrators should review authentication logs and audit trails for suspicious recovery code usage on 2FA-enabled accounts (Github Advisory, Gogs Advisory).

The vulnerability attracted notable attention due to its discovery by OpenAI Security Research using GPT-5, positioning it as an early example of AI-assisted vulnerability research leading to a disclosed CVE. Security media outlets including SecurityOnline, CyberPress, and The Hacker News covered the broader context of OpenAI's Codex Security tool scanning 1.2 million commits and finding over 10,000 high-severity issues, with this CVE cited as a representative finding. The BeyondMachines community and Infosec.exchange discussed the vulnerability in the context of critical Gogs flaws enabling 2FA bypass alongside other RCE-class issues. Red Hat also tracked the vulnerability, indicating relevance to enterprise Linux environments running Gogs (SecurityOnline, The Hacker News).