☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 6.7 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H 🐛 CWE-269
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2026-105688

CVE-2026-105688 Privilege Escalation in Penpot
📅 PUBLISHED: 2026-10-05 00:00 UTC 🔄 UPDATED: 2026-10-07 05:00 UTC
[ ZERO-DAY / UNPATCHED ] [ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.26%
👁️
0.26% probability
6.6× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1098
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
VULNERABLE: < 2.18.0
CVSS VECTOR BREAKDOWN 6.7
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: H Privileges Required High
UI: N User Interaction None
S: U Scope Unchanged
C: L Confidentiality Low
I: H Integrity High
A: H Availability High
6.7
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2026-105688 is a privilege escalation vulnerability in Penpot, an open-source design and prototyping platform, affecting versions prior to 2.18.0. A non-owner team administrator can assign the owner role during team invitation creation and acceptance, because invitation roles are persisted and applied without the same role-ceiling check used by the team member role update path. Successful exploitation allows an administrator to manufacture additional owner accounts and leverage one of them to obtain owner-only control over the team, resulting in unauthorized privilege gain and potential full takeover of team resources.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

Penpot is a web-based, multi-tenant design and prototyping platform where teams, members, and roles form the core authorization model. In a correctly implemented role-based access control (RBAC) system, a privileged-but-non-owner administrator must be prevented from granting a role that exceeds their own privilege level — a concept commonly called a role ceiling or "no privilege escalation by delegation" check. The NVD description states that prior to version 2.18.0, the create-team-invitations flow and the invitation acceptance path allow a non-owner team administrator to assign the owner role. The root cause is that invitation roles are persisted to storage and applied at acceptance time without the role-ceiling validation that is applied in the update-team-member-role code path.

CWE-269 (Improper Privilege Management) accurately maps this issue. The defect is not a memory-safety or injection problem; it is a logic/authorization flaw. The platform correctly enforces a role ceiling when an administrator modifies an existing member's role through the dedicated update-team-member-role operation, but the invitation subsystem is a separate code path that omits the same guard. Because invitation data (including the requested role) is written to persistent storage and later materialized when the invitee accepts, the elevated role survives the gap in validation and becomes an actual, durable membership at the owner tier.

The attack surface is the authenticated administrative web interface and its backing API endpoints for team invitations. The privilege required is high (PR:H in the CVSS vector), meaning the actor must already hold a team administrator account. No user interaction is required on the victim side (UI:N) because the attacker controls both the invitation issuance and the acceptance using a second account they manage. The vector AV:N reflects that the flaw is reachable remotely over the platform's normal network interface. Impact subscores indicate limited confidentiality impact (C:L) but high integrity (I:H) and high availability (A:H) impact, consistent with an authorization bypass that lets an actor rewrite team membership and, through owner-only control, alter or remove team resources.

This is a privilege escalation and persistent account manipulation issue rather than a remote code execution flaw. Its severity derives from the trust boundary it crosses: the distinction between administrator and owner is the highest authorization boundary within a team, and the vulnerability eliminates it. Insufficient technical detail is available regarding the exact request parameters or internal function names; the analysis is therefore bounded to the vulnerability class (broken role ceiling on an invitation workflow) and the mechanism described by NVD.

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template is available for this CVE. The following attack chain is inferred strictly from the vulnerability class and the NVD description; no specific undocumented function names, parameters, or endpoints are asserted.

  1. Reconnaissance and target identification. The attacker identifies a Penpot deployment running a version prior to 2.18.0, for example by fingerprinting the instance or confirming the version through the platform's normal interfaces. The attacker requires an existing authenticated account that holds the non-owner team administrator role within the target team.

  2. Triggering the flaw class. Using the team invitation feature (create-team-invitations), the administrator issues an invitation that specifies the owner role. In a correctly guarded implementation this request would be rejected because the inviter's own role is below owner; here, the role-ceiling check that governs the update-team-member-role operation is absent from the invitation path, so the elevated role is accepted and persisted with the invitation record.

  3. Payload/execution method. The attacker accepts the invitation using a second account under their control. Because the stored invitation role is applied at acceptance without re-validating the ceiling, that account becomes a team owner. At the vulnerability-class level, the "payload" is simply a role value carried through an invitation lifecycle; no code injection, script payload, or crafted binary is involved. The attacker can repeat this to create multiple owner accounts.

  4. Post-exploitation impact. The attacker now holds one or more owner accounts. As NVD notes, the new owner account can be used to obtain owner-only control over the team. This grants the ability to perform owner-restricted actions on the team and its resources, including managing membership and controlling team-owned assets. The persistence of the elevated role means the privilege gain survives routine sessions until remediated.

Impact Assessment

The primary impact is an authorization boundary breach within a multi-tenant design platform. A team administrator — who should be subordinate to the owner — can escalate to owner and thereby seize full control of the team. Given the CVSS subscores (C:L, I:H, A:H), the most pronounced effects are integrity and availability: the attacker can modify or disrupt team configuration, membership, and resources under owner-only authority. Confidentiality impact is rated low, but any design assets or project data reachable through owner-level controls may still be exposed.

Blast radius is bounded to teams where the attacker already possesses an administrator account, which limits opportunistic mass exploitation but increases the risk in insider-threat and compromised-account scenarios. The ability to mint multiple owner accounts is operationally significant: it provides redundancy, complicates remediation (multiple rogue owners must be identified and removed), and can enable long-term persistence inside a victim organization's Penpot instance. Organizations using Penpot for collaborative design work — where team ownership may govern access to proprietary product designs and brand assets — should treat a successful escalation as a potential full disclosure of that team's design data.

Because the CVSS base score is 6.7 (Medium) with PR:H, the vulnerability is not a remote unauthenticated critical issue, but its placement on the owner boundary and its persistence make it a high-priority item for internal review in any deployment where the administrator-to-owner separation is a security requirement. There is no evidence of exploitation in the wild, and the CVE is not listed in CISA KEV.

Detection Guidance

Sigma Rule

title: Penpot Team Invitation Privilege Escalation to Owner Role
id: 8f3a1c2e-1056-88aa-9c00-penpotcve2026105688
status: experimental
description: Detects creation or acceptance of Penpot team invitations that assign the owner role, which may indicate exploitation of CVE-2026-105688 by a non-owner administrator.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-105688
author: valtersit.com
date: 2026/01/01
logsource:
  product: penpot
  service: application
detection:
  selection_event:
    event_type|contains:
      - 'team-invitation'
      - 'invitation-accept'
  selection_role:
    role|contains: 'owner'
  condition: selection_event and selection_role
falsepositives:
  - Legitimate owner accounts creating owner-level invitations
level: high
tags:
  - attack.t1098
  - cve.2026.105688

YARA Rule

rule Penpot_Team_Invitation_Owner_Escalation_CVE_2026_105688
{
    meta:
        author = "valtersit.com"
        description = "Detects Penpot invitation payloads or logs referencing owner-role team invitations tied to CVE-2026-105688"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-105688"
        date = "2026-01-01"
    strings:
        $s1 = "create-team-invitations" ascii nocase
        $s2 = "update-team-member-role" ascii nocase
        $s3 = "invitation" ascii nocase
        $s4 = "owner" ascii nocase
    condition:
        2 of ($s*) and filesize < 200KB
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-105688 Penpot Team Invitation Owner Role Escalation Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"team-invitations"; nocase; http.request_body; content:"owner"; nocase; classtype:attempted-admin; reference:cve,2026-105688; sid:2026105688; rev:1;)

Elastic Detection

sequence by user.name with maxspan=10m
  [ network where url.path : "*team-invitations*" and http.request.method : "POST" and http.request.body.text : "*owner*" ]
  [ network where url.path : "*invitation*" and http.request.method : "POST" ]

Splunk SPL Query

index=web OR index=penpot sourcetype=penpot:app
| search ("team-invitations" OR "invitation") AND ("owner")
| eval suspicious=if(match(_raw, "(?i)create-team-invitations|invitation.*owner"), 1, 0)
| where suspicious=1
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, user, url
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="penpot,cve-2026-105688,">
  <rule id="2026105" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">team-invitations|invitation</field>
    <field name="role">owner</field>
    <description>CVE-2026-105688: Penpot team invitation attempted with owner role - possible privilege escalation</description>
    <mitre>
      <id>T1098</id>
    </mitre>
    <group>privilege_escalation,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Per the NVD description, the issue is addressed in Penpot 2.18.0, but no vendor advisory, commit, or tracked patch source is available in the intelligence data provided, so the following guidance is precautionary and should be validated against authoritative vendor channels.

  1. Immediate mitigations (interim, no tracked workaround available):
  • Treat the administrator-to-owner boundary as untrusted until 2.18.0 can be validated. Restrict and audit team administrator assignments to a minimal, vetted set of users.
  • Monitor and alert on the create-team-invitations and invitation acceptance paths, especially any invitation carrying the owner role (see detection rules above).
  • Maintain an out-of-band record of legitimate team owners and reconcile it regularly; investigate any owner account not present in the approved list as a potential indicator of this escalation.
  • Where operationally feasible, temporarily constrain which accounts can issue invitations, reducing the opportunity to mint rogue owners.
  1. Patch/upgrade steps:
  • Upgrade Penpot to version 2.18.0 or later, where the description states the invitation path enforces the role ceiling applied by update-team-member-role.
  • Because patch confidence is 0/4 with no tracked source, independently verify the fix against the official Penpot release notes and repository before relying on it, and stage the upgrade in a non-production tenant first.
  1. Long-term hardening:
  • Enforce a consistent role-ceiling check across every code path that assigns or mutates roles, including invitation creation, invitation acceptance, and membership updates — treat role assignment as a single guarded operation.
  • Apply least privilege to team administrator assignments and require review/approval for owner grants.
  • Audit team membership periodically for orphaned or rogue owner accounts, and alert on the creation of new owners.
  • Instrument application logs to retain invitation lifecycle events (creation, role value, acceptance) for forensic correlation.

References

No public PoC, exploit code, or threat-actor campaign is associated with this CVE as of this report. Exploitation in the wild has not been observed, and the vulnerability is not present in CISA KEV.

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

product:"Penpot"
title:"Penpot"
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2026-105688/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.