fix: prevent cross-organization password resets - #6111
Conversation
|
@shafeeq27edu-ai is attempting to deploy a commit to the agenta projects Team on Vercel. A member of the Team first needs to authorize it. |
|
✅ Thanks @shafeeq27edu-ai! This PR now meets the contribution requirements and has been reopened. A maintainer will review it soon. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Disabled knowledge base sources:
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe password reset flow now passes project scope to the service, validates organization membership, maps permission and missing-user errors to HTTP responses, and adds regression tests for these cases. ChangesPassword reset authorization
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant reset_user_password
participant generate_user_password_reset_link
participant ProjectAndUserData
Client->>reset_user_password: Request password reset
reset_user_password->>generate_user_password_reset_link: Pass user_id, admin_user_id, project_id
generate_user_password_reset_link->>ProjectAndUserData: Resolve project organization and target user
ProjectAndUserData-->>generate_user_password_reset_link: Return scope data or raise error
generate_user_password_reset_link-->>reset_user_password: Return reset link or exception
reset_user_password-->>Client: Return link, 403, or 404
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Fixed an authorization issue in the admin password reset flow where a user with the
RESET_PASSWORDpermission could potentially generate a password reset link for a user belonging to another organization.Root cause
The password reset endpoint verified that the requesting user had the
RESET_PASSWORDpermission, but the targetuser_idwas not validated against the requesting user's organization.The authorization check therefore verified the caller's permission without verifying whether the caller was authorized to act on the target user.
Fix
The password reset flow now:
403 Forbidden.The existing
RESET_PASSWORDpermission check remains unchanged.Additionally, the router now handles
NoResultFoundspecifically as404 Not Foundinstead of catching all exceptions and incorrectly converting unexpected failures into 404 responses.Unexpected exceptions continue through Agenta's normal error handling.
Testing
Verified locally
RESET_PASSWORDpermission check.ruff formatpassed.ruff checkpassed.The focused IDOR tests and existing access-control tests passed before the final exception-handling refinement.
A subsequent test rerun was blocked by a pre-existing local environment issue while building the
litellmdependency due to missing MSVClink.exe. This is unrelated to the changes in this PR.Added or updated tests
Added
test_reset_password_idor.pycovering:403 Forbidden404 Not FoundRESET_PASSWORDpermission →403 ForbiddenThe cross-organization test also verifies that password reset link generation is not reached for an unauthorized target.
QA follow-up
N/A
This is a backend authorization fix with unit-level regression coverage. No UI changes are included.
Demo
Before/after terminal demonstration of the password reset IDOR fix.
Before: The cross-organization password reset regression test fails because the vulnerable implementation returns
200instead of the expected403.After: The fixed implementation correctly returns
403for cross-organization resets, while authorized same-organization resets continue to work.The focused regression suite passes all 4 tests after the fix.
Checklist