CVE-2026-82269 in Gophish
Summary
by MITRE • 08/28/2026
Gophish through 0.12.1 fails to enforce account lockout and password change requirements in the API authentication middleware. Attackers with valid API keys can bypass these security controls and retain full API access even when their account is locked or password change is required.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in Gophish versions up to 0.12.1 represents a critical failure in identity and access management controls within the application's API authentication middleware. This flaw specifically impacts the enforcement of two fundamental security policies: account lockout mechanisms and mandatory password change requirements. In standard secure configurations, when an administrator or user account is locked due to excessive failed login attempts, or when a policy dictates that a password must be changed upon first use or after expiration, all subsequent authentication requests should be rejected regardless of the credentials provided. However, in this vulnerable implementation, the API middleware does not properly check these status flags before granting access based on valid API keys. This creates a significant gap between the intended security posture and the actual operational behavior of the system.
From a technical perspective, the root cause lies in the authentication logic flow within the Gophish backend. When an API request is received, the middleware validates the provided API key against stored credentials. While it correctly verifies that the key itself exists and matches the user record, it fails to query or respect additional attributes associated with that account, such as the locked status flag or the password change required boolean. Consequently, even if a security administrator has explicitly locked an account due to suspected compromise or policy violation, the API endpoint continues to accept requests authenticated by any valid key belonging to that compromised identity. Similarly, users who are forced to reset their passwords can continue using previously issued API keys without being prompted for authentication renewal, effectively bypassing credential rotation policies designed to mitigate risk after potential exposure.
The operational impact of this vulnerability is severe, particularly in environments where Gophish is used for security awareness training or penetration testing campaigns that involve sensitive data handling. An attacker who has obtained a valid API key from an account that was subsequently locked due to brute-force activity can maintain persistent access to the application's functionalities. This includes the ability to create and manage phishing simulation campaigns, view campaign results, export user interaction data, and potentially exfiltrate contact lists or other stored information. The persistence of this access means that standard incident response procedures relying on account lockout as a containment measure are rendered ineffective against API-based attacks. Furthermore, the inability to force credential rotation via password change requirements allows attackers to operate with stale credentials indefinitely, increasing the window of opportunity for malicious activity without detection through traditional authentication failure logs.
This vulnerability aligns closely with CWE-287, which describes Improper Authentication, and more specifically CWE-640, Weak Password Recovery Mechanisms for Administrators, as it undermines the effectiveness of password management policies. In terms of adversarial tactics, this behavior facilitates persistence within an environment by allowing continued access despite administrative intervention attempts to revoke privileges. It also supports lateral movement if the compromised API key is used to pivot into other integrated systems or data stores accessible through the Gophish interface. The lack of enforcement on account lockout mirrors patterns seen in CWE-307, Improper Restriction of Excessive Authentication Attempts, although here the restriction exists but is bypassed rather than absent entirely.
To mitigate this risk, organizations running vulnerable versions of Gophish should immediately upgrade to version 0.12.2 or later where these authentication checks have been corrected in the middleware layer. Until an update can be applied, administrators should rotate all API keys associated with accounts that are locked or require password changes as a precautionary measure. Additionally, implementing network-level controls such as IP whitelisting for Gophish administrative interfaces and API endpoints can reduce the attack surface by restricting access to trusted sources only. Monitoring logs for successful API authentications following account lock events is also recommended to detect any potential exploitation of this flaw in real-time. Regular audits of authentication middleware logic against industry standards like OWASP Authentication Cheat Sheet are essential to ensure that identity management controls function as intended across all entry points, including programmatic interfaces often overlooked during traditional web application testing.