RubberDucky.codes

Session Tokens and Password Changes: A Reauthentication Gap in Filebrowser Quantum

CATEGORY: RESEARCH DATE: 2026-03-09

Research by badjuju - Red Orca

#appsec #authentication #session-security #defense-in-depth

Analysis of a password change flow that accepts a valid session token without requiring current-password reauthentication.

I was poking around Filebrowser Quantum and noticed something interesting in the account update flow.

If you have a valid session token, you can change the account password.

Let’s walk through it.

Where the Behavior Lives

Account updates are handled in userPutHandler inside http/users.go.

The logic is pretty straightforward:

  1. Validate the JWT session cookie
  2. Parse the fields being updated
  3. Apply the change

Password updates go through the exact same path as things like profile updates. There’s no additional verification step when "password" appears in the update payload.

So if the request has a valid session attached, the password gets updated.

The API payload looks like this:

{
  "which": ["password"],
  "data": {
    "password": "newpassword"
  }
}

That’s it. The session is treated as sufficient authorization.

Reproducing It

First grab a session token.

jwt=$(curl -s -X POST \
  -H "X-Password: password1" \
  "http://localhost/api/auth/login?username=user2" | tail -n 1)

Now use that session to change the password.

curl --path-as-is -X PUT \
  -H "Content-Type: application/json" \
  -H "Cookie: filebrowser_quantum_jwt=$jwt" \
  -d '{"which":["password"],"data":{"password":"pwned"}}' \
  "http://localhost/api/users?id=2"

The API happily updates the password. So let’s verify the old password:

curl -X POST \
  -H "X-Password: password1" \
  "http://localhost/api/auth/login?username=user2"

That correctly fails.And we try with the new password:

curl -X POST \
  -H "X-Password: pwned" \
  "http://localhost/api/auth/login?username=user2"

That works.

Session token -> password change -> done. No reauthentication needed.

Why This Matters

This isn’t an unauthenticated bug. You still need a valid session. But once someone has a session, they can immediately convert it into permanent account access. If an attacker grabs a session cookie, they don’t just get temporary access - they can lock the user out by rotating the password.

Session tokens leak in the real world all the time:

Requiring the current password forces attackers to have both the session and the credential.

Without that check, the session alone is enough.

Reauthentication Is Standard Practice

This isn’t exactly reinventing the wheel.

Major platforms like GitHub, Google, AWS, and Microsoft all require users to re-enter their password before performing sensitive account actions. Things like:

OWASP recommends the same pattern in:

The reason is simple: a session token alone shouldn’t be enough to permanently take over an account.

Responsible Disclosure

After confirming the behavior I reported it to the maintainer. They responded quickly and agreed the password change flow should require the current password. This wasn’t classified as a vulnerability requiring a CVE, but an issue was opened to track the improvement.

Password changes should require reauthentication.

A simple flow looks like this:

  1. User initiates password change
  2. Application prompts for the current password
  3. Current password is verified
  4. New password is accepted only if verification succeeds

Administrative password resets should stay separate so admins can still rotate credentials without knowing the existing password.

Closing Thoughts

This kind of finding sits in the gray zone between vulnerability and security hardening.

But it matters.

Session compromise is common. Designing sensitive operations to assume sessions can be stolen dramatically reduces the blast radius when it happens.

Authentication security doesn’t stop at login.

Sometimes the interesting bugs are hiding in what happens after.

About

badjuju focuses on application security and vulnerability research, digging into how bugs happen and where things break in real systems.

Related Posts