Gophish EUVD-2026-67800

Exploitation requires possession of a valid Gophish API key associated with an account that has been locked or flagged for a mandatory password change - these are the precise conditions that the middleware fails to check. The API key must have been issued prior to the lockout event and not yet rotated or revoked. This limits the attacker pool to: (1) insiders or former users who retained their API key, (2) attackers who have already compromised credentials and are maintaining persistence after partial remediation. Exploitation does not require any special network position beyond connectivity to the Gophish API port (default TCP 3333). No user interaction is required once the key is in hand. Default Gophish deployments with all active, unlocked accounts are NOT vulnerable to this specific bypass; the flaw only manifests when an administrator takes lockout action and assumes it will terminate API access.

The CVSS 4.0 score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) accurately reflects the network reachability and high impact, but PR:L is the key limiting signal: exploitation unconditionally requires possession of a valid API key, meaning this is not a zero-effort, unauthenticated attack against default deployments. The realistic risk is concentrated in two scenarios: insider threats where a departing or suspended user retains API access, and post-compromise persistence where an attacker has already exfiltrated API credentials and the defender attempts remediation through account lockout rather than key rotation. In both cases, the CVSS vector is realistic. EPSS data was not provided; given no KEV listing and no public POC, widespread opportunistic exploitation is unlikely. However, the flaw is operationally significant in security-team environments where Gophish holds live phishing campaign data, harvested credentials from simulations, and employee targeting lists - all high-value data even in an authorized red-team context. The absence of a confirmed patch version is a concern; no specific fixed release is cited in the available references.

A security team locks a former red-team operator's Gophish account after their departure, expecting this to terminate their platform access. The operator, having previously exfiltrated their API key, continues to issue authenticated API requests that the middleware accepts without checking the locked-account state, allowing them to read harvested employee credentials and ongoing campaign configurations, or modify campaign targets. No public proof-of-concept has been identified, but the flaw is straightforward to exploit given knowledge of the middleware logic published in the reference commit.