Two Session/Auth Bugs

Hello, In this writeup I’m going to talk about two authentication/session related bugs I found, one is a replay attack on a user creation endpoint due to missing server-side session validation, and the other is a stale session issue on a connected portal after a password change.

Target

let’s call our target example.com, along with its connected admin portal portal.example.com

Bug 1: Missing Server-Side Auth Validation on User Creation Endpoint Enables Replay Attack

i found that the endpoint

POST /api/v1/account/groups/xxxxx/users

does not validate whether the session token is still active at the time of the request
so even after logging out of the admin portal, previously captured API requests still work perfectly fine, the server accepts them, processes them, and creates new users as if the session were still valid
on top of that, there’s no rate limiting or authorization re-check on this endpoint, so the request can be replayed an unlimited number of times with arbitrary user data
basically, the backend is trusting the request data without checking:

• is this session token still active? (Authentication check)
• is this user still authorized to perform this action? (Authorization check)

  Attack Scenario

  1. log in to the admin portal and navigate to the add-user flow
  2. enable Burp Suite intercept and fill in all required fields to create a new user
  3. click submit, intercept the outgoing request in Burp and send it to Repeater
  4. drop the intercepted request (the user is never actually created via the browser)
  5. log out of the admin portal entirely
  6. in Burp Repeater, send the captured request, observe a 200 OK and a successful user creation response
  7. modify the required data fields and send again, a second user gets created, and this can be repeated indefinitely

     Impact

• an attacker who captures a single valid “add user” request can keep creating unlimited new users, even long after the original session has ended
• there’s no dependency on the session actually being active, meaning logging out or even session expiry does not stop this attack
• this breaks the fundamental trust between authentication state and privileged actions like user creation
  

Bug 2: Session Not Invalidated on portal.example.com After Password Change on example.com

i found that after changing a password on example.com, active sessions on the linked portal.example.com remain valid indefinitely
since the portal is connected to the main domain and shares the same credential store, this means an attacker who maintains a portal session can keep performing privileged actions, including resetting other users’ passwords, even after the victim changes their own password

Attack Scenario

1. log into example.com and portal.example.com with the same credentials
2. open an additional incognito tab and log into example.com
3. change the password from the example.com account settings
4. observe: example.com correctly logs out all tabs (expected behavior)
5. observe: the portal.example.com session remains active (vulnerable behavior)
6. confirm privileged portal actions can still be performed (e.g resetting other users’ passwords) using the stale session
7. after changing the password, logging out of portal.example.com and logging back in confirms the new password is enforced there too, proving both applications share the same credential store
   this confirms the session persistence on portal.example.com after a password change is a clear security gap

   Impact

   • an attacker with a previously valid portal session retains full administrative access even after the victim takes corrective action by changing their password