Summary
Papermerge Core contains a missing authorization vulnerability in its shared-nodes API. An authenticated user may supply another user's document UUID and grant themselves access, potentially allowing the document to be read, modified, deleted, or have existing shares revoked.
Papermerge Core contains a missing authorization vulnerability in its shared-nodes API. An authenticated user may supply another user's document UUID and grant themselves access, potentially allowing the document to be read, modified, deleted, or have existing shares revoked.
Affected context
The issue occurs in Papermerge Core deployments where authenticated users can reach the shared-nodes endpoints and the API does not sufficiently verify ownership or sharing permissions for the supplied node UUID. Risk is highest when document identifiers are discoverable or obtainable and authorization is enforced only at the authentication boundary rather than for each requested resource.
The issue occurs in Papermerge Core deployments where authenticated users can reach the shared-nodes endpoints and the API does not sufficiently verify ownership or sharing permissions for the supplied node UUID. Risk is highest when document identifiers are discoverable or obtainable and authorization is enforced only at the authentication boundary rather than for each requested resource.
Exploit preconditions
- Attack surface: The shared-nodes API, including
POST /shared-nodesandPATCH /shared-nodes/access/{node_id} - Required access: A valid authenticated user account
- Trigger point: A request containing an arbitrary document or node UUID
- Why exploitation is possible: The API accepts the referenced node without adequately confirming that the requester owns it or is authorized to manage its sharing permissions
- Attack surface: The shared-nodes API, including
POST /shared-nodesandPATCH /shared-nodes/access/{node_id} - Required access: A valid authenticated user account
- Trigger point: A request containing an arbitrary document or node UUID
- Why exploitation is possible: The API accepts the referenced node without adequately confirming that the requester owns it or is authorized to manage its sharing permissions
Why this happens
The underlying flaw is an object-level authorization failure. The API authenticates the caller but does not consistently enforce a relationship between that caller and the referenced document before performing sharing or access-control operations. This maps to CWE-862: Missing Authorization, where a protected operation can be reached without an effective permission check for the requested resource.
The underlying flaw is an object-level authorization failure. The API authenticates the caller but does not consistently enforce a relationship between that caller and the referenced document before performing sharing or access-control operations. This maps to CWE-862: Missing Authorization, where a protected operation can be reached without an effective permission check for the requested resource.
Potential impact
- An attacker may gain access to documents owned by other users
- Sensitive document contents could be disclosed
- Documents may be modified or deleted without owner approval
- Existing sharing permissions could be revoked
- Unauthorized role assignments may enable further document actions
- An attacker may gain access to documents owned by other users
- Sensitive document contents could be disclosed
- Documents may be modified or deleted without owner approval
- Existing sharing permissions could be revoked
- Unauthorized role assignments may enable further document actions
General mitigation guidance
Mitigation generally focuses on enforcing resource-level authorization for every shared-node operation.
Common defensive patterns include:
- Checking document ownership or explicit management permission before creating or changing shares
- Applying deny-by-default authorization policies to all document operations
- Deriving the target resource from an authorized server-side relationship rather than trusting client-supplied identifiers alone
- Separating read, write, delete, and permission-management privileges
- Returning uniform responses that do not disclose whether unauthorized document identifiers exist
- Testing authorization decisions across users, roles, and document ownership boundaries
Mitigation generally focuses on enforcing resource-level authorization for every shared-node operation.
Common defensive patterns include:
- Checking document ownership or explicit management permission before creating or changing shares
- Applying deny-by-default authorization policies to all document operations
- Deriving the target resource from an authorized server-side relationship rather than trusting client-supplied identifiers alone
- Separating read, write, delete, and permission-management privileges
- Returning uniform responses that do not disclose whether unauthorized document identifiers exist
- Testing authorization decisions across users, roles, and document ownership boundaries
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and code review checks for handlers that use path or body identifiers without nearby authorization checks
- Review of every endpoint that accepts document, node, tenant, or account identifiers
- Authorization test matrices covering owners, collaborators, unrelated users, and revoked users
- API gateway or policy enforcement rules requiring resource-level permission evaluation
- Audit monitoring for unusual sharing changes, broad role grants, and access to documents outside a user's normal ownership scope
Organizations can identify similar issues through:
- Static analysis and code review checks for handlers that use path or body identifiers without nearby authorization checks
- Review of every endpoint that accepts document, node, tenant, or account identifiers
- Authorization test matrices covering owners, collaborators, unrelated users, and revoked users
- API gateway or policy enforcement rules requiring resource-level permission evaluation
- Audit monitoring for unusual sharing changes, broad role grants, and access to documents outside a user's normal ownership scope
