Improperly Configured rack_attack.rb does not prevent rate limit attacks in lobsters/lobsters


Reported on

Jul 6th 2022


The lobsters repository depends upon rack_attack.rb to prevent rate limit attacks against the /login or the /login/set_new_password endpoint, allowing for only 4 requests in a minute. However, this can be bypassed by simply appending some strings like /login.turtles to the endpoint.

Proof of Concept

$ while true; do curl -ikIL "" -X POST -d "{'username': 'itsmemario'}"; done


This can allow an attacker to bypass rate-limit checks and brute-force login attempts. (See References for further readings)


The vulnerability arises due to the following lines of code:

Rack::Attack.throttle("login", limit: 4, period: 60) do |request|
  request.ip if &&
                (request.path == '/login' || request.path == '/login/set_new_password')

The main vulnerability arises due to the fact that request.path is an absolute. With a bit of junk injection, we can append random strings of characters to the protected directory.

We are processing your report and will contact the lobsters team within 24 hours. a month ago
whokilleddb modified the report
a month ago
We created a GitHub Issue asking the maintainers to create a a month ago
We have contacted a member of the lobsters team and are waiting to hear back 25 days ago
We have sent a follow up to the lobsters team. We will try again in 7 days. 22 days ago
A lobsters/lobsters maintainer
21 days ago


Thanks for reporting this. I've updated it:

diff --git config/initializers/rack_attack.rb config/initializers/rack_attack.rb
index e9557830..5a8e54bd 100644
--- config/initializers/rack_attack.rb
+++ config/initializers/rack_attack.rb
@@ -18,8 +18,10 @@
 # at some point they'll proceed to testing credentials
 Rack::Attack.throttle("login", limit: 4, period: 60) do |request|
-  request.ip if &&
-                (request.path == '/login' || request.path == '/login/set_new_password')
+  request.ip if && (
+                 request.path.starts_with?('/login') ||
+                 request.path.starts_with?('/login/set_new_password')
+  )

 Rack::Attack.throttle("log4j probe", limit: 1, period: 1.week.to_i) do |request|

Committing and deploying this fix is backed up behind an unrelated security fix, which unfortunately broke the prod site yesterday when I deployed it:

I hope to sort that out and land this fix tonight after work.

21 days ago


Thanks. Can you please mark the report as verfied? That would really be helpful. Also, if you want to have a more comprehensive report about the vulnerability and let users know about it do that they can fix it ASAP, I guess @admin can also arrange for a CVE for you guys once it has been patched. That way, it'll be easier to document, detect and remediate ūüėÉ

Across different systems, CVE IDs give users a reliable way to recognize unique vulnerabilities and coordinate the development of security tools and solutions. Read more about it here.

A lobsters/lobsters maintainer
19 days ago


Sorry, I don't see any UI for doing that?

I don't know why we'd need a CVE, we're one website with a one-line bug that's not seeing abuse. Can't say I know much about the CVE process though. I've already written the patch, the only reason it's not deployed is the unrelated breaking change in Rails

We have sent a second follow up to the lobsters team. We will try again in 10 days. 15 days ago
A lobsters/lobsters maintainer
14 days ago


I've deployed this fix:

A lobsters/lobsters maintainer modified the Severity from High to Low 14 days ago
The researcher has received a minor penalty to their credibility for miscalculating the severity: -1
A lobsters/lobsters maintainer validated this vulnerability 14 days ago
whokilleddb has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
A lobsters/lobsters maintainer confirmed that a fix has been merged on 190ce7 14 days ago
The fix bounty has been dropped
rack_attack.rb#L22 has been validated
11 days ago


Thanks for validating the report. Also, I see that you marked the report as a low-severity. However, another very well know project had the same exact vulnerability and was reported as High because this misconfiguration can also lead to DoS attacks. Just putting it out there for future references.

A lobsters/lobsters maintainer
11 days ago


This site doesn't really do a great job of explaining itself, it has zero explanation what the consequences of any of these actions will be or what their definitions are. I don't see that I can do anything about it now, sorry.

to join this conversation