CVE-2026-47665: stored XSS — HIGH

CISO Take

Penpot, an open-source design and prototyping platform, renders file-comment text into the page via innerHTML with no sanitization beyond a backend length check, so any team member able to comment on a shared file can plant HTML like an image error handler or inline script. The attack is passive — no click required beyond simply opening the comments panel — and executes on the Penpot origin, meaning session cookie theft, actions performed as the victim, and access to the victim's files and projects are all in scope, with CVSS 8.7 (scope-changed, high confidentiality and integrity impact). There is no evidence of active exploitation (not in CISA KEV), no public exploit code, and no Nuclei scanner template as of this writing, and EPSS data is not available, so treat this as a credible-but-unconfirmed threat rather than an imminent one. This is a generic web-application stored XSS rather than an attack against an AI model, pipeline, or agent — its relevance to AI/ML teams is only that Penpot is commonly used to prototype AI-product UIs and could expose sensitive design work if compromised. Patch to Penpot 2.15.3 or later immediately on any self-hosted instance, and in the meantime disable or restrict the comments feature and audit recent comment content for embedded HTML/script payloads.

Sources:NVDGitHub Advisory

What is the risk?

High severity (CVSS 8.7) on paper due to the scope change (S:C) and full confidentiality/integrity impact, but real-world risk is currently moderate: exploitation requires an attacker to already hold at least commenter-level access to a shared file (PR:L) and requires the victim to open the comments panel (UI:R), which narrows the practical attack surface to insider threats, compromised low-privilege accounts, or social-engineered file sharing. No KEV listing, no public PoC/exploit, and no automated scanner coverage were found, so this is not yet being mass-exploited. Because Penpot is a collaborative, multi-tenant SaaS/self-hosted tool, a single malicious comment can passively compromise every collaborator who views it, giving it high blast-radius potential inside an organization or agency-client workspace despite the access precondition.

How does the attack unfold?

Initial Access

Attacker obtains commenter-level access to a shared Penpot file, either as an insider, a compromised low-privilege account, or an invited external collaborator.

Payload Delivery

Attacker posts a file comment containing raw HTML/script (e.g., an image error handler), which the backend accepts after only a length check.

Exploitation

A victim opens the comments panel on the affected file; the frontend renders the stored comment via innerHTML without sanitization, executing the attacker's script in the victim's browser on the Penpot origin.

Impact

The script steals the victim's session cookie, allowing the attacker to act as the victim, access their files and projects, and pivot to other shared workspaces.

Initial Access

Attacker obtains commenter-level access to a shared Penpot file, either as an insider, a compromised low-privilege account, or an invited external collaborator.

Payload Delivery

Attacker posts a file comment containing raw HTML/script (e.g., an image error handler), which the backend accepts after only a length check.

Exploitation

A victim opens the comments panel on the affected file; the frontend renders the stored comment via innerHTML without sanitization, executing the attacker's script in the victim's browser on the Penpot origin.

Impact

The script steals the victim's session cookie, allowing the attacker to act as the victim, access their files and projects, and pivot to other shared workspaces.

How severe is it?

CVSS 3.1

8.7 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 39% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRLow

UIRequired

SChanged

CHigh

IHigh

ANone

What should I do?

1 step

Upgrade self-hosted Penpot instances to version 2.15.3 or later, where the fix (commit 29f940f) sanitizes comment content before rendering. Until patched, restrict comment permissions on shared files to trusted collaborators only, or disable the comments panel/feature entirely for externally shared projects. Detection: review recent file comments for HTML-like payloads (e.g., <img onerror=, <script>, event-handler attributes) and rotate session tokens for any account that viewed a suspicious comment. Post-patch, verify via the GitHub Security Advisory (GHSA-vc72-6r45-q988) that the fixed version is running and that comment content is escaped, not just length-limited.

What does CISA's SSVC say?

DecisionAttend

Exploitationpoc

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionData LeakageFramework

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.6-Third-party and supplier relationships

