CVE-2026-75575: Rocket.Chat Missing DDP Rate Limit on the sendForgotPasswordEmail Meteor Method
Rocket.Chat exposes the sendForgotPasswordEmail Meteor method without a DDP rate limit, so an unauthenticated caller may invoke it as often as it likes. The method is reachable over DDP and over the HTTP route POST /api/v1/method.callAnon/sendForgotPasswordEmail, and it triggers a password reset message for any address that matches an account. With no DDPRateLimiter rule registered for it, a caller can drive an unbounded volume of reset mail at a chosen address from the deployment's own mail sender, and can probe addresses at scale: the method answers true for an address with no account and for a successful send, but false when the address belongs to an account that authenticates through an external provider and AccountsAllowPasswordChangeForOAuthUsers is off, so repeated calls distinguish that class of account. Later versions register a rule permitting ten calls per minute per client address.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Rocket.Chatto a version that resolves this vulnerability.Fixed in Later versions register a rule permitting ten calls per minute per client addressPatch Missing DDP Rate Limit on the sendForgotPasswordEmail Meteor Method
Event History
Frequently Asked Questions
Who can exploit this issue?
Any unauthenticated remote caller that can reach the Rocket.Chat DDP endpoint or the POST /api/v1/method.callAnon/sendForgotPasswordEmail route can invoke the method repeatedly. No account or user interaction is required.
What can an attacker do with repeated requests?
An attacker can cause an unbounded volume of password-reset email to be sent to an address associated with an account, using the deployment's configured mail sender. They can also probe account behavior at scale based on whether the method returns false for externally authenticated accounts when password changes for OAuth users are disabled.
Are externally authenticated accounts affected in the same way?
When an address belongs to an account authenticated through an external provider and Accounts_AllowPasswordChangeForOAuthUsers is off, the method returns false rather than sending the reset message. This response difference can allow callers to distinguish that account class.
What rate limit addresses the issue?
Later versions register a DDPRateLimiter rule for this method that permits ten calls per minute per client address.