CVE-2026-75575 in Rocket.Chatinfo

Summary

by MITRE • 08/25/2026

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 Accounts_AllowPasswordChangeForOAuthUsers is off, so repeated calls distinguish that class of account. Later versions register a rule permitting ten calls per minute per client address.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 08/25/2026

The vulnerability in Rocket.Chat stems from the absence of adequate rate limiting on the sendForgotPasswordEmail Meteor method when accessed via Distributed Data Protocol (DDP) and its corresponding HTTP endpoint POST /api/v1/method.callAnon/sendForgotPasswordEmail. This architectural oversight allows unauthenticated actors to invoke the function without restriction, enabling them to trigger password reset emails for any email address that corresponds to an existing user account within the system. The lack of a DDPRateLimiter rule means there is no mechanism to throttle or cap the frequency of these requests, leaving the deployment's mail sender exposed to unbounded usage from external sources.

From an operational perspective, this flaw facilitates two distinct categories of malicious activity: denial-of-service attacks and user enumeration. By sending a high volume of reset emails to a specific target, attackers can overwhelm the recipient’s inbox or exhaust the organization’s email delivery quotas, effectively causing a service disruption. Simultaneously, the method exhibits discriminatory behavior based on account authentication types. It returns true for addresses associated with standard accounts as well as those without any account, but it explicitly returns false when the address belongs to an account that authenticates exclusively through external providers and where Accounts_AllowPasswordChangeForOAuthUsers is disabled. This binary response pattern allows attackers to probe email lists at scale, distinguishing between local user accounts and OAuth-only accounts with high precision.

This behavior aligns closely with CWE-754: Improper Check for Unusual or Exceptional Conditions, as the system fails to validate input constraints regarding request frequency before processing sensitive operations. Furthermore, the capability to enumerate valid email addresses by observing response codes maps directly to ATT&CK technique T1082: System Information Discovery, specifically under sub-techniques involving account enumeration. The ability to confirm the existence of an account based on a boolean return value constitutes a significant information disclosure risk that can be leveraged for subsequent targeted attacks such as phishing or credential stuffing.

Mitigation strategies must focus on implementing strict rate limiting controls at both the application and network levels. As noted in later versions, registering a DDPRateLimiter rule to restrict calls to ten per minute per client address is an effective remediation that balances usability with security. Organizations should also ensure that their mail servers are configured with appropriate throttling policies to prevent abuse even if application-level controls fail. Additionally, developers should review other unauthenticated API endpoints for similar rate limiting gaps and consider implementing CAPTCHA challenges or email verification steps before allowing password reset requests to further reduce the attack surface.

Responsible

VulnCheck

Reservation

08/18/2026

Disclosure

08/25/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!