@pdfme/common EUVD-2026-108940

Exploitation requires that the application allow an attacker to control a pdfme template's basePdf value that reaches getB64BasePdf, AND that the code run in an environment where window is defined - a browser or a server-side DOM shim - since the vulnerable fetch path only executes there; purely headless Node without a DOM shim does not hit it. The attacker must supply a URL whose hostname evades the string denylist: IPv4-mapped IPv6 (e.g. http://[::ffff:127.0.0.1]/ or http://[::ffff:a9fe:a9fe]/), the unspecified address http://[::]/, NAT64 (http://[64:ff9b::a9fe:a9fe]/), or a trailing-dot/alias localhost (http://localhost./). Limiting factors: no exploitation without attacker-controlled basePdf input, and none outside a window-defined fetch context; plain dotted-quad loopback and metadata addresses are already correctly rejected.

This is a server-side request forgery (CWE-918) in @pdfme/common, rated CVSS 4.0 8.9 (High) with vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N - network reachable, no privileges or user interaction, but with elevated attack complexity and a present attack requirement (AT:P), and high confidentiality impact on both the vulnerable and a subsequent system (the internal/metadata endpoint reached via SSRF). The vuln.today decision label is 'this_week' rather than act_now/emergency, which is consistent with the absence of a CISA KEV listing - there is no confirmed active exploitation. No EPSS probability was supplied in the input, so widespread-exploitation likelihood cannot be quantified here. A public PoC reference exists in the GHSA advisory (it demonstrates the denylist bypass via isUrlSafeToFetch returning true for internal addresses); it is not verified as a working end-to-end exploit. Note a signal conflict to verify: the GHSA advisory itself estimated CVSS 3.1 confidentiality as C:L with no scope change (S:U), whereas the supplied CVSS 4.0 vector asserts high vulnerable- and subsequent-system confidentiality (VC:H/SC:H) - the higher rating reflects reachability of cloud metadata credentials, but the vendor's own estimate was more conservative. Overall this is a genuine, patch-now-this-week issue for deployments matching the exploitation conditions, not a purely theoretical high-CVSS item, but it is gated by the application exposing attacker-controlled basePdf and running in a window-defined fetch context.

An application lets users supply or import a pdfme template, and that template's basePdf value is passed to getB64BasePdf in a runtime where window is defined (a browser or a server-side DOM shim). An attacker sets basePdf to http://[::ffff:a9fe:a9fe]/ (the IPv4-mapped form of 169.254.169.254), bypassing the isUrlSafeToFetch denylist so the runtime fetches the cloud metadata endpoint and embeds the response - potentially including credentials - into the generated PDF, which the attacker then retrieves. A public PoC reference exists demonstrating the bypass; it is not verified as working end-to-end exploit code.