CVE-2026-107271 in Gophish
Summary
by MITRE • 10/07/2026
Gophish through 0.12.1 contains a rate limit bypass vulnerability that allows unauthenticated attackers to evade /login throttling by spoofing X-Forwarded-For or X-Real-IP headers. Attackers can send a different forwarded address per request so the limiter keyed on rewritten RemoteAddr never triggers, enabling unlimited password guessing and credential stuffing.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in Gophish versions up to 0.12.1 represents a critical failure in access control mechanisms, specifically within the authentication subsystem's rate limiting implementation. This flaw allows unauthenticated actors to bypass security controls designed to prevent brute-force attacks and credential stuffing campaigns. The core of the issue lies in how the application determines the source IP address for throttling purposes rather than relying on the actual network connection details provided by the underlying web server or reverse proxy infrastructure.
Technically, the vulnerability stems from an improper validation of client identity headers. Gophish relies on the X-Forwarded-For and X-Real-IP HTTP headers to determine the remote address for its rate limiting logic. These headers are commonly used in environments behind load balancers or proxies where the direct connection originates from a trusted internal IP rather than the end user's public IP. However, because these headers originate directly from the client-side request stream, they can be trivially manipulated by an attacker. By sending requests with spoofed values for X-Forwarded-For and X-Real-IP that change with every single attempt, the rate limiter perceives each login attempt as coming from a distinct IP address. Consequently, the throttling mechanism keyed on the rewritten RemoteAddr never triggers its thresholds, effectively neutralizing the protection against rapid authentication attempts.
The operational impact of this vulnerability is severe for organizations deploying Gophish without additional protective layers. Since the application allows unlimited password guessing and credential stuffing attacks to proceed at high velocity, attackers can rapidly compromise user accounts if weak passwords are in use. This undermines the fundamental security posture of any phishing simulation platform that relies on account-based access controls. The ability to bypass rate limiting also facilitates automated reconnaissance tools that rely on iterative login attempts to enumerate valid usernames or test password policies without being blocked by standard anti-brute-force defenses.
From a classification perspective, this flaw aligns with CWE-287 Improper Authentication and CWE-307 Improper Restriction of Excessive Authentication Attempts. In the context of the MITRE ATT&CK framework, this vulnerability enables techniques associated with Credential Access such as Brute Force (T1110) and Password Spraying (T1110.003). The lack of robust source IP verification allows adversaries to operate undetected by standard intrusion detection systems that monitor for high-frequency login failures from a single origin point.
Mitigation strategies must address both the immediate configuration gaps and long-term architectural improvements. Administrators should immediately upgrade Gophish to version 0.12.2 or later, where this rate limiting bypass has been patched to correctly identify client IPs regardless of spoofed headers. In environments where upgrading is not immediately feasible, deploying a reverse proxy such as Nginx or Apache in front of the application can provide an additional layer of defense by enforcing strict IP-based rate limiting at the network edge before requests reach the Gophish backend. It is crucial that these external proxies are configured to trust only known internal load balancers and ignore X-Forwarded-For headers from untrusted sources, ensuring that the true client IP is preserved for security controls. Additionally, implementing multi-factor authentication adds a critical secondary barrier against credential-based attacks regardless of rate limiting efficacy.