Inconsistent Access Control After User Removal & Note Merge

linkResolution: ❌

Not a security vulnerability

Not considered for fix


linkReport

Note to Security Team
 
Hi Team,
 
I came across the following behavior during testing and wanted to responsibly report it. I’m not fully certain whether this qualifies as a security vulnerability or falls under best practice/design improvement.
 
If this issue meets your bug bounty criteria, I’d appreciate you considering it for a reward. Otherwise, please treat this as a best practice recommendation to improve access control and data integrity.
 
Thank you for your time and review.
 
Summary
 
Two related issues in note sharing and merging lead to loss of owner control, orphaned access, and inconsistent permission states. These behaviors may result in unintended data exposure and administrative lockout.
 
Issue 1 Orphaned Access After Intermediate User Removal
Description
When a note is shared across multiple users in a chain, removing an intermediate user does not properly update downstream permissions.
 
Steps to Reproduce
User-A (Owner) creates a note.
 
Share note with User-B.
 
User-B shares with User-C.
 
User-C shares with User-D.
 
User-A removes User-B from collaborators.
 
Observe:
 
User-C and User-D still retain access.
 
Owner (User-A) cannot:
 
Modify their roles
 
Remove them
 
Fully control access to their own note
 
Impact
Owner loses control over access management.
 
Unauthorized users may retain access indefinitely.
 
Violates expected access hierarchy.
 
Creates orphaned permissions that cannot be managed.
 
Expected Behavior
Removing an intermediate user should:
 
Either remove downstream shared users
 
Or reassign ownership/control properly
 
Owner should always retain full control over all collaborators.
 
Actual Behavior
Downstream users retain access.
 
Owner cannot manage or revoke their permissions.
 
Issue 2 Access Loss & Data Inconsistency After Note Merge
Description
Merging two notes with different sharing states results in loss of ownership access and inconsistent permission propagation.
 
Steps to Reproduce
User-A creates:
 
Note-A (shared with 3 users)
 
Note-B (not shared with anyone)
 
From Note-B, perform a merge with Note-A.
 
Observe:
 
Note content from A is merged into B.
 
User-A (Owner) loses access to the merged note.
 
The note disappears from User-A’s dashboard.
 
Previously shared users (from Note-A) may still retain access to old/shared context.
 
Impact
Owner loses access to their own data.
 
Shared users retain access while the owner does not.
 
Data ownership becomes inconsistent.
 
High risk of data loss / unauthorized persistence.
 
Expected Behavior
During merge:
 
System should warn:
“Merging will transfer data and permissions.
 
Permissions from both notes should be merged or normalized.
 
Owner must never lose access.
 
Actual Behavior
Ownership is broken.
 
Permissions are not merged or validated.
 
Access becomes inconsistent across users.
 
 
Recommendation
Enforce strict ownership guarantees (owner can never lose access).
 
Recalculate permissions after:
 
User removal
 
Note merge operations
 
Maintain a single source of truth for collaborator hierarchy.
 
Add user warnings/confirmation dialogs before merge actions.
 
Ensure downstream shared users are properly handled when upstream users are removed.
 
Note to Security Team
This may fall under best practice / design issue, but it has clear implications for:
 
Access control integrity
 
Data ownership consistency
 
Kindly review and confirm whether this qualifies for bounty consideration.