وَأَن لَّيْسَ لِلإِنسَانِ إِلاَّ مَا سَعَى * وَأَنَّ سَعْيَهُ سَوْفَ يُرَى * ثُمَّ يُجْزَاهُ الْجَزَاء الأَوْفَى

It started like any other day of bug hunting. I was exploring a target, just getting a feel for the application logic, when I stumbled upon a profile page. Little did I know that a simple "Read-Only" field would lead me to a catastrophic discovery where an account could literally "cease to exist."

The illusion of "Read-Only"

While browsing the account settings, I saw the email field. Next to it, there was a clear message from the developers:

🚫R "This information cannot be modified."

None

In the world of web security, "Read-Only" on the frontend is often just a suggestion. I opened Burp Suite, captured the synchronization request (/api/v1/SyncAccount), and decided to test the backend's integrity.

I first tried changing my email to a random, unregistered address. The Result? 200 OK. The UI lied; the backend was wide open.

Leveling Up: The Collision

At this point, it was a standard UI bypass. But then, a dangerous question popped into my head: "What happens if I change my email to one that is ALREADY registered on the platform?"

I took a victim's email and injected it into my attacker account's request:

POST /api/v1/SyncAccount HTTP/2
Host: target-app.com
Authorization: Bearer [ATTACKER_TOKEN]
Content-Type: application/json

{
  "email": "victim@example.com", 
  "firstName": "Attacker",
  "lastName": "User"
}

To my absolute shock, the server accepted it. Now, the system was in a state of Identity Collision: One email address was now tied to two completely different accounts, each with its own data and password.

If the attacker logged in with their password, they saw their data. If the victim logged in, they saw theirs. It was a "Digital Parallel Universe."

The Trigger: Activating the "Death" Sequence

I wanted to see if I could force the system to choose one identity over the other. I went into the attacker's account and enabled a security feature called the PIN.

Immediately after activating the PIN from the Attacker's side, I went back to the Victim's side and tried to log in. Error: "The email and/or password are incorrect."

The victim was officially evicted. The system had prioritized the "Active/Secured" record (the attacker's) and orphaned the victim's credentials.

The Final Act: "FULL ACCOUNT WILL DIE"

To understand the full scale of the disaster, I performed a password reset as the victim. I received the link, changed the password, and logged in, expecting to see my original victim data.

I was wrong.

I was redirected to the Attacker's profile. My original account, my configurations, my history, and my access were all gone. By exploiting the UI bypass and creating an identity collision, the attacker had effectively "overwritten" the victim's existence in the database.

The original account didn't just get hijacked — it died.

POST /api/v1/Account/DeleteAccount HTTP/2
Host: target-app.com
...
{"password":"[ATTACKER_PASSWORD]"}

(Final Step: Deleting the attacker account now purges the shared email identifier, making recovery impossible for the victim.)

Key Takeaways

  • Never Trust the Frontend: Read-only fields are a UI feature, not a security control.
  • Enforce Uniqueness: Database-level constraints are mandatory for primary identifiers like emails.
  • Atomic Identity: Authentication flows must rely on immutable Internal IDs, not mutable strings like emails.

The moral of the story: When two identities collide in a poorly designed logic flow, only one survives.

Status: Vulnerability confirmed . Impact: P1 (Critical)

None