Description

Monkeytype is a minimalistic and customizable typing test. In 26.26.0 and earlier, the backend rate-limit key generator in backend/src/middlewares/rate-limit.ts uses client-controlled cf-connecting-ip and x-forwarded-for headers before the trust-proxy-derived req.ip value. An unauthenticated attacker can rotate either header to create a new bucket for each request, bypassing rootRateLimiter, badAuthRateLimiter, getKey(), and the getKeyWithUid() fallback used by public endpoints. This permits repeated POST /users/forgotPasswordEmail and verificationEmail requests, mail bombing registered users, consuming Firebase or SMTP quota, evading brute-force protection, and enabling resource exhaustion. Exploitability of cf-connecting-ip depends on deployment topology, but x-forwarded-for and direct-to-origin paths remain affected when those values are not overwritten by a trusted proxy. No fixed version is available as of this review.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-20T17:19:34.387Z",
  "pubdate": "2026-08-20T17:19:34.387Z",
  "executiveSummary": "A rate-limiting bypass vulnerability exists in Monkeytype version 26.26.0 and earlier due to improper handling of client-controlled HTTP headers during rate-limit key generation.\nThe backend rate-limit key generator located in backend/src/middlewares/rate-limit.ts incorrectly prioritizes the cf-connecting-ip and x-forwarded-for headers over the trusted, proxy-derived req.ip value.\nThis flaw allows unauthenticated attackers to spoof or continuously rotate these headers, effectively generating a unique rate-limiting bucket for every incoming HTTP request.\nConsequently, attackers can completely evade security controls provided by rootRateLimiter, badAuthRateLimiter, getKey(), and the getKeyWithUid() fallback mechanism utilized by public endpoints.\nThe successful exploitation of this vulnerability enables malicious actors to execute repeated requests to sensitive endpoints such as POST /users/forgotPasswordEmail and verificationEmail.\nThis facilitates large-scale mail bombing attacks against registered users, rapid exhaustion of underlying Firebase or SMTP provider quotas, circumvention of brute-force protection mechanisms, and overall application resource exhaustion.\nExploitation of the cf-connecting-ip vector depends heavily on the specific deployment topology, whereas the x-forwarded-for vector and direct-to-origin configurations remain directly vulnerable when proxy mechanisms fail to sanitize or overwrite untrusted client inputs.",
  "technicalDetails": "The root cause of this vulnerability lies in the architectural design of the backend rate-limiting middleware implemented in backend/src/middlewares/rate-limit.ts within Monkeytype versions 26.26.0 and earlier.\nWhen evaluating incoming HTTP requests to determine the origin IP address for rate-limiting calculations, the rate-limit key generator evaluates client-supplied HTTP headers—specifically cf-connecting-ip and x-forwarded-for—prior to inspecting the cryptographically secure and trust-proxy-derived req.ip property.\nBecause unauthenticated attackers have direct control over the values transmitted within the cf-connecting-ip and x-forwarded-for headers, they can manipulate these fields arbitrarily on a per-request basis.\nBy altering the header value with every subsequent HTTP request, the attacker forces the rate-limiting subsystem to generate a new, isolated key and bucket for each transmission.\nThis behavior completely bypasses the intended defensive thresholds enforced by rootRateLimiter, badAuthRateLimiter, getKey(), and the getKeyWithUid() fallback function designed to protect public endpoints.\nThe attack flow proceeds as follows: an unauthenticated attacker crafts an HTTP request targeting sensitive endpoints like POST /users/forgotPasswordEmail or verificationEmail. Within the request headers, the attacker injects a unique or sequentially incremented IP address string into the x-forwarded-for or cf-connecting-ip headers. The vulnerable middleware parses this untrusted header, treats it as the definitive client identifier, and instantiates a new rate-limit tracking bucket. As a result, the request is processed successfully without triggering any rate-limiting blocks.\nThe attacker can script this process to loop continuously, bypassing authentication and authorization barriers while operating over standard network exposures.\nThe post-exploitation impact includes severe resource exhaustion, rapid depletion of third-party SMTP or Firebase transactional email quotas via continuous mail bombing of registered users, and the total neutralization of brute-force mitigations protecting authentication and recovery workflows.\nNo fixed version is currently available as of this review, meaning systems remain vulnerable unless manual topological adjustments are enforced."
}