CVE-2025-68428: Critical Path Traversal and Local File Inclusion in jsPDF

CVE-2025-68428 represents a critical security flaw in the server-side implementation of jsPDF, a widely used library for generating PDF documents. While jsPDF is primarily known for client-side usage in browsers, it offers specific builds (jspdf.node.js and jspdf.node.min.js) for Node.js environments. These server-side builds require file system access to load resources such as fonts, images, and HTML templates.

The vulnerability is classified as a Path Traversal (CWE-22) and Local File Inclusion (LFI) issue. It arises because the library explicitly trusted user-supplied paths when loading external resources. If a web application exposes PDF generation functionality—for instance, allowing users to specify a logo URL or a font path—an attacker can supply a malicious path containing traversal sequences (e.g., ../../).

Successful exploitation results in the application reading files outside the intended directory. The content of these files is then processed and often embedded directly into the generated PDF, allowing the attacker to retrieve sensitive system configuration files, source code, or credentials simply by downloading the resulting document.

The root cause of this vulnerability lies in the nodeReadFile function located within the libs/fileloading.js module. In versions prior to 4.0.0, this function was responsible for handling file I/O operations when the library detected it was running in a Node.js environment.

The logic used path.resolve(url) to process the input path. While path.resolve resolves relative segments like .., it does not verify that the resulting absolute path resides within a safe or expected directory. It simply normalizes the string and returns an absolute path on the filesystem.

Immediately after resolution, the library passed this absolute path to fs.readFileSync. There were no checks to ensure the path was within a specific sandbox or allowlist. Consequently, an input of ../../../../etc/passwd would be resolved by Node.js to /etc/passwd (assuming the traversal depth was sufficient), and the file system API would obediently read the file. This creates a direct bridge between user input and the server's restricted filesystem.

The following analysis compares the vulnerable file loading logic with the hardened implementation in version 4.0.0.

Vulnerable Implementation (Pre-v4.0.0)

In the vulnerable version, the code performs no validation on the resolved path. It assumes that path.resolve is sufficient for safety, which is a common misconception.

// libs/fileloading.js (simplified)
function nodeReadFile(url, callback) {
    // DANGEROUS: path.resolve processes '..' but enforces no boundaries
    var resolvedPath = require('path').resolve(url);
    
    // The file is read immediately without authorization checks
    var data = require('fs').readFileSync(resolvedPath);
    return data;
}

Patched Implementation (v4.0.0)

The fix introduces a strict "deny-by-default" model. It requires developers to explicitly allowlist paths via jsPDF.allowFsRead.

// libs/fileloading.js (patched)
function nodeReadFile(url, callback) {
    var path = require('path');
    var fs = require('fs');
    
    // 1. Resolve the path to handle relative segments
    var resolvedPath = path.resolve(url);
    
    // 2. CHECK: Is this path in the allowed list?
    // The library now iterates through `jsPDF.allowFsRead` patterns.
    // If no match is found, it throws an error preventing the read.
    if (!isPathAllowed(resolvedPath)) {
        throw new Error("File access denied: " + resolvedPath);
    }
    
    // 3. SAFE: Read the file only after validation
    return fs.readFileSync(resolvedPath);
}

> [!NOTE] > The patch forces a breaking change. Developers upgrading to v4.0.0 must configure the allowFsRead property, or all local file loading operations will fail by default.

Exploiting this vulnerability requires an application to pass user-controlled input into one of jsPDF's file-loading methods, such as addImage, addFont, or loadFile. A common scenario is an invoice generator that allows a user to specify a custom logo.

Attack Vector

1. Reconnaissance: The attacker identifies a feature that generates PDFs and accepts a URL or filename (e.g., POST /api/invoice with {"logo": "default.png"}).
2. Payload Construction: The attacker crafts a payload using directory traversal sequences to reach the root directory and access sensitive files.
3. Execution: The payload is submitted: {"logo": "../../../../../../../etc/passwd"}.
4. Data Exfiltration: The server generates the PDF. Since jsPDF treats the file content as image or font data (or raw text depending on the method), the content of /etc/passwd is embedded into the PDF stream.

Proof of Concept

If the application blindly passes the input to doc.addImage, the resulting PDF might be corrupt (as /etc/passwd is not a valid image), but the file data is still present in the PDF source code. If loadFile is used, the text is returned directly.

# Example of retrieving the generated PDF and inspecting raw content
curl -X POST https://vulnerable-app.com/generate -d "image=../../etc/passwd" -o leak.pdf
 
# Inspecting the PDF binary for known strings
grep "root:x:0:0" leak.pdf

The impact of CVE-2025-68428 is rated Critical (CVSS 9.2) due to the complete loss of confidentiality regarding local files on the server.

• Confidentiality: High. Attackers can read configuration files, environment variables (if stored in files), source code, and system credentials. This can lead to further compromise of the infrastructure or database.
• Integrity: None. The vulnerability allows reading files, not writing or modifying them.
• Availability: Low to None. While an attacker might try to read extremely large files to exhaust memory, the primary risk is data leakage.

This vulnerability is particularly dangerous because it bypasses application-level authentication checks for file access, relying solely on the permissions of the Node.js process, which often runs with excessive read privileges.

The only complete fix is to upgrade the library and configure the new security controls. Network-level mitigations are difficult to implement effectively because the traversal happens within the application logic, not the HTTP URI (unless the input is taken directly from the URL path).

Official Patch

Upgrade to jsPDF v4.0.0 or later immediately. Verify the version in your package.json:

"dependencies": {
  "jspdf": "^4.0.0"
}

Configuration Required

After upgrading, you must explicitly allow access to the directories your application needs. Faiilure to do so will break PDF generation features that load local files.

const { jsPDF } = require('jspdf');
const doc = new jsPDF();
 
// SECURITY: Whitelist specific directories for file access
doc.allowFsRead = [
  path.resolve(__dirname, 'assets/fonts'),
  path.resolve(__dirname, 'assets/images')
];

Defense in Depth

For critical environments, consider using the Node.js experimental permission model (available in Node 20+) to restrict the filesystem access of the entire process, providing a safety net even if the library is misconfigured.

node --permission --allow-fs-read="/app/assets/*" app.js