CVE-2026-105688 in Penpot
Summary
by MITRE • 10/06/2026
Penpot is an open-source design and prototyping platform. 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. This issue is fixed in version 2.18.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Penpot versions prior to 2.18.0 represents a critical privilege escalation flaw rooted in inconsistent access control enforcement within the platform's team management subsystem. As an open-source design and prototyping tool, Penpet relies on role-based access controls to maintain organizational integrity and data security. The core technical deficiency lies in the disparity between two distinct code paths: one for updating existing member roles and another for creating new invitations. While the update-team-member-role endpoint correctly implements a role-ceiling check that prevents administrators from assigning privileges higher than their own, this same validation logic was absent in the create-team-invitations flow and the subsequent invitation acceptance mechanism. This architectural inconsistency allows a non-owner team administrator to bypass standard privilege boundaries by inviting another account with owner-level permissions, effectively creating multiple owners within a single team structure.
From an operational perspective, this flaw enables a malicious actor or compromised user account to escalate privileges from a limited administrative role to full ownership of the team workspace. By exploiting the invitation acceptance path, an attacker can invite themselves or a co-conspirator as an owner without triggering the necessary authorization checks that would normally block such actions during direct role updates. Once the new owner account is established and accepts the invitation, it gains unrestricted control over the team resources. This includes the ability to modify critical settings, access sensitive design assets, manage other members arbitrarily, and potentially exfiltrate proprietary intellectual property or client data associated with the workspace. The impact extends beyond simple privilege escalation, as the attacker can leverage their new owner status to further compromise the broader security posture of the organization using Penpot for collaborative design work.
This vulnerability aligns closely with CWE-269, which describes Improper Privilege Management, specifically where an actor is able to elevate privileges due to a failure in enforcing role ceilings or hierarchical constraints. Furthermore, it maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as the attacker utilizes legitimate but misconfigured credentials and workflows to gain unauthorized elevated access within the system environment. The root cause is not necessarily a complex code injection or buffer overflow, but rather a logical error in security design where different API endpoints handle authorization checks inconsistently, allowing attackers to choose the path of least resistance for privilege escalation.
To mitigate this risk, organizations must immediately upgrade Penpot to version 2.18.0 or later, which includes patches that enforce consistent role-ceiling validation across all invitation and membership management workflows. Until an update is applied, administrators should strictly limit the number of users with administrative privileges and monitor for unusual patterns in team member additions, particularly those involving rapid creation of owner-level accounts by non-owner admins. Implementing additional monitoring alerts for changes to team ownership structures can also help detect exploitation attempts early. Security teams should review their access control policies to ensure that all endpoints handling role assignments undergo rigorous testing against privilege escalation scenarios during the software development lifecycle to prevent similar logical flaws in future releases.