Exploiting Race Condition to Break Idempotency & Corrupt Data Integrity

While this report was Real Finding but ultimately closed as N/A (Out of Scope), the underlying vulnerability — a Race Condition leading to data integrity corruption — is a classic logical flaw that is always fun to exploit and discuss. It serves as a great reminder that even simple, everyday features can break under concurrent execution.

🎯 The Target & The Feature

The target was jobs.target.com, the career portal for the well-known hospitality company. Like many job portals, it has a feature that allows authenticated users to "Save" or "Favorite" a job posting by clicking a heart icon.

Logically, the expected behavior is simple:

• If you save a job, it goes to your "Saved Jobs" cart.
• If you click it again, it should either unsave it or do nothing (idempotency).
• One user account should only have one saved instance of a specific job.

But as bug hunters, we always ask: What happens if we send multiple requests at the exact same millisecond?

💥 The Vulnerability: Race Condition

I suspected that the application might be vulnerable to a Time-of-Check to Time-of-Use (TOCTOU) flaw. When a user saves a job, the server checks if the job is already saved. If it isn't, it writes the entry to the database.

However, if multiple requests arrive concurrently, the server might process the "Check" phase for all requests simultaneously before any of them reach the "Use" (write) phase. This means all concurrent requests would see that the job hasn't been saved yet, leading the server to write multiple duplicate entries for the exact same job.

🛠️ Steps to Reproduce (The Exploitation)

To test this theory, I used Burp Suite Professional and its powerful Repeater tab grouping feature to execute a concurrent request attack.

1. I logged into a normal user account on jobs.target.com and ensured my "Saved Jobs" list was empty for a clean testing state.
2. Intercepting the Request: I browsed the job listings, found an unsaved job > open burpsuite and turn on intercept on > and clicked the heart/save control > send request to repeater > drop all request (so the like action we did got canceled) . So now i have the request in the repeater.

• The application sent a POST request to the /widgets endpoint.

4. Duplication: I duplicated the exact same request into 7 identical Repeater tabs.

5. Parallel Execution: Beside the repeater tabs there's "+" icon, click on it > choose "Create tab group" > then checklist all tabs > click create > now all 7 tabs placed into a single group > on the tabs group, click on the dropdown > select "Send group in parallel (single-packet attack)" > click "send group (parallel)".

🚨 The Result & Impact

After firing the grouped requests, I navigated back to the Job Cart / saved-jobs page and refreshed it.

Boom! The exact same job appeared multiple times in my saved jobs list.

To confirm this wasn't just a transient UI glitch or a front-end desynchronization, I refreshed the page multiple times. The duplicate entries persisted. Even better, when I tried to delete one of the duplicate entries, only that specific entry was removed, while the other cloned copies remained safely in my account.

The Impact: By exploiting this race condition, an attacker (or a normal user) can trigger concurrent save requests for the same job and cause persistent duplicate records. This completely breaks the idempotency of the save/favorite workflow and corrupts the integrity of the database state for the user's account.

💡 Takeaways

1. Always test for Race Conditions on state-changing endpoints: It doesn't have to be a financial transaction or a coupon redemption. Simple features like "Add to Cart", "Save Job", or "Follow User" are heavily prone to concurrent execution flaws.
2. Burp's Tab Group is your best friend: The ability to send parallel requests with a single click in Burp Repeater makes testing for race conditions incredibly easy and reliable.

Thanks for reading, and happy hunting!