Summary
A flaw in the permission management system allows a shared user to indirectly downgrade the original owner's access level to “view-only”, resulting in loss of control over their own note.
Affected Platform
https:
Vulnerability Type
Improper Access Control
Privilege Escalation / Authorization Logic Flaw
Description
The application fails to enforce proper ownership protection when permissions are reassigned through shared users.
An attacker (or shared collaborator) can re-share the note back to the original owner with reduced privileges (e.g., view-only), and the server incorrectly accepts this change — effectively overriding the owner’s permissions.
Steps to Reproduce
Create a note using account A (aligoodluck427@gmail.com).
Share the note with account B with “view and share” permissions.
Login to account B.
From account B, share the same note back to account A.
While sharing, set permission to “view-only”.
Observe that:
The server accepts the change.
The original owner (Account A) is now downgraded to view-only.
Impact
Original owner loses full control over their own content.
Owner cannot edit, manage permissions, or recover ownership.
Potential for account/data takeover-like scenarios.
Breaks core access control and trust model.
Proof of Concept
Affected Note:
https:
Expected Behavior
The original owner’s role should be immutable.
No user (including shared collaborators) should be able to modify or downgrade the owner's permissions.
Actual Behavior
Shared users can reassign permissions to the owner.
Server accepts unauthorized role downgrade.
Severity
High
Recommendation
Enforce strict ownership validation on the backend.
Prevent any permission changes affecting the original owner.
Validate role hierarchy before applying permission updates.