Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain authenticated Penpot user or admin access
-
DeliveryCraft NAT64/6to4/Teredo IPv6 URL embedding 169.254.169.254 or internal IPv4
-
ExploitSubmit as media-import or webhook URL
-
ExecutionServer routes request via NAT64 gateway bypassing IPv4-only SSRF filter
-
ImpactExfiltrate cloud-metadata/internal response body or probe via response status
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires (1) the attacker to route the request through a NAT64 gateway or control a DNS AAAA record the Penpot server will resolve, and (2) authenticated control of a media-import URL (any user) or a webhook URL (administrator). The attacker then supplies an IPv6 transition address - NAT64 64:ff9b::/96, 6to4 2002::/16, or Teredo 2001:0000::/32 - that embeds a blocked IPv4 target (cloud metadata 169.254.169.254, loopback 127.0.0.1, link-local, or RFC1918 private ranges) to defeat the IPv4-only CIDR filtering in app.util.ssrf/blocked-address?. Limiting factors: cloud environments with an existing NAT64 gateway are directly exploitable, but non-NAT64 deployments require the harder attacker-controlled AAAA-record path; the webhook sink only yields a status-code side channel (not response bodies); and only versions prior to 2.18.0 are affected. |
| Impact | This is a genuine but conditional SSRF (CWE-918), best characterized as a real-but-moderate priority rather than a drop-everything emergency. The vendor CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N, score 6.0 MEDIUM) is internally consistent with the description: network-reachable, but with both high attack complexity (AC:H) and a present attack requirement (AT:P) reflecting the need for a NAT64 gateway or attacker-controlled DNS AAAA record, plus low privileges (PR:L) since the actor must be an authenticated user controlling a media-import URL or an administrator controlling a webhook URL. No EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be quantified. The CVE is NOT in CISA KEV and no public exploit code was supplied in the intelligence; therefore this is 'no public exploit identified at time of analysis.' Note a meaningful environmental dependency the raw score understates in one direction and overstates in another: in cloud environments that already run NAT64 gateways the AT:P/AC:H barriers largely collapse and the flaw becomes 'directly exploitable' per the description, whereas in on-prem/non-NAT64 environments exploitation requires an attacker-controlled AAAA record and is materially harder. The confidentiality impact is asymmetric by sink: media import can disclose full response bodies (high confidentiality) while webhook delivery only leaks response status as a network-probing side channel. Net: prioritize patching for cloud-hosted Penpot instances with NAT64; lower urgency for isolated self-hosted deployments. |
| Exploit ScenarioDerived | An authenticated Penpot user (or administrator for the webhook path) submits a media-import or webhook URL containing an IPv6 transition address such as http://[64:ff9b::a9fe:a9fe]/latest/meta-data/, which embeds the 169.254.169.254 cloud-metadata IPv4 target. Because the pre-2.18.0 blocklist only applies CIDR checks to IPv4 and never classifies NAT64/6to4/Teredo, the server resolves and fetches the internal target through a NAT64 gateway, returning cloud-metadata or internal response bodies to the attacker. No public exploit code was identified at time of analysis, though the vendor's regression tests demonstrate the exact bypass payloads. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
Server-side request forgery in Penpot before 2.18.0 allows an authenticated user who controls a media-import URL, or an administrator who controls a webhook URL, to reach internal and cloud-metadata endpoints by supplying IPv6 transition addresses (NAT64 64:ff9b::/96, 6to4 2002::/16, or Teredo 2001:0000::/32) that embed a blocked IPv4 destination such as 169.254.169.254, 127.0.0.1, link-local, or RFC1918 addresses. The bypass works because the backend blocklist app.util.ssrf/blocked-address? applies its extra CIDR checks only to IPv4 values and relies on Java InetAddress predicates that do not classify transition-mechanism addresses; exploitation further requires the request to traverse a NAT64 gateway or the attacker to control a DNS AAAA record the Penpot server resolves, with cloud environments that already run DNS64/NAT64 directly exploitable, while non-NAT64 deployments depend on the harder attacker-controlled AAAA path. Media import can disclose response bodies, whereas webhook delivery exposes only response status as a network-probing side channel, and there is no public exploit identified at time of analysis. Penpot 2.18.0 is the vendor-released fix (commit 326d83e780ae120b45ccd6f3d7bd24922b54461c).
RemediationAI
Upgrade Penpot to 2.18.0 or later, the vendor-released patch version, which introduces the transition-prefix classification in app.util.ssrf/blocked-address? and rejects NAT64 64:ff9b::/96, 6to4 2002::/16 and Teredo 2001:0000::/32 hosts outright; the fix is documented in advisory GHSA-wxgm-8qjw-x445 and in commit 326d83e780ae120b45ccd6f3d7bd24922b54461c on the 2.18.0 release. If immediate upgrade is not possible, apply compensating controls with awareness of their trade-offs: disable or tightly allowlist the media-import-by-URL feature and the administrator webhook URL field in Penpot so no user-supplied hostname is fetched at all (this removes legitimate import and integration workflows and is the most effective short-term mitigation), or restrict those features to a curated set of trusted domains; on the network side, block backend egress to the transition prefixes 64:ff9b::/96, 2002::/16 and 2001:0000::/32 and deny access to 169.254.169.254 and RFC1918 ranges from the Penpot pod or host (this also breaks any legitimate NAT64-based IPv6-only egress), and where a NAT64/DNS64 gateway exists, consider disabling it for the segment hosting Penpot or filtering DNS64 synthesis so AAAA records embedding private IPv4 targets are not returned. Finally, apply IMDSv2 or equivalent metadata hardening on the underlying cloud instance, since that blocks the highest-value target of this SSRF even if the transition-address filter is bypassed again.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The issue is a classic CWE-918 server-side request forgery rooted in incomplete IPv6 handling inside Penpot's Clojure backend validation module backend/src/app/util/ssrf.clj. The affected function blocked-address? combines Java InetAddress predicates (which already cover loopback, link-local, site-local, multicast and similar standard classifications) with extra operator-supplied CIDR checks, but those additional CIDR ranges were applied only when the parsed value was IPv4. IPv6 transition mechanisms were therefore never inspected: NAT64 (64:ff9b::/96), 6to4 (2002::/16) and Teredo (2001:0000::/32) addresses carry an embedded IPv4 address, so an attacker can write an IPv6 literal whose payload is 169.254.169.254, 127.0.0.1, or a private range and have it pass validation; a NAT64 gateway or an attacker-controlled AAAA record then converts or routes the request to the embedded IPv4 target. The fix adds a transition-prefix helper that examines the first four bytes of a 16-byte address and classifies it as :nat64, :6to4 or :teredo, rejecting any URL whose host falls into those ranges regardless of what IPv4 address is embedded, and the accompanying tests assert rejection of 64:ff9b::a9fe:a9fe (metadata), 64:ff9b::7f00:1 (loopback), 2002:a00:1:: / 2002:c0a8:101:: (RFC1918) and 2001:0000:4136:e378:8000:63bf:3fff:fdd2 (Teredo). The CPE string cpe:2.3:a:penpot:penpot:*:*:*:*:*:*:*:* confirms that every Penpot release prior to 2.18.0 carries the vulnerable code path.
Know when Penpot gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N
AC:H and effectively an attack prerequisite reflect the required NAT64 gateway or attacker-controlled AAAA record; PR:L because an authenticated user/admin must submit the URL; C:H as media import discloses internal response bodies, with no integrity/availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
Penpot is an open-source design and prototyping platform. Prior to 2.18.0, app.util.ssrf/blocked-address? relies on Java InetAddress predicates that do not classify NAT64, 6to4, or Teredo addresses and applies additional CIDR checks only to IPv4 values. Exploitation requires routing through a NAT64 gateway or an attacker-controlled DNS AAAA record; cloud environments with NAT64 gateways are directly exploitable. A user controlling a media import URL, or an administrator controlling a webhook URL, can then supply an IPv6 transition address that embeds a cloud-metadata, loopback, link-local, or private IPv4 target and bypasses the intended SSRF restrictions. Media import can disclose response bodies, while webhook delivery can expose response status as a network-probing side channel. This issue is fixed in version 2.18.0.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
Penpot before version 2.13.2 contains a path traversal vulnerability in the font creation endpoint that allows authentic
Authenticated command injection in the Penpot SVG exporter prior to 2.18.0 allows a user with edit rights on a design fi
Account takeover in Penpot before 2.14.5 allows an authenticated registered user to hijack any non-blocked profile witho
Server-side request forgery in Penpot before 2.15.0 lets an authenticated file editor coerce the backend into fetching a
Missing authorization on Penpot's ::import-binfile RPC command allows any authenticated user to overwrite arbitrary file
Privilege escalation in Penpot before 2.18.0 lets a non-owner team administrator promote themselves to team owner by cre
Missing authorization checks in Penpot prior to 2.18.0 let a holder of a valid share link read design and shape data fro
Penpot versions prior to 2.18.0 leak the contents of other users' in-progress uploads because the backend assemble-chunk
Logout in Penpot versions prior to 2.18.0 clears the browser's auth-token cookie but leaves the matching server-side ses
Authenticated editors on a Penpot file (prior to version 2.18.0) can delete share links that were created by other users
Stored cross-site scripting in Penpot before 2.18.0 allows an authenticated user holding file-edit permission to upload
Authenticated users of Penpot prior to 2.18.0 can exhaust server-side temporary storage by repeatedly re-uploading a val
EUVD-2026-92707
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB