Penpot CVE-2026-105692

Requires an authenticated account that has editor (edit) permission on the specific target file - typically a team member with the :editor role - so it cannot be exploited by anonymous or view-only users. The attacker must also know (or discover) the UUID of a share-link; file editors can obtain these IDs from the file's view-only bundle, which lists existing share-links. It affects the default behavior of the standard share-link feature, so no special or non-default configuration is needed. Limiting factors: attacker must be an existing collaborator with edit rights (not external/anonymous), impact is confined to deleting share-links and revoking external reviewer access, and there is no confidentiality loss or code execution. Fixed in 2.18.0, which adds an owner-or-admin check.

This is a medium-severity (CVSS 5.4) broken-access-control / IDOR issue, and the real-world urgency is modest rather than critical. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) shows that although the attack is network-reachable, it is NOT unauthenticated: PR:L means the attacker must already hold editor permission on the target file, so the realistic threat actor is an existing team collaborator/insider rather than an anonymous internet attacker. No EPSS score was provided in the input, there is no CISA KEV listing, and no standalone public exploit was identified - so none of the 'high exploitation probability' signals are present. The impact is deliberately narrow (C:N, I:L, A:L): the flaw only allows deleting share-links created by others and revoking external reviewers' access, not data theft or code execution. Signals are internally consistent - a network-facing RPC that nonetheless requires authenticated edit rights - so there is no CVSS-vs-description conflict to flag. Bottom line: a legitimate authorization defect worth patching on a normal cycle, but not a drop-everything emergency; treat it as an insider/collaborator abuse risk, not mass exploitation.

An authenticated user who has been granted editor rights on a Penpot file (for example a contractor or team member) obtains the UUID of a share-link another user created and calls the delete-share-link RPC with it. Because the server only checked that the caller could edit the parent file, the link is deleted and the external reviewer who relied on it loses access. No public exploit tool is needed and no user interaction is required; the share-link IDs are discoverable to file editors via the file's view-only bundle.