CVE-2026-100868

Penpot is an open-source design and prototyping platform. Prior to 2.18.0, the get-page RPC accepts a share-link permission object with blanket read access but does not verify that the caller-selected page-id belongs to the link's authorized pages set. An attacker with both a valid share link and the attacker's own authenticated Penpot session can retrieve the complete shape and design data of another page in the same file when its identifier is known, because get-page requires authentication. The related get-file-fragment RPC also permits share-link access without mapping fragments to authorized pages. This issue is fixed in version 2.18.0.

Penpot is an open-source design and prototyping platform. Prior to 2.18.0, assemble-chunks retrieves an upload session using only its session ID, while upload-chunk correctly scopes the lookup to the authenticated profile. An authenticated user who obtains another user's live, completed upload-session UUID can assemble the victim's chunks into the attacker's own file, team font, or project import, disclosing the uploaded bytes and deleting the victim's pending session. This issue is fixed in version 2.18.0.

Penpot is an open-source design and prototyping platform. Prior to 2.18.0, authenticated users with file-edit permission can upload SVG media whose scripts, event-handler attributes, and foreignObject elements are stored without sanitization and served as image/svg+xml from the Penpot origin. A victim who navigates to the asset URL executes attacker-controlled JavaScript in that origin, allowing requests and data access with the victim's Penpot session authority. This issue is fixed in version 2.18.0.

Penpot is an open-source design and prototyping platform. Prior to 2.18.0, the unauthenticated get-view-only-bundle RPC returns every share-link row for a file even when the caller authenticated with only one scoped share link. A holder of a restrictive link can obtain other links' secret IDs, page scopes, comment permissions, and inspection permissions, then replay a more permissive token to access page data that was not included in the original share. This issue is fixed in version 2.18.0.

In Penpot prior to 2.18.0, the delete-share-link RPC verifies only that the caller can edit the parent file, without checking whether the caller created the share link or has owner or administrator authority. Any file editor who knows a share-link UUID can delete links created by other users and revoke external reviewers' access.

In Penpot prior to 2.18.0, logout clears the browser's auth-token cookie without revoking the corresponding server-side session. A previously captured session token remains usable after the victim logs out and can continue to make authenticated requests with the victim's authority until natural expiration.

In Penpot prior to 2.18.0, app.util.ssrf/blocked-address? relies on Java InetAddress predicates that do not classify NAT64, 6to4, or Teredo addresses and applies additional CIDR checks only to IPv4 values. A user controlling a media import URL, or an administrator controlling a webhook URL, can supply an IPv6 transition address embedding a cloud-metadata, loopback, link-local, or private IPv4 target and bypass SSRF restrictions.

In Penpot prior to 2.18.0, create-team-invitations and the invitation acceptance path allow a non-owner team administrator to assign the owner role because invitation roles are persisted and applied without the role-ceiling check used by update-team-member-role. An administrator can invite another account as an owner, create multiple owners, and then use the new owner account to obtain owner-only control over the team.

In Penpot prior to 2.18.0, the delete-team-member RPC allows a team administrator to remove any member other than themselves but does not protect the team owner. A non-owner administrator can delete the owner's team-profile-rel membership and lock the owner out of the team and its projects, files, fonts, and media.

In Penpot prior to 2.18.0, the chunked media upload RPC validates that a chunk index is in range but neither rejects an already stored index nor replaces its previous object. An authenticated user can repeatedly upload the same valid index, causing each successful request to allocate another temporary object and increasing stored bytes beyond the upload session's declared logical size.