🔍 Quick Overview

• Vulnerability Type: IDOR chained with WebSocket Information Disclosure
• Severity: High
• Affected Endpoint: /api/auth/account
• HTTP Method: DELETE
• Discovery Date: 26 Dec , 2025
• Impact: By obtaining a valid account ID through WebSocket information leakage, an attacker can delete any user account without any additional verification or authorization checks. This allows unauthorized account deletion, leading to potential account takeover consequences, data loss, and service disruption.

Subject

Hello, my hacker friends 👋 Welcome to a new write-up covering a newly discovered vulnerability in a chat website.

While I was bored (the most dangerous state for any security researcher 😄), I decided to look for a website where I could practice my skills. I typed "chat websites" into Google and started exploring some of the results until one particular site caught my attention.

After around five minutes of normal usage, the first thing I noticed while monitoring the traffic was something… interesting. Most requests sent to the server did not include any important cookies or tokens — no session ID, no JWT, and no authentication headers. At first, this seemed acceptable since I was interacting with the website as a guest user.

However, things became more suspicious when I created an account and logged in. While monitoring the traffic with Burp Suite, I observed that the situation remained exactly the same. Even after authentication, requests such as sending messages or reporting users were still sent without any authorization tokens, cookies, or headers.

At this point, curiosity turned into concern — and concern quickly turned into testing 😈.

At this point, I was convinced that there had to be another way for the client to send actions to the server. If HTTP requests were not handling these actions, then logically, another communication method had to be in place.

That was when I immediately thought about the WebSocket protocol.

After switching to the WebSocket tab in Burp Suite, I found a large number of messages being exchanged between the client and the server. This confirmed my suspicion. I started analyzing these messages carefully to build a clearer picture of how the application processes user actions behind the scenes.

And that was where things started to get interesting.

After a few minutes of analysis, I was able to build a clear picture of how the application works. I was surprised to find that the application relies on WebSockets for almost every action, including:

• Sending messages
• Reading (seen) messages
• Editing messages
• Receiving messages
• Updating online users
• Sending notifications
• And more…

However, one WebSocket message immediately caught my attention.

The server was sending a message to the client (me) called update_users. This message was massive, split across multiple frames, and contained sensitive data. Its payload consisted of a JSON object listing all online users, along with their information such as :

• Username
• Bio
• Email address (for non-guest users)
• Age
• Other profile-related data

This behavior resulted in a serious information disclosure, exposing private user data to any connected client without proper access control.

At this stage, the exposed data mainly included users' email addresses, which should be considered private and sensitive, especially since the login functionality relies on email-based authentication. As demonstrated earlier, these emails were directly accessible through server-to-client WebSocket messages.

Considering the nature of the application — a chat platform — many users tend to choose weak or simple passwords. This risk is further increased by the application's weak password policy, which only enforces a minimum password length of four characters, with no CAPTCHA, rate limiting, or brute-force protection mechanisms in place.

From a security perspective, this combination significantly lowers the attack cost and increases the likelihood of account compromise, highlighting the severity of the information disclosure issue.

At this point, I was almost ready to explore account compromise scenarios. But before going down that road, a shiny button called "Delete Account" caught my eye — and as every curious security researcher knows, shiny buttons deserve attention 😄.

I decided to test this functionality first.

While intercepting the Delete Account request, I discovered something… surprising. In a secure world, this request should depend on a session ID or an authentication token to confirm who is allowed to delete which account.

Instead, the application simply sent a DELETE request to the backend with a user-controlled ID parameter specifying the account to be deleted.

In other words, the backend politely trusted the client and said:

"Sure, just tell me which user you want to delete." 😈

This resulted in a classic IDOR vulnerability, allowing arbitrary account deletion without any ownership or authorization checks.

So, at this point, the only thing needed to fully confirm this vulnerability was a valid user ID. Normally, that would be a challenge — the user IDs were randomized, complex, and not guessable.

But… plot twist 🎬 We already had access to all user IDs through the update_users WebSocket message.

Armed with this "unexpected gift from the server," I replaced my own user ID with another valid one and sent the request again.

As shown above, the server responded indicating that this specific ID belonged to a guest user, and therefore could not be deleted.

Fair enough.

So, I changed the user ID to another one obtained from the WebSocket update_users message — this time selecting an account that had an email field (i.e., a real user).

I sent the request again… and boom 💥 The account was successfully deleted.

No additional verification. No authorization checks. No confirmation step.

Just a simple ID change — and one less user in the system.

🧾 Summary

This write-up demonstrated a high-severity vulnerability chain caused by combining WebSocket information disclosure with a classic IDOR flaw.

The application exposed sensitive user data — including user IDs and email addresses — through a server-to-client WebSocket message (update_users) sent to all connected clients without proper access control. These exposed user IDs were then directly trusted by a critical backend endpoint responsible for account deletion.

By simply replacing the user_id parameter in the DELETE /api/auth/account request, it was possible to delete arbitrary user accounts without any authentication, authorization, or verification checks.

In short:

• The WebSocket leaked the keys 🔑
• The backend accepted them without questions 🤝
• And user accounts disappeared accordingly 💥

This vulnerability allows unauthorized account deletion, resulting in potential data loss, service disruption, and severe impact on user trust