Frequently Asked Questions

What is CVE-2026-47665?

Penpot, an open-source design and prototyping platform, renders file-comment text into the page via innerHTML with no sanitization beyond a backend length check, so any team member able to comment on a shared file can plant HTML like an image error handler or inline script. The attack is passive — no click required beyond simply opening the comments panel — and executes on the Penpot origin, meaning session cookie theft, actions performed as the victim, and access to the victim's files and projects are all in scope, with CVSS 8.7 (scope-changed, high confidentiality and integrity impact). There is no evidence of active exploitation (not in CISA KEV), no public exploit code, and no Nuclei scanner template as of this writing, and EPSS data is not available, so treat this as a credible-but-unconfirmed threat rather than an imminent one. This is a generic web-application stored XSS rather than an attack against an AI model, pipeline, or agent — its relevance to AI/ML teams is only that Penpot is commonly used to prototype AI-product UIs and could expose sensitive design work if compromised. Patch to Penpot 2.15.3 or later immediately on any self-hosted instance, and in the meantime disable or restrict the comments feature and audit recent comment content for embedded HTML/script payloads.

Is CVE-2026-47665 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-47665, increasing the risk of exploitation.

How to fix CVE-2026-47665?

Upgrade self-hosted Penpot instances to version 2.15.3 or later, where the fix (commit 29f940f) sanitizes comment content before rendering. Until patched, restrict comment permissions on shared files to trusted collaborators only, or disable the comments panel/feature entirely for externally shared projects. Detection: review recent file comments for HTML-like payloads (e.g., `<img onerror=`, `<script>`, event-handler attributes) and rotate session tokens for any account that viewed a suspicious comment. Post-patch, verify via the GitHub Security Advisory (GHSA-vc72-6r45-q988) that the fixed version is running and that comment content is escaped, not just length-limited.

What systems are affected by CVE-2026-47665?

This vulnerability affects the following AI/ML architecture patterns: ml_ui / design-and-prototyping collaboration tooling.

What is the CVSS score for CVE-2026-47665?

CVE-2026-47665 has a CVSS v3.1 base score of 8.7 (HIGH). The EPSS exploitation probability is 0.45%.

What is the AI security impact?

Affected AI Architectures

ml_ui / design-and-prototyping collaboration tooling

Compliance Controls Affected

ISO 42001: A.6.2.6

What are the technical details?

Original Advisory

Penpot is an open-source design and prototyping platform. In versions up to and including 2.14.3, Penpot is vulnerable to stored cross-site scripting through file comments, whose content is stored as raw text and rendered into the page with innerHTML without any sanitization. Because the backend applies only a length check and the frontend writes comment content directly through innerHTML, any team member who can comment on a shared file can embed HTML such as an image error handler or script that executes in the browser of every other collaborator. The attack is passive: any user who opens the comments panel on the affected file triggers script execution on the Penpot origin, allowing theft of session cookies, actions performed as the victim, and access to their files and projects. This issue is fixed in version 2.15.3.

Exploitation Scenario

An attacker gains commenter access to a shared Penpot file — either as a malicious insider, via a compromised low-privilege team member account, or by being invited into a project as an external collaborator/client. They post a comment containing an HTML payload, such as an `<img src=x onerror=...>` tag or inline script, which is stored as raw text server-side (only length-checked). When any other collaborator — including a project admin — opens the comments panel on that file, the frontend renders the payload via innerHTML and the script executes in their browser under the Penpot origin, silently exfiltrating their session cookie to an attacker-controlled endpoint. The attacker then replays that session to impersonate the victim, browse and exfiltrate their private files and projects, and potentially pivot to other shared workspaces the victim has access to.

Weaknesses (CWE)

CWE-79Improper Neutralization of Input During Web Page GenerationPrimary CWE-79Improper Neutralization of Input During Web Page Generation

CWE-79 — Improper Neutralization of Input During Web Page Generation: The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.