How I Found a No Rate Limit Vulnerability on a Login Endpoint, Earned a 100€ Bounty, and My Approach to Testing for No Rate Limit Issues

Hi friends, I’m Jivan, back with another write-up related to a No Rate Limit vulnerability.
In this article, I will explain a No Rate Limit vulnerability that I discovered, for which I was rewarded a bounty of 100€ Euros.

Before diving into how I found this vulnerability, I want to briefly explain what a No Rate Limit vulnerability is, its impact, and how it is typically treated in bug bounty programs.
Many new hunters often face challenges when reporting valid No Rate Limit vulnerabilities, such as the lack of rate limiting on “Forgot Password” endpoints, which can lead to email bombing or SMS flooding.
Unfortunately, these types of issues are often considered out of scope in many bug bounty programs or classified as low priority (P5) or simply marked as “informative.”

If you are reporting this type of No Rate Limit vulnerability that only causes email or SMS flooding, most companies will classify it as a P5 or an informative finding.
However, there is always a chance, as some companies do accept this type of bug and may even reward a bounty.

Now, let’s begin with how i found the No Rate Limit Vulnerability.

Due to security reasons, I can’t disclose the company or target details, so I’ll refer to it as [Redacted Dot Com], where I discovered the security issue on their web application.

When I reviewed the bug bounty scope and policy, I carefully read that the company stated:
“No Rate Limit Vulnerability on Unauthenticated Endpoints is Out of Scope.”

If you’re new to bug bounty or reporting bugs related to No Rate Limit vulnerabilities, you’ll often come across this type of statement in the out-of-scope section. Many new hunters, after reading this, assume that all rate limit vulnerabilities are out of scope and skip this test in their checklist.

But I want to clarify this for new hunters:
If you see this statement in a bug bounty policy, it only means that rate limit vulnerabilities on unauthenticated endpoints are out of scope — for example, No Rate Limit on Forgot Password, or endpoints that allow attackers to flood with SMS, OTP, or email requests.

However, here’s the key point: if you carefully read the policy line
“No Rate Limit Vulnerability on Unauthenticated Endpoints is Out of Scope,”
this means that authenticated or sensitive endpoints like the login endpoint are still in scope.

So, if you discover a No Rate Limit vulnerability on a login endpoint, it is considered a valid security issue, and you can receive a bounty. Login endpoints are sensitive areas of any application, and being able to brute-force login credentials is a valid and impactful finding.

I hope this clears things up. If not, feel free to drop a comment below.

Now, back to the point.
After reading the policy, I started BurpSuite and created an account on [Redacted Dot Com]. Once the account was created, I logged out and navigated to the login endpoint.

To test for a No Rate Limit vulnerability on the login endpoint, I entered my username (email ID) and an incorrect password. Then, I captured the request in BurpSuite.

The captured request was:
POST /index.php?route=account/login/ajax HTTP/2
This request contained my email as the username and the incorrect password I had supplied.

After capturing this POST request, I sent it to the Intruder tab in Burp Suite to perform a brute-force attack and check whether any rate limiting mechanism was in place.

In the Intruder tab, I selected the password as the payload position and set the payload type to Simple list.
When testing this kind of security flow on any target, it’s important to create a random password wordlist. In my case, I created a list of 50 random passwords and added the correct password at a few random positions within that list.

I then expanded the list to a total of 1,000 password payloads and used it to confirm whether rate limiting was enforced on the login endpoint.

After that, I clicked on the Start Attack button and waited for the attack to complete.
I received HTTP 200 OK status codes for all requests in the attack.
Since I knew the correct password, I checked the responses. If the password didn’t match, the response showed "result": "error"

So, I looked for the status "result": "ok", which indicates the correct password was found and confirms that our brute-force attack worked on the login endpoint.

This proves there is no rate limit on login, which is a valid security issue.
However, to ensure the company accepts this report, you must demonstrate the attack using at least 1000 payloads. Otherwise, it may be closed as “informative.”
I have reported this type of issue many times across different bug bounty programs, and all my reports have been accepted as valid security issues.

After confirming that [Redacted Dot Com] was vulnerable to a No Rate Limit on the Login Endpoint, I created a detailed and comprehensive report and submitted it to the company. After review, the triager classified it as a Medium severity issue and awarded a bounty of 100€ Euros.

🙏 Thank You for Reading!