Race Condition: Claiming the Same Sunbed More Than Once

At first glance, Towel on the Sunbed appears to be a simple reward-claim system. Users place a towel on a sunbed, wait for the appropriate time, and receive a reward. However, behind this seemingly harmless functionality lies a classic Race Condition vulnerability.

In this write-up, we'll explore how improper synchronization between concurrent requests allows us to claim the same reward multiple times and ultimately complete the challenge.

The first step is straightforward. Create a new account and log in to the application.

After signing in, you'll notice that the application provides a Welcome Reward. Clicking the Claim Reward button sends a request to the backend, where the reward is marked as claimed.

At first, everything behaves exactly as expected — but this is where the interesting part begins

Understanding the Frontend

Before attacking the backend, it's always worth understanding how the frontend controls user interaction.

Open your browser's Developer Tools and inspect the Claim Reward button. You'll notice that the application relies on a frontend value to determine whether the button should remain disabled after the reward has been claimed.

Since this restriction exists only on the client side, we can easily bypass it.

After saving the override and refreshing the page, the Claim Reward button becomes available again.

Although this doesn't bypass the backend validation by itself, it allows us to repeatedly send requests to the server — exactly what we need for the next step.

Now it's time to test whether the backend correctly handles concurrent requests.

Intercept the Claim Reward request using Burp Suite. Once captured, right-click the request and select Send to Group.

Create a new request group and duplicate the request several times.

Finally, use Send Group in Parallel to ensure that every request reaches the server at nearly the same moment.

If the application lacks proper synchronization, multiple requests may be processed before the reward status is updated.

Triggering the Vulnerability

After sending the grouped requests:

1. Turn Intercept off in Burp Suite.
2. Disable the browser proxy.
3. Refresh the page.

If everything worked correctly, the application will have processed multiple reward requests simultaneously.

Instead of granting the reward once, the server accepts several concurrent requests before updating its internal state.

This behavior confirms the presence of a Race Condition vulnerability.

Success! The application accepted multiple concurrent requests

Conclusion

This challenge demonstrates why relying solely on frontend restrictions is never sufficient. More importantly, it highlights the importance of implementing proper synchronization on the server side when handling operations that should only occur once.

Without atomic operations or appropriate locking mechanisms, concurrent requests can bypass business logic and lead to unintended behavior, as demonstrated in this Race Condition vulnerability.

The Next Stop: CryptoCabana

CryptoCabana Walkthrough: Exploiting Implicit Trust in Azure | by Isv0x1 | Aug, 2026 | Medium

FOLLOW ME

Linkdin : www.linkedin.com/in/islam-salem-5a13a032b

اللهم انصر اخواننا في غزة