Valid Tokens, Broken Limits: A Race Condition Story

Valid Tokens, Broken Limits: A Race Condition Story

🐦‍🔥 Platform Overview

During my recent bug hunting activities, I came across a platform (referred to here as ProjectHub to comply with responsible disclosure policies).

The platform offers two types of accounts:

• Free Plan Allows users to have only one project, which is automatically created upon account registration.
• Pro Plan (Trial) Allows users to create unlimited projects during the trial period.

Any attempt to create additional projects on a Free account results in a prompt to upgrade the subscription..

💡 New to Race Conditions?

If you want to understand Race Conditions in a simple way and learn how to reproduce them step by step, check out this write-up:

🔗 Bypassing a Monthly Secure Message Limit Using a Race Condition https://medium.com/@pophacker996/bypassing-a-monthly-secure-message-limit-ecd700714720

It provides a beginner-friendly explanation of the concept and demonstrates how parallel requests can break business logic restrictions.

🐦‍🔥 Vulnerability Summary

• Vulnerability Type: Race Condition (TOCTOU)
• Affected Component: Project Creation Endpoint
• Core Issue: The application relies on a pre-check for project limits without enforcing it during execution, and lacks proper locking/atomic operations, allowing concurrent requests to bypass plan restrictions.

🐦‍🔥 Exploitation Workflow

1. Understanding the Project Creation Flow

The project creation process consists of two main steps:

• Access the project creation page:

GET /{Workspace_ID}/projects/new

GET /{Workspace_ID}/projects/new

• Submit the project creation request:

POST /{Workspace_ID}/projects

POST /{Workspace_ID}/projects

The POST request includes a critical parameter:

authenticity_token

authenticity_token

2. Discovering the Token Source (Using Burp Search)

Initially, the main obstacle was the authenticity_token:

• It changes with every request
• It is tied to the session
• It cannot be reused across accounts

To understand its origin, I used Burp Suite's Search feature:

• I captured a valid request containing the token
• Then searched for the same token across all proxy history responses
• This revealed that the token appears in the response of:

GET /projects/new

GET /projects/new

💡 This confirmed that:

Each visit to /projects/new generates a fresh valid token

3. Limitation on Free Accounts

When accessing:

/projects/new

/projects/new

Free accounts are redirected to:

/account/upgrade_needed

/account/upgrade_needed

This prevents direct access to valid tokens.

4. Manipulating Application State

To bypass this limitation:

• The default project was deleted
• The project count became 0
• Access to /projects/new was restored

5. Collecting Multiple Tokens

• The /projects/new endpoint was accessed repeatedly
• Multiple valid tokens were collected (e.g., 5 tokens)

6. Triggering the Race Condition

• Multiple project creation requests were prepared
• Each request included a different valid token
• All requests were sent simultaneously (parallel execution) using Burp Suite (Send Group)

🧠 Root Cause

The vulnerability occurs because:

The application validates the project limit before execution but does not enforce it during execution with proper synchronization

This leads to a classic:

Time-of-Check to Time-of-Use (TOCTOU) vulnerability

🐦‍🔥 Proof of Concept (PoC)

Step 1 — Create a Free account Step 2 — Delete the default project Step 3 — Access /projects/new multiple times to collect tokens Step 4 — Page Source → Extracting the tokens

Step 5 — Prepare multiple POST requests (each with a unique token) Step 6 — Send all requests in parallel using Burp Suite

🎯 Result

Successfully created multiple projects (e.g., 5 projects) on a Free account, bypassing the intended limitation of a single project.

🐦‍🔥 Risk & Impact

Although the impact here is limited to subscription abuse, similar race conditions can be critical in other contexts:

• Billing manipulation
• Resource exhaustion
• Abuse of sensitive features (roles, invites, payments)

In this case:

👉 Impact is limited to business logic abuse

🐦‍🔥 Final Thoughts

This vulnerability highlights the importance of:

• Implementing atomic operations
• Enforcing server-side locking
• Avoiding reliance on pre-checks without securing execution

Additionally, it demonstrates how tools like Burp Suite (especially Search) can help uncover hidden relationships between requests and responses.

🔥Even though the issue was out of scope, Sometimes, the real reward isn't the bounty — it's the deep understanding of how systems actually work.

🤝 Let's Connect! If you have any questions, feel free to reach out. Bavly Zaher | LinkedIn

This work was a collaboration with Zeyad Abdelrhman | LinkedIn