Summary
Penpot's ::import-binfile RPC command does not adequately authorize the optional file-id parameter. An authenticated user may therefore overwrite files they should not control and subscribe to related WebSocket events, potentially enabling data exfiltration and data poisoning.
Affected context
The vulnerability occurs in Penpot deployments where authenticated users can invoke the ::import-binfile RPC command and provide the optional file-id parameter. Risk is present when authorization is not checked against the referenced file and when WebSocket event subscriptions expose activity or data associated with files outside the user's permitted scope.
Exploit preconditions
- Attack surface: Penpot's authenticated RPC interface and related WebSocket event handling
- Required access: A valid authenticated user account capable of invoking the affected command
- Trigger point: Processing the optional
file-idparameter in::import-binfile - Why exploitation is possible: The server does not sufficiently verify that the authenticated user is authorized to modify or observe the referenced file
Why this happens
The underlying flaw is an authorization failure in which access control is not enforced for a user-supplied object identifier. The RPC handler accepts a file reference without consistently validating ownership, permission, or tenant scope before performing a write or allowing related event access. This behavior maps to CWE-862: Missing Authorization, because an authenticated identity is accepted without enforcing the permissions required for the requested resource.
Potential impact
- An attacker may overwrite files belonging to other users or projects.
- Sensitive file-related data may be exposed through WebSocket events.
- Project or design data could be poisoned, altered, or rendered unreliable.
- Other users may receive misleading or corrupted application state.
- Broader compromise could occur if overwritten content is trusted by downstream workflows.
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every resource access boundary, rather than relying solely on authentication or client-side restrictions.
Common defensive patterns include:
- Check ownership, role, project membership, and tenant scope for every supplied file identifier.
- Apply authorization immediately before file writes and WebSocket event subscriptions.
- Use deny-by-default policies for optional identifiers and resource references.
- Prefer server-derived resource scopes over trusting client-provided identifiers.
- Return consistent authorization failures without revealing whether unauthorized files exist.
- Separate read, write, and event-subscription permissions using least privilege.
- Add automated tests covering cross-user, cross-project, and cross-tenant resource access.
How teams detect issues like this
Organizations commonly identify missing-authorization risks through:
- Static analysis and code review rules that flag resource lookups using client-controlled identifiers without nearby authorization checks.
- Review of RPC handlers for authentication checks that are not followed by object-level authorization.
- Tests that attempt cross-user and cross-project file operations using valid accounts.
- Monitoring for unusual file overwrite activity, unexpected resource access, and broad WebSocket subscriptions.
- Policy enforcement requiring authorization tests for every resource-mutating endpoint and event channel.
Automated security review tools may help identify inconsistent authorization patterns, but findings should be validated against the application's resource model.
