✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Greptile Summary

This PR implements rate-limiting for MFA unlock emails to prevent email spam when the POST /api/v2/auth/mfa/verify endpoint is abused. The implementation uses Redis-based distributed locking and TTL-based rate-limiting to ensure only one unlock email is sent per user per 5 minutes.

Changes:

• Added two new keystore prefixes: UserMfaLockoutLock for mutual exclusion and UserMfaUnlockEmailSent for tracking recent sends
• Injected keystore dependency into the auth login service
• Wrapped email sending logic in a lock-acquire-check-send pattern with proper cleanup

Critical Issue Found:
The error handling in the email sending block (line 933-934) catches all exceptions indiscriminately, not just lock acquisition failures. This masks legitimate errors from sendMail(), createTokenForUser(), and keystore operations, potentially breaking error monitoring and making debugging difficult.

Confidence Score: 3/5

• The PR has a critical error handling flaw that masks legitimate errors and could hide operational issues.
• The core functionality is sound - using Redis locks and TTL-based rate-limiting is the correct approach for this problem. However, the broad try-catch block around the entire email-sending logic (lines 907-939) swallows all exceptions without distinguishing between lock acquisition failures (which are expected and should be silently ignored) and actual errors from sendMail, createTokenForUser, or keystore operations (which should be logged and propagated). This pattern makes it impossible to detect if emails are failing to send, tokens are failing to create, or other critical operations are failing. The fix is straightforward but required for production safety.
• backend/src/services/auth/auth-login-service.ts - The catch block at line 933-934 needs to distinguish between expected lock failures and actual errors.

Important Files Changed