One Race Condition, Nine Projects, One Shared Data

While testing a web application I found a race condition in its project creation feature that allowed me to create nine projects with the same name and identifier.

But the real issue was not the duplicate projects. All nine projects shared the same internal Project ID and underlying data. Finding the Race Condition The affected endpoint was:

"POST /backend/createproject/create" Normally, the application prevents users from creating projects with an existing name or identifier.

By sending multiple requests concurrently I bypassed this restriction and created nine projects with the same details. One ID, Shared Data

After creating the projects I checked their details and found that all of them had the same internal Project ID: "919909".

I then tested whether the projects were isolated.

• Uploading a file to one project made it visible in the others.
• Modifying or deleting shared data affected the other projects.
• A member invitation created through one project was accepted, although its broader access implications were not fully verified.

The projects appeared separate in the interface but they were operating on the same underlying project state.

Why This Matters This was more than a duplicate creation issue.

The race condition allowed multiple project entries to be created while sharing the same internal identity and data. Depending on the application's access controls, this behavior could lead to project isolation and data integrity issues.

This finding highlights the importance of handling concurrent requests safely. Uniqueness checks should be enforced atomically and each project should maintain a consistent identity with properly isolated data and access controls.

All testing was performed using controlled test projects and data. The target's identity has been omitted to avoid disclosing the affected service.