Penpot CVE-2026-105688

Exploitation requires the attacker to already be an authenticated team member holding the 'administrator' role (not owner) on the target team, and to use the create-team-invitations RPC (either the emails+role or the invitations[] format) or the update-team-invitation-role path to assign role :owner. The limiting factor is this pre-existing administrator privilege within the specific team (PR:H) - it cannot be performed by anonymous or ordinary (editor/viewer) users, and it only affects versions prior to 2.18.0; no user interaction by a victim is needed beyond the attacker accepting their own crafted invitation. Owners are legitimately allowed to create owner invitations, so the condition is specifically a non-owner administrator acting on invitation roles.

This is a genuine but moderate-priority privilege-escalation flaw (CWE-269), best treated as a within-tenant integrity issue rather than an internet-facing emergency. The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N (6.7) is internally consistent with the description and the patch: PR:H correctly reflects that the attacker must already be an authenticated team administrator, AC:L reflects that no race or special timing is needed, and I:H/A:H capture the resulting owner-level takeover of the team. No EPSS score, SSVC decision, KEV listing, or POC was provided in the input; per precision rules this is 'no public exploit identified at time of analysis' and there is no evidence of active exploitation. The commit diff and dedicated regression tests (T7-F-01) confirm the root cause - invitation roles were persisted and applied without the role-ceiling check that update-team-member-role already enforced - so the vulnerability itself is well substantiated even though exploitation-probability signals are absent. Net: real and worth patching because the privilege boundary (admin→owner) is meaningfully violated, but the PR:H precondition means the attacker is already a semi-trusted insider, so this is not a mass-exploitable remote-takeover bug. Missing data to note: no EPSS and no SSVC inputs were supplied, so widespread-exploitation likelihood cannot be quantified from the provided intelligence.

A malicious or compromised account that already holds the team 'administrator' role (but not 'owner') sends a team invitation specifying the owner role, or updates a pending invitation's role to owner, which pre-2.18.0 is persisted and applied without any role-ceiling check. The attacker accepts the invitation on a second account to mint a new owner, then uses that owner account to seize owner-only control of the team. No public exploit code was identified, but the authoritative fix commit and regression tests make the exact exploitation path explicit.