Race Condition Vulnerabilities: Bypassing Free Plan Limits

Hello, In this writeup I’m going to talk about two Race Condition vulnerabilities I found that allowed bypassing free plan restrictions.

What is a Race Condition?

A Race Condition happens when an application processes multiple requests at the same time without properly synchronizing or locking shared resources (like a counter or a limit check). If the app checks a condition (e.g “is the limit reached?”) and updates the value in two separate steps, sending many requests simultaneously can make all of them pass the check before any of them updates the value, this leads to the limit being bypassed entirely.
this is usually exploited using Burp Suite’s Repeater with the single-packet attack feature, which sends multiple requests at the exact same time to win the race before the server can properly validate and update the state.

Bug 1: Bypassing the 5-User Limit on Free Plan

the free plan on this platform only allows owner/admin accounts to add up to 5 users to the test management product, i managed to bypass this limit and add an unlimited number of users using a race condition

Discovery

while testing the User Management functionality with an owner/admin account, i noticed the user count restriction was enforced on the backend, so i wanted to see if the check could be raced

Attack Scenario

• logged in with the owner/admin role and navigated to the User Management page
• attempted to modify some users’ access to add them to the test management product
• intercepted the “add user” requests using Burp Suite
• sent all these requests simultaneously via Burp Repeater using the single-packet attack technique, creating a race condition
• the system failed to correctly enforce the user count limit, and all users were added successfully, completely bypassing the 5-user restriction

  Impact

• free plan users can bypass the 5-user restriction and add unlimited team members
• this results in potential financial loss, since users no longer need to upgrade to a paid plan to add more participants
  

Bug 2: Bypassing the 50-Scan Limit on accessibility.example.com

similar idea, but this time on accessibility.example.com, the free plan restricts users to a maximum of 50 web scans, and i was able to bypass this limit using the same race condition technique

Discovery

i started creating scans normally until i hit the limit, a pop-up appeared confirming that the free plan cap of 50 scans had been reached, so i decided to test if this limit could be raced the same way

Attack Scenario

• navigated to accessibility.example.com and attempted to create a new scan until hitting the 50-scan limit, confirmed by the limit pop-up
• intercepted the New Scan request and sent it to Burp Repeater
• duplicated the request multiple times in Repeater to match the desired number of new scans
• deleted the 50th (last) scan in the account to reset the state before firing the race
• sent all duplicated requests in parallel (single-packet attack), creating a race condition
• most of the scan creation requests succeeded, allowing me to bypass the 50-scan limit completely

  Impact

• free plan users can create an unlimited number of scans, bypassing the 50-scan restriction
• results in potential financial loss for the platform, since users no longer need to upgrade to a paid plan to exceed the scan limit