CVE-2026-105688: Penpot Privilege Escalation Vulnerability

CVE-2026-105688 Overview

Penpot, an open-source design and prototyping platform, contains a privilege escalation flaw in versions prior to 2.18.0. The create-team-invitations command and the invitation acceptance path persist and apply invitation roles without enforcing the role-ceiling check used by update-team-member-role. A team administrator who is not an owner can invite another account with the owner role, create multiple owners, and then pivot through the newly minted owner account to gain full control of the team. The flaw is classified under CWE-269: Improper Privilege Management and is fixed in Penpot 2.18.0.

Critical Impact
An authenticated non-owner administrator can escalate to team owner, bypassing owner-only governance controls over team membership, billing, and project ownership.

Affected Products

Penpot versions prior to 2.18.0
Self-hosted Penpot deployments running vulnerable backend builds
Penpot SaaS instances before the 2.18.0 rollout

Discovery Timeline

2026-10-05 - CVE-2026-105688 published to NVD
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-105688

Vulnerability Analysis

Penpot's team role model distinguishes owners from administrators. Owners hold exclusive authority to assign the owner role, enforced in the update-team-member-role command through a role-ceiling check. The invitation workflow in backend/src/app/rpc/commands/teams_invitations.clj did not apply that same check. When an administrator issued an invitation with :role :owner, the backend persisted the requested role on the invitation record and later honored it during acceptance.

The outcome is a horizontal-to-vertical privilege escalation inside the team authorization model. An administrator can promote arbitrary accounts, including accounts they control, to the owner role. Once multiple owner accounts exist, owner-only operations such as deleting the team, transferring ownership, and modifying billing become accessible to the attacker. Exploitation requires an authenticated administrator session and network access to the Penpot RPC endpoints.

Root Cause

The root cause is missing authorization enforcement on a sensitive input field. The invitation creation and acceptance paths trusted the role value supplied by the caller without verifying the caller's is-owner permission. The role-ceiling validation existed only in the direct role-update command, leaving the invitation path as an unchecked side channel to the same privileged state change.

Attack Vector

An authenticated team administrator submits a create-team-invitations request with :role :owner for one or more target email addresses. The invitation is stored with the elevated role. When the invitee accepts, the backend assigns the owner role without consulting the inviter's permissions. The attacker may invite an account under their control to directly obtain owner privileges on the targeted team.

text

                 :code :insufficient-permissions
                 :hint "Organization policy does not allow you to send invitations"))

+    ;; Don't allow promote to owner to admin users.
+    (when (and (not (:is-owner perms))
+               (or (= role :owner)
+                   (some #(= :owner (:role %)) (:invitations params))))
+      (ex/raise :type :validation
+                :code :cant-promote-to-owner))
+
     (when (> invitation-count max-invitations-by-request-threshold)
       (ex/raise :type :validation
                 :code :max-invitations-by-request

Source: Penpot commit 5efd9cc. The patch introduces an explicit :cant-promote-to-owner validation that rejects owner-role invitations submitted by non-owner callers.

Detection Methods for CVE-2026-105688

Indicators of Compromise

Team invitation records in the Penpot database containing role = 'owner' where the inviting user does not hold the owner role.
Unexpected increases in the count of owner-role members on a given team.
Acceptance of invitations by newly created or external accounts that immediately receive owner privileges.

Detection Strategies

Query the team_invitation table for historical rows where role = 'owner' and cross-reference the inviter's role at the time of invitation.
Audit the team_profile_rel table for teams that have transitioned from a single owner to multiple owners, especially within short time windows.
Review Penpot application logs for create-team-invitations RPC calls that specify the owner role.

Monitoring Recommendations

Alert on any RPC call to create-team-invitations carrying an owner role parameter.
Track changes to team ownership counts and flag teams that exceed a baseline of one owner.
Forward Penpot backend logs to a centralized logging or SIEM platform and build detections for invitation-driven role changes.

How to Mitigate CVE-2026-105688

Immediate Actions Required

Upgrade all Penpot deployments to version 2.18.0 or later.
Review existing team ownership assignments and revert unauthorized owner promotions.
Revoke pending invitations that specify the owner role and were issued by non-owner administrators.

Patch Information

The fix is available in Penpot 2.18.0 and documented in GHSA-mx4v-cmxq-644v. The patch adds a role-ceiling check to the invitation creation path in teams_invitations.clj, raising a :cant-promote-to-owner validation error when a non-owner attempts to issue an owner-role invitation.

Workarounds

Restrict the administrator role to trusted operators until the upgrade to 2.18.0 is completed.
Enforce manual review of team ownership changes through out-of-band change management.
Place the Penpot backend behind a reverse proxy that blocks create-team-invitations payloads containing "role":"owner" from non-owner sessions.

bash

# Verify Penpot backend version after upgrade
docker exec penpot-backend cat /opt/penpot/backend/version.txt

# Identify owner-role invitations in the database for review
psql -U penpot -d penpot -c "SELECT id, team_id, email, role, created_at \
  FROM team_invitation WHERE role = 'owner' ORDER BY created_at DESC;"