CVE-2026-69183: Monkeytype: Rate-limit and anti-brute-force controls bypassable via spoofed HTTP headers (forgotPasswordEmail/verificationEmail mail bombing and badAuth bypass)
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.
Affected Software
Event History
Frequently Asked Questions
Does exploitation require an account or user interaction?
No. An unauthenticated attacker can send repeated requests while changing client-controlled IP headers to obtain a new rate-limit bucket for each request.
Which deployment paths are most likely to remain exposed?
Direct-to-origin access is affected when the supplied forwarding headers are not overwritten by a trusted proxy. The x-forwarded-for header remains a concern in that situation; cf-connecting-ip exploitability depends on the deployment topology.
What can an attacker do after bypassing the limiter?
They can repeatedly invoke the forgotPasswordEmail and verificationEmail endpoints to mail bomb registered users. The bypass can also evade brute-force protections and consume Firebase or SMTP quota, contributing to resource exhaustion.
How can I check whether my instance is affected?
Versions 26.26.0 and earlier use a rate-limit key generator that prioritizes cf-connecting-ip and x-forwarded-for over the trust-proxy-derived req.ip value. Review whether those headers can reach the application without being overwritten by a trusted proxy, including through direct origin access.
Is a fixed release available?
No fixed version was available as of this review.