Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-05T20:17:20.240Z",
  "pubdate": "2026-10-05T20:17:20.240Z",
  "executiveSummary": "A broken access control vulnerability exists in Penpot prior to version 2.18.0, stemming from improper authorization checks within the application's RPC mechanisms.\nThe vulnerability allows an authenticated attacker possessing a valid share link to access unauthorized design data within the same file.\nSpecifically, the get-page and get-file-fragment RPC functions fail to validate that a requested page or file fragment identifier belongs to the set of pages authorized by the provided share-link permission object.\nThis flaw enables unauthorized information disclosure, where an attacker can retrieve the complete shape and design metadata of private pages if their identifiers are known.\nThe risk is elevated because the exploitation requires only an authenticated Penpot session and a valid share link to any page within the target file.\nThe impact includes the potential exposure of proprietary design data, intellectual property, and sensitive prototyping information to unauthorized users.",
  "technicalDetails": "The vulnerability is rooted in an insecure implementation of server-side authorization logic within the Penpot RPC handlers, specifically get-page and get-file-fragment.\nWhen a user invokes the get-page RPC, the application accepts a share-link permission object intended to grant access to specific file content. However, the application fails to perform a rigorous mapping between the user-supplied page-id and the list of pages explicitly authorized by the provided share-link.\nBecause the get-page RPC mandates authentication, an attacker with a standard Penpot account can leverage their own authenticated session in conjunction with a legitimate share link. Even though the share link may have been intended for a restricted subset of a design file, the backend logic erroneously trusts the requested page-id without verifying its association with the access token's scope.\nThe attack flow proceeds as follows: First, the attacker acquires a valid share link for any page within a target file. Second, the attacker authenticates to their own Penpot account. Third, the attacker initiates a get-page RPC request, providing both their valid session credentials and the share-link permission object. By iterating or guessing known page identifiers within that file, the attacker bypasses the intended boundary, forcing the server to return the complete shape and design data for pages that should be inaccessible.\nA similar flaw exists in the get-file-fragment RPC, which also processes share-link access without validating that the requested file fragments map correctly to the authorized pages defined by the link. This allows for broader unauthorized data extraction.\nThe vulnerability exists in all Penpot versions prior to 2.18.0. The lack of strict ownership verification against the session-linked permissions constitutes a critical failure in the Principle of Least Privilege. Successful exploitation grants the attacker the ability to exfiltrate private design schemas, effectively bypassing file-level and page-level access restrictions imposed by the platform's security policy."
}