Security vulnerabilities

Attached to Project: Security vulnerabilities
Opened by Jay_Riod - 24.07.2026
Last edited by cbay - 24.07.2026

A rate limiting algorithm is used to check if the user session (or IP address) has to be limited based on the information in the session cache. In case a client made too many requests within a given time frame, HTTP servers can respond with status code 429: Too Many Request. I just realized that on the reset password page, the request has no rate limit which can be used to loop through one request

Steps to reproduce-

.Go to the alwaysdata password reset page.
.Enter the email address of a test account controlled by the researcher.
.Submit the password reset request.
.Repeat the same request multiple times within a short period using the same email address.
.Observe that the application continues accepting the requests without showing a cooldown, CAPTCHA, temporary block, or rate-limit error.

Observed Result:
The application allows repeated password reset email requests for the same account without visible throttling or blocking.

Expected Result:
The password reset endpoint should apply abuse protection, such as:

Per-account cooldown.
Per-IP rate limiting.
CAPTCHA after repeated attempts.
Temporary blocking after excessive requests.
Generic response message to reduce abuse.

Security Impact:
An attacker could abuse this behavior to repeatedly send password reset emails to a target user. This may cause inbox flooding, harassment, and abuse of the platform’s email-sending resources.

I tested this only against my own account and did not attempt to target other users or perform high-volume testing.

Proof of Concept is in the video below