CVE-2026-105695 in Penpot
Summary
by MITRE • 10/06/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Penpot prior to version 2.18.0 represents a critical Insecure Direct Object Reference (IDOR) flaw within the file upload processing logic, specifically affecting how uploaded data chunks are assembled into final assets. As an open-source design and prototyping platform, Penpet relies on robust access controls to ensure that user-generated content remains isolated and secure. The core technical deficiency lies in a discrepancy between two distinct API endpoints: assemble-chunks and upload-chunk. While the upload-chunk endpoint correctly validates that the incoming data belongs to the authenticated profile of the current session, the subsequent assembly phase fails to perform this same verification. Instead, the assemble-chunks function retrieves an existing upload session solely based on its universally unique identifier (UUID), without cross-referencing it against the identity of the user initiating the request. This architectural oversight creates a situation where possession of a valid UUID is sufficient to manipulate the associated data, bypassing authentication and authorization checks entirely.
From an operational perspective, this flaw allows any authenticated user who can obtain another user's live or completed upload-session UUID to hijack that session's contents. By providing the victim's UUID to the assemble-chunks endpoint within their own context, an attacker can force the system to merge the victim's uploaded bytes into a file, team font, or project import owned by the attacker. This results in two significant adverse outcomes: unauthorized disclosure of sensitive data and potential denial of service for the victim. The disclosed information includes whatever files were being uploaded at the time, which could range from proprietary design assets to confidential documents depending on what was in transit during the attack window. Furthermore, because the assembly process consumes or finalizes the session state, it effectively deletes or invalidates the victim's pending upload session, disrupting their workflow and potentially causing data loss if they were relying on that specific transfer for critical project components.
This vulnerability aligns with CWE-284, which describes Improper Access Control, as well as CWE-601, URL Redirection to Untrusted Site (SSRF) in the context of object reference manipulation where the system trusts an input parameter without validating ownership. In terms of threat modeling and adversary tactics, this behavior is consistent with MITRE ATT&CK technique T1534, Internal Spearphishing, or more accurately T1078, Valid Accounts, as it exploits legitimate credentials to perform unauthorized actions against other users' resources. The attack vector requires the attacker to first discover a valid upload-session UUID belonging to another user, which may be achieved through network sniffing if traffic is not encrypted, via cross-site request forgery attacks that leak session identifiers, or by exploiting other information disclosure vulnerabilities within the platform's interface or API documentation.
To mitigate this risk, it is imperative for administrators and developers to ensure that all state-changing operations involving user-specific resources enforce strict ownership verification at every step of the process. The fix implemented in version 2.18.0 addresses this by ensuring that the assemble-chunks endpoint validates that the upload session being assembled belongs to the authenticated user making the request, mirroring the security checks already present in the upload-chunk logic. For organizations still running older versions, immediate upgrade is recommended as there are no effective workarounds other than restricting network access or implementing strict API rate limiting and monitoring for anomalous assembly patterns. Additionally, future development should adopt a principle of least privilege where every interaction with external identifiers requires explicit authorization checks against the current session's identity to prevent similar IDOR vulnerabilities in other parts of the application logic.