🧠 The "Wait, Really?" Moment

We've all forgotten our passwords before. The normal flow is:

"Forgot password?" → Email link → Reset → All good.

But what if someone else could reset your password without knowing your current one, and without any email confirmation?

That's exactly what I found.

I was poking around the account settings of a test account when I spotted a POST request that looked… suspiciously friendly.

🔍 The Endpoint

text

POST /ca/static/spa/eks/chwwy-account-ui/update-account-data?userId=121212121 HTTP/2
Host: www.rendom.com
Cookie: [session of User A]
Content-Type: application/json

And the payload?

json

{
  "newPassword": "Hacked123!",
  "currentPassword": ""
}

Notice anything missing?

Yeah. A valid currentPassword.

But I sent it anyway — just to see what happens.

💥 The Exploit (Step by Step)

Here's how easy it was to take over an account:

  1. Log into User A's account (assume session hijack via XSS, shared computer, or just a dev leaving a tab open — happens more than you'd think).
  2. Open Burp Suite and capture the password change request.
  3. Change the body to:
  4. json
  • { "newPassword": "Hacked123!", "currentPassword": "" }
  1. Forward the request.
  2. Server responds with HTTP 200 OK. No error. No "current password incorrect." Just… success.
  3. Log out.
  4. Log back in using:

✅ Login successful.

💀 The original password was never required. The victim is now locked out.

🤯 Why This Is Dangerous

Let me be blunt:

  • No current password check. None. Zero. Nada.
  • Empty currentPassword field was accepted without complaint.
  • No email notification to the victim.
  • No session invalidation after password change.
  • No re-authentication required.

An attacker with a stolen session token (from XSS, malware, or even a physical shared device) can permanently take over an account in one single request.

No phishing. No brute force. No OTP bypass needed. Just one POST.

📚 How This Should Work (But Didn't)

According to:

  • OWASP ASVS v4.0.3 Requirement 2.2.1
  • "Verify that users are required to authenticate with their current password before changing their password."
  • CWE-620: Unverified Password Change
  • The product does not require knowledge of the original password when setting a new password.

And real CVEs like:

  • CVE-2025–47938 (TYPO3 CMS)
  • CVE-2025–63800 (Open Source POS)
  • CVE-2025–1107 (CVSS 9.9)

…all describe the same flaw. This isn't new, but it's still surprisingly common — and always critical.

🛠️ How to Fix It (Dear Dev Team)

Please implement all of these:

✅ Validate current password — even if it's hashed, compare it before allowing a change.

✅ Reject empty or missing currentPassword with 401 Unauthorized.

✅ Send email notification to the user when password is changed.

✅ Invalidate all active sessions after password change.

✅ Log password changes and monitor for anomalies.

✅ Rate-limit password change attempts.

And while you're at it — consider requiring re-authentication (password + maybe OTP) for any sensitive account operation.

🧃 Final Thoughts

This wasn't a complex exploit. No chaining. No fancy techniques. Just a missing validation and a developer who maybe trusted the frontend too much.

Lesson: Never assume the client will validate the current password. Never skip server-side checks. And never — ever — trust an empty string sent by an attacker.

Stay sharp, test everything, and always question the "harmless" requests.

— Your friendly neighborhood bug hunter 🐞