Conversation
PUT /users/v1/{username}/password previously used the URL path
username directly to look up and overwrite a user's password,
allowing any authenticated user to hijack any other account by
supplying a different username in the URL while presenting their
own valid JWT.
Now the handler compares the URL username against the authenticated
caller's own subject (resp['sub']) taken from their validated token,
and returns 403 if they don't match, before any password update is
performed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
🏆 VAmPI — CTF Patch Score1 / 9 challenges patched
Commit: 🎉 Your result is on the leaderboard — see where you rank! 🏆 |
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Vulnerability
API1:2019 Broken Object Level Authorization.
PUT /users/v1/{username}/passwordused theusernamefrom the URL path directly to locate and overwrite the target account's password, without checking whether it matched the authenticated caller's own identity. Any authenticated user could send their own valid JWT while putting a different username in the URL and take over that account.Fix
In
api_views/users.pyupdate_password(), the vulnerable branch now compares the URLusernameagainst the caller's own subject (resp['sub']) taken from their validated JWT, returning HTTP 403 before performing any lookup/update if they differ.Testing (local, WSL, vulnerable=1)
name1, attemptedPUT /users/v1/name2/passwordwith name1's token -> now returns403with"You are not authorized to change the password of another user"instead of silently succeeding.name2can still log in with their original password afterward (account takeover prevented).name1can still change their own password viaPUT /users/v1/name1/passwordand log in with the new password (legitimate feature unaffected).🤖 Generated with Claude Code