How I Found a Data Deletion Bypass via Subdomain Synchronization

🙌🏻Introduction

Hello everyone! Shortly after my lunch break one afternoon, I accidentally discovered a quite serious business logic errors vulnerability. This flaw enabled a user with a Moderator role to delete an entire organizational group simply by visiting the group settings. Naturally, such a destructive action should strictly be restricted to users with Admin or Owner privileges.

In appreciation of the report, the security team provided a a fairly attractive cash reward. To give you an idea, if you live in a major capital city, the bounty is more than enough to fund a premium retail shopping spree.

Interestingly, this finding did not involve any advanced hacking techniques, sophisticated tools, or magical payloads.

There is only one key

High curiosity supported by a deep understanding of how the application workflow operates.

🏗️ Architecture & Application Flow

I discovered this vulnerability in a self-hosted bug bounty program with a fairly broad scope. After thoroughly reviewing the program rules, my first step was to perform subdomain enumeration using a mix of online tools and command-line utilities like VirusTotal , Subfinder, redlimit and similar asset discovery tools.

After filtering the scanning results, one particular subdomain caught my attentiontodo.redacted.com. The application functions as an activity scheduler designed to boost daily user productivity. Without hesitation, I decided to dive deep into it mapping out the application flow and studying the developer documentation to understand all the available features.

The authentication architecture had an interesting twist. To use todo.redacted.com, new users had to sign up first. However, the registration process redirected users to a completely separate subdomain account.redacted.com. Only after successfully creating an account on the account subdomain could a user log back in and access the todo platform.

Looking at this architectural setup, a hypothesis immediately came to my mind:

These two subdomains exchange data in the same database without any process isolation (separation). This means that any configuration errors in the account subdomain will affect the todo subdomain.

So, how did I confirm it?

It was surprisingly simple. When a primary user creates an organization and invites a second user via the account.redacted.com dashboard, the changes automatically sync the moment the primary user opens todo.redacted.com. The newly created organization and its invited members instantly populate on the todo subdomain.

🧑‍🏫Understanding the target (account.redacted.com)

The account.redacted.com subdomain serves specifically as the central hub for account setting, group creation, and member management.

The most interesting component to audit here was the group member management feature. Within this feature, the system implements a Role-Based Access Control (RBAC) model with three distinct privilege levels:

• Owner / Admin (Full Access): Holds the highest level of control. They can create groups, invite new members, edit group profiles, remove members, change user roles, and permanently delete the group.
• Moderator (Medium Access): They can edit group profiles, invite new members, remove members, and update roles of lower tier users. Crucially, this role should not have the authority to delete a group.
• Member (Lowest Access): The standard user role with highly restricted privileges. Generally, they can only view information within the group without making any structural changes.

🧑‍🏫Understanding the target (todo.redacted.com)

Once an organization is created and members are invited via account.redacted.com, the state is automatically synchronized to todo.redacted.com.

In theory, all entire roles on the todo subdomain apply the same authorization permissions as theaccount.redacted.com subdomain.

🧠 The Thought That Led to the Bug

In reality, when a user with a Moderator role accessed the group on todo.redacted.com, a Delete Group button was visibly present in the User Interface (UI) and its functionality wasn't restricted at all.

At that moment a question arose in me:

Since both subdomains dynamically exchange data, shouldn't the Moderator be restricted from deleting a group on the todo platform as well? Shouldn't that delete button be functionally disabled or hidden from the UI for moderator role?

Question 2

What if this is a genuine vulnerability? If a Moderator successfully deletes a group on the todo side, will that action cascade and completely wipe out the group on the central account platform as well?

🔍 What I Found in the Real Case

Without wasting any time, I decided to test the functionality of the deletion button. To my surprise, After clicking Delete Group button the backend didn't enforce any server side validation or rejection. The server seamlessly processed the request, executing a destructive action triggered by the Moderator role.

💥 Impact

The consequence was severe the organizational group was permanently deleted from both the todo and account subdomains.

According to the developer documentation, the capability to delete organizations is strictly reserved for Admin and Owner roles, this flaw proved otherwise. In reality, due to a severe synchronization flaw, a Moderator could fully execute a cross-subdomain cascade deletion, compromising the integrity of both interconnected platforms through a single request on the todo side.

🤔What I Expected vs What Happened

Expected

❌The server immediately refused and the action failed.

Actual

✅200 OK And after refreshing the UI moderator role successfully deleted the groups on both subdomains

🕛Timeline

• Reported: Aug 10, 2025
• Triaged: Accepted
• Severity: High
• Bounty: Very interesting
• Fix: The application implement proper authorization permissions and access control from both the user interface (UI) and API Endpoint sides.

🤔Root Cause

The application server didn't implement data authorization properly and created a confusion between the account subdomain and the todo subdomain.

🔚Conclusion

Serious vulnerabilities often arise from simple hypotheses and techniques, not always from complex (advanced) methods. However, this doesn't mean we should ignore advanced techniques. This proves that vulnerabilities still exist with simple techniques.

One important aspect that hunters often overlook is reading the official documentation published by the developer. Sometimes, there are hidden security vulnerabilities hidden behind this documentation, something that other hunters often overlook. Always be suspicious of an application's workflow.