CVE-2026-72584

The core vulnerability here isn't a code bug—it's a design failure. Fastschema's OTP rate limiter implements a classic check-then-increment pattern without accounting for concurrent request processing: each request checks the attempt counter, but before incrementing, other parallel requests also read the same counter value. The result is that rate limits become unenforceable. An attacker can spawn concurrent requests and systematically iterate through the full 6-digit OTP space (1,000,000 combinations) because every request sees the counter at its pre-increment state. The rate limit isn't weakened; it's nullified as a security control. This is particularly dangerous because the attack is unauthenticated. An attacker doesn't need a compromised account or any foothold—they target the account recovery endpoint directly. That shifts the threat from targeted to opportunistic, vastly expanding what's exposed. The deeper problem is architectural. Rate limiting was almost certainly added late in development as a compliance checkbox, with the developer thinking linearly ('check count, then increment') rather than considering how their framework handles hundreds of concurrent requests. That cognitive gap—a checklist security requirement versus a concurrency-hardened mechanism—produces this exact vulnerability class consistently across frameworks. If your rate limiter wasn't designed with atomic operations and thread safety as foundational requirements, it's already vulnerable to this pattern, regardless of the specific codebase. The blast radius extends beyond OTP guessing. Successful account recovery grants access to the full session token that downstream services trust by design. This creates a lateral movement path without requiring a second vulnerability—authentication token reuse across microservices means compromising one flow compromises the ecosystem. For defenders: verify whether your OTP implementation uses atomic database operations or proper locking for the counter, not application-level increments. The fix is either atomic increments (database-level ADD or mutex-protected counters) or moving to stateless HMAC-based OTP verification, which eliminates shared state entirely. Check your account recovery flow for the same check-then-increment pattern—if it exists elsewhere, it's likely vulnerable to the same race condition. Monitor for anomalous OTP request volumes, but recognize that robust anomaly detection and this vulnerability likely share the same design-in rigor deficit—if concurrency wasn't considered in the rate limiter, it probably wasn't considered in the monitoring either.

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