CVE-2026-105692 in Penpot
Summary
by MITRE • 10/06/2026
Penpot is an open-source design and prototyping platform. Prior to 2.18.0, the delete-share-link RPC retrieves a caller-selected share-link ID and verifies only that the caller can edit the parent file. It does not verify that the caller created the share link or has owner or administrator authority, allowing any file editor who knows a share-link UUID to delete links created by other users and revoke external reviewers' access. This issue is fixed in version 2.18.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Penpot versions prior to 2.18.0 represents a critical authorization flaw within the platform's remote procedure call (RPC) infrastructure, specifically affecting the delete-share-link functionality. As an open-source design and prototyping tool widely used for collaborative work, Penpet relies on granular access controls to manage file permissions and shared resources. The core technical deficiency lies in the server-side validation logic of the RPC endpoint responsible for removing share links. When a user initiates a request to delete a specific share link by providing its universally unique identifier (UUID), the system performs an authorization check that is insufficiently restrictive. Instead of verifying whether the requesting user has explicit ownership or administrative privileges over the target share link, the server only validates that the caller possesses edit permissions for the parent file containing the link. This architectural oversight creates a significant gap in access control enforcement, allowing any authenticated user with editor-level rights on a shared document to manipulate sharing configurations beyond their intended scope of authority.
From an operational perspective, this flaw enables unauthorized deletion of share links created by other users within the same project or workspace. In collaborative environments where multiple designers and stakeholders contribute to complex projects, it is common for different team members to generate distinct share links for various reviewers, clients, or internal review stages. An attacker with editor access can exploit this vulnerability by identifying a target share link UUID associated with another user's contribution and issuing a delete request. Because the system fails to verify that the requester created the specific link in question, the operation succeeds regardless of the original creator's identity. This results in the immediate revocation of external reviewers' access without their knowledge or consent, effectively disrupting ongoing workflows and potentially causing data exposure if alternative secure channels are not established promptly. The impact extends beyond mere inconvenience; it undermines trust in the platform’s security model and can lead to significant project delays or loss of critical feedback loops essential for design iteration cycles.
This vulnerability aligns with CWE-269, which classifies Improper Privilege Assignment, as well as CWE-862, Missing Authorization, since the application fails to enforce proper access control policies on a specific resource (the share link) despite having some level of authorization over the parent container. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior corresponds to techniques involving unauthorized API manipulation and privilege escalation through flawed object-level permissions. Attackers can leverage this flaw in scenarios where they have gained initial access with low-privilege editor accounts but seek to disrupt operations or escalate their influence by controlling the dissemination channels of sensitive design assets. The lack of verification regarding link ownership means that lateral movement within a project is facilitated, as any editor can neutralize another’s sharing efforts, potentially forcing reliance on less secure communication methods or causing confusion about which links remain active and valid for external parties.
Mitigation strategies primarily involve upgrading to Penpot version 2.18.0 or later, where the developers have addressed this authorization gap by implementing stricter validation checks that ensure only the creator of a share link, or users with explicit owner/administrator roles over the file, can delete it. For organizations unable to upgrade immediately due to dependency constraints, temporary mitigations include restricting editor permissions in shared projects to trusted individuals who do not need broad deletion rights and monitoring audit logs for unusual patterns of share link deletions initiated by non-owners. Additionally, implementing additional layers of authentication or approval workflows for critical sharing actions can provide defense-in-depth against such authorization bypasses. It is crucial for administrators to review their permission structures regularly to ensure that the principle of least privilege is strictly applied, preventing users from performing administrative functions like managing external access controls unless explicitly required by their role definition.