CVE-2026-31938

What it actually does

jsPDF versions before 4.2.1 fail to sanitize attacker-controlled values in the options argument of output() (and related overloads). Those values can introduce arbitrary HTML and script into the browser document in which the generated PDF is opened, executing as a cross-origin/scope-changing XSS in the victim application origin with access to that origin’s DOM, storage, and reachable secrets. Confidentiality and integrity impact is high; availability impact is limited. CVSS 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L).

Why it matters to the business

Any product that generates PDFs in the browser with jsPDF and forwards untrusted output options can expose users to session theft, unauthorized actions in the user’s account, and leakage of data shown in that origin. The library is widely embedded in web apps, so unpatched dependents inherit the risk even if they did not author the PDF code. The issue is not on CISA KEV, has no public exploit maturity, and EPSS remains low (~0.004) though it rose ~53% over 30 days; combined with CVSS 9.6 and ~194 days since publication, remaining pre-4.2.1 deployments are an overdue patching gap rather than an active mass-exploitation event.

How an attack unfolds

Exploitation requires an application that takes attacker-influenced values (forms, APIs, shared document settings) and passes them unsanitized into jsPDF output options, then a victim who generates and opens the PDF in their browser. Injected script then runs in the victim’s application origin and can read or alter secrets in that context. No named threat actors or ransomware campaigns are associated with this CVE, and public exploit maturity is none; success depends on an app-specific data path, not on a standalone remote exploit against jsPDF itself.

How to fix it

Upgrade the jspdf package to 4.2.1 or later (the version that fixes this issue). If an immediate upgrade is not possible, stop passing any user-controlled data into output() options; allowlist expected fields and treat option values as untrusted. Do not accept client-supplied HTML, document chrome, or type/target-related options. Hunt lockfiles, bundles, and CDNs for jspdf < 4.2.1 and replace transitive copies.

How to confirm the fix worked

Confirm installed and shipped jspdf is 4.2.1 or newer via package lockfiles, SBOM, and production JavaScript bundles. Review all output() call sites and prove no untrusted request or UI field reaches options. After upgrade, regression-test PDF generation with previously accepted untrusted option fields and confirm they are rejected or encoded rather than interpreted as HTML. Use SCA policy to fail builds that still pull jspdf below 4.2.1.

Typical attack path

1. Locate an application using jsPDF before 4.2.1 that forwards user-supplied values into output() options.
2. Submit untrusted option values through an exposed input such as a form, query parameter, or API.
3. Induce or wait for the victim to generate a PDF and open it in the browser.
4. Injected HTML/script executes in the victim’s application origin.
5. Attacker uses that origin context to steal session material or act as the victim.

How to detect it

This is client-side XSS; server access logs alone rarely prove exploitation. Prioritize exposure: SBOMs, lockfiles, and bundled JS containing jspdf below 4.2.1. For possible abuse, review application logs and telemetry around PDF generation for unexpected HTML or script-like content in output-option fields, CSP violation reports on PDF preview/download pages, and user reports of unexpected behavior immediately after opening an in-browser PDF. No named APT or ransomware activity is tied to this CVE; treat hits as application-specific input abuse, not a known campaign fingerprint.

What your security team should do

• Inventory every application and bundle that includes jspdf and flag versions below 4.2.1.
• Upgrade to jspdf@4.2.1 or later as a priority given CVSS 9.6 and time since publication.
• Block untrusted input from reaching output() options until upgrades land.
• Add SCA/SBOM gates so pre-4.2.1 jspdf cannot re-enter CI or production.
• Brief application owners that this is origin XSS via PDF open-in-browser, not a server RCE, and that user interaction (opening the PDF) is required.