CVE-2026-105686 in Penpot
Summary
by MITRE • 10/06/2026
Penpot is an open-source design and prototyping platform. 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. Assembly detects the inconsistent chunk count only after allocation. 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 versions prior to 2.18.0 represents a significant resource exhaustion flaw rooted in improper validation of input data during media upload operations. As an open-source design and prototyping platform, Penpet handles substantial amounts of binary data through its remote procedure call interface. The specific technical flaw lies within the chunked media upload mechanism, which is designed to handle large files by breaking them into smaller segments for efficient transmission and processing. While the system correctly validates that a provided chunk index falls within an acceptable numerical range, it fails to implement stateful tracking of previously received chunks with identical indices. This oversight allows an authenticated user to exploit the logic by repeatedly submitting requests containing valid but duplicate chunk indexes. Instead of rejecting these redundant submissions or overwriting existing data structures associated with those indexes, the server allocates new temporary objects for each incoming request that passes the basic range check.
This lack of deduplication leads directly to a severe impact on system stability and resource availability. Each successful upload of a duplicate index triggers additional memory allocation without corresponding progress toward completing the logical file structure. Consequently, the total amount of stored bytes can rapidly exceed the declared size of the upload session as defined by the client metadata. The server-side assembly process only detects this inconsistency in chunk count after the allocations have already occurred and consumed system resources. This delay means that an attacker can trigger a denial-of-service condition not through immediate crash or error, but through gradual resource depletion. By continuously sending these malformed requests, an authenticated user can exhaust available memory on the server, potentially rendering the application unresponsive to legitimate users or causing service interruptions until manual intervention clears the allocated resources.
From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as well as CWE-770, Allocation of Resources Without Limits or Throttling. The attack vector leverages authenticated access to manipulate server-side state inappropriately, fitting into the MITRE ATT&CK framework under techniques related to resource exhaustion and potentially service disruption within cloud infrastructure environments. Such flaws are particularly dangerous because they require authentication, which may be perceived as a lower risk by some administrators, yet they can still cause significant operational downtime and financial loss due to lost productivity or emergency remediation efforts.
Mitigation for this issue involves upgrading the Penpot instance to version 2.18.0 or later, where the developers have addressed the logic flaw by ensuring that duplicate chunk indices are either rejected outright or properly handled without allocating additional temporary objects. In environments where immediate patching is not feasible, administrators should implement strict rate limiting on media upload endpoints to prevent rapid successive requests from a single source. Additionally, configuring web application firewalls to monitor for anomalous patterns in request sizes and frequencies can help detect and block such exploitation attempts before they consume critical system resources. Regular auditing of server memory usage during high-load periods can also provide early warning signs of similar resource exhaustion vulnerabilities across the platform.