Monkeytype's backend rate-limit key generator in versions 26.26.0 and earlier uses client-controllable cf-connecting-ip and x-forwarded-for headers before the trusted proxy-derived req.ip value. An attacker can spoof these headers to create new rate-limit buckets per request, bypassing rootRateLimiter, badAuthRateLimiter, getKey(), and getKeyWithUid() fallback mechanisms used by public endpoints. This enables repeated POST requests to /users/forgotPasswordEmail and verificationEmail endpoints, resulting in mail bombing of registered users, consumption of Firebase or SMTP quotas, evasion of brute-force protections, and potential resource exhaustion. Exploitability depends on deployment topology, with x-forwarded-for and direct-to-origin paths always affected if not overwritten by a trusted proxy. No fixed version is available as of this report. The service is cloud-hosted, so vendor-managed remediation is expected.

The vulnerability allows unauthenticated attackers to bypass rate limiting by spoofing client IP headers, leading to repeated triggering of email-related endpoints. This can cause mail bombing of users, exhaustion of email service quotas (Firebase or SMTP), evasion of brute-force protections, and resource exhaustion on the backend. There is no direct confidentiality or integrity impact reported. The CVSS score is 7.5 (high) with no confidentiality or integrity impact but high availability impact.

As monkeytype is a cloud-hosted service, the vendor manages remediation server-side. Users should monitor vendor advisories for updates. No fixed version is currently available. Deployment architectures should ensure trusted proxies overwrite client-controlled headers like x-forwarded-for and cf-connecting-ip to prevent spoofing. Until a vendor fix is released, reliance on trusted proxy configurations is critical.