CVE-2026-69183

The CVSS 7.5 on this CVE badly understates the risk. It's not that one rate limiter gets bypassed—it's that six independent protection layers collapse simultaneously. The application reads cf-connecting-ip (and x-forwarded-for) directly from client headers to identify requesters for rate limiting, which means an attacker sending those headers can claim any identity they want. Every rate-limited endpoint—password reset, email verification, account recovery, authentication failures—loses its throttle simultaneously. The attack vector is email bombing: flooding registered users with password reset or verification emails until Firebase quotas exhaust, accounts lock out, or the noise drowns legitimate traffic. That's the actual impact, and it's real harm against real users. The CVSS measures a technical gap, not the adversarial business outcome. If you have Cloudflare in front of Monkeytype, cf-connecting-ip is set by the CDN and you're not directly trusting client input—but verify your deployment. If Monkeytype is directly exposed to the internet (direct-to-origin), that header is client-controlled and the bypass is trivial. Check whether your proxy is actually overwriting these headers before the application sees them, or whether trust-proxy settings are correctly applied. With no patched version available yet, your only mitigation is deployment-level header stripping. Configure your proxy to remove or overwrite cf-connecting-ip and x-forwarded-for before requests reach the application. If you can't trust your proxy layer, rate limiting at the application layer cannot work—move it to the proxy where client identity is actually knowable. This is an architectural issue, not a simple input-validation bug; sanitizing headers in-app won't fix the fundamental problem that the app is trying to identify requesters using attacker-controllable data.

Reviewed through automated stages and approved by a human before publication.