CVE-2024-4367 PDF.js Arbitrary Code Execution

Mozilla PDF.js CVE-2024-4367 is an arbitrary JavaScript-execution vulnerability disclosed on May 20, 2024, by Codean Labs researcher Thomas Rinsma. The root cause is that PDF.js evaluated a font-metric field from the PDF file as JavaScript in the context of the page that rendered the document, which means opening a malicious PDF with an unpatched PDF.js build executes attacker-controlled code with the privileges of the embedder. Because PDF.js ships bundled inside Firefox, Thunderbird, hundreds of npm packages, and thousands of web applications that preview user-uploaded PDFs, a single upstream flaw propagates across a broad dependency graph. Rinsma's writeup drove patching across the ecosystem, but long-tail exposure persists in forgotten vendored copies.

What is the technical root cause of CVE-2024-4367?

The technical root cause of CVE-2024-4367 is that PDF.js's font-handling code took a value from the font's FontMatrix entry and used it to build a JavaScript expression that was then evaluated with eval or a similar construct. As Rinsma documented in the Codean Labs disclosure, the PDF specification allows a font to declare a custom transformation matrix, and PDF.js parsed the matrix values directly from the document. A crafted matrix whose fields contained arbitrary JavaScript characters survived the surrounding string construction and was executed as code.

The impact context depends on where PDF.js is running. Inside Firefox, the PDF viewer runs in a privileged context with access to the Components.utils interfaces, so the attacker can reach chrome-level APIs that in turn allow broader system interaction. Inside Thunderbird, the equivalent APIs give access to mail-client internals. Inside a web application that embeds PDF.js client-side, the code runs in the page's origin, which allows cross-site interactions within that origin but not direct system access. In Node.js-based server-side PDF.js usage, the code runs in the Node process with full filesystem and network access.

Mozilla's fix, shipped in PDF.js 4.2.67 and backported into Firefox 126, Firefox ESR 115.11, and Thunderbird 115.11, validates the font-matrix field and rejects any content that would escape the intended numeric context.

Which PDF.js embedders are affected?

Affected embedders include every product that bundles PDF.js older than version 4.2.67. The direct list Mozilla published covers Firefox before 126, Firefox ESR before 115.11, and Thunderbird before 115.11. The indirect list is effectively the full dependency graph of the npm pdfjs-dist package, which according to npm download statistics was pulled hundreds of millions of times per year at the time of disclosure.

Common embedder categories:

• Web applications that render uploaded PDFs client-side (document review tools, expense systems, case-management platforms)
• Electron applications bundling PDF.js for in-app document viewing (note-taking apps, CRM clients, support tools)
• Server-side PDF processing in Node.js that uses PDF.js for text extraction or thumbnail generation
• Developer-tooling such as documentation generators that parse PDFs as part of content ingestion
• Browser extensions that rewrite PDF links to use in-page PDF.js rendering

Each category has a different patch velocity. Firefox users were covered by the regular update channel within days. Electron application users depended on the application's own release cycle, which ranges from weeks to never. Server-side Node.js users depended on their own dependency-update discipline. Vendored copies (PDF.js embedded as a static asset rather than via npm) were the slowest to catch up because package-manager tooling does not see them.

How does the exploit chain work end-to-end?

The exploit chain works by delivering a PDF with a malicious font and convincing the victim to open it in a vulnerable PDF.js context. End-to-end:

1. Attacker crafts a PDF containing a Type1 or TrueType font whose FontMatrix contains a JavaScript payload wrapped to survive PDF parsing
2. Victim opens the PDF in Firefox, Thunderbird, or a web application that uses PDF.js to render previews
3. PDF.js parses the font table and constructs the JavaScript expression from the matrix values
4. The expression is evaluated, executing the attacker's JavaScript in the embedder's context
5. The payload performs the attacker's objective: in browser contexts, stealing cookies or credentials from same-origin storage; in Electron or server contexts, reaching filesystem and process APIs

Rinsma's writeup includes a working PoC that opens the calculator on a vulnerable Node.js PDF.js installation, demonstrating the server-side RCE path. Browser-side impact is narrower but still significant because PDF.js in Firefox runs with privileges that exceed ordinary web content.

What public IoCs did defenders publish?

Public IoCs published by Mozilla, the PDF.js project, and independent researchers include:

• PDFs whose font objects contain unusual FontMatrix values with non-numeric characters or excessive string content
• PDFs that include JavaScript-like syntax inside font descriptors when inspected with a text-mode PDF parser
• Firefox or Thunderbird telemetry showing unexpected chrome-level API calls invoked from PDF viewer contexts
• Electron application logs showing renderer-process crashes or unusual IPC traffic shortly after opening a PDF
• Server-side Node.js logs showing child-process creation from a PDF-processing worker that does not normally spawn processes

Because the attack lands in JavaScript context, endpoint detection that focuses on binary-process lineage can miss it entirely until the script produces a visible effect. Web-application logs showing unusual same-origin API calls immediately after a PDF upload and preview are a stronger signal for application-embedded contexts.

What are the exploitation prerequisites?

The exploitation prerequisites are that a vulnerable PDF.js build renders a crafted PDF. No authentication or special privileges are required on the victim's side beyond the ability to open the document, which for email-delivered attacks is effectively zero friction in Thunderbird's preview and one click in Firefox. Server-side embedders that auto-render uploaded PDFs for thumbnails or OCR are triggered without any user interaction at all; the upload alone is sufficient.

Factors that change exploitability:

• Firefox's sandboxing: limits but does not fully contain post-exploitation within the browser
• Electron context isolation: if enabled and properly scoped, limits the payload's reach to the renderer process
• Server-side PDF processing in a containerized sandbox: constrains post-exploitation to the container
• Content-security-policy headers on web applications embedding PDF.js: constrain some post-exploitation network activity

What is the patch and hardening plan?

The patch plan is to update every PDF.js instance to 4.2.67 or later. For Firefox and Thunderbird users, the regular update channel handles this automatically. For direct consumers of pdfjs-dist via npm, the fix requires a dependency bump and a rebuild of downstream applications. For vendored copies of PDF.js distributed as static assets, the fix requires manually replacing the assets.

Remediation sequence for application teams:

1. Identify every application that embeds PDF.js, including vendored copies that do not appear in the npm dependency tree
2. Bump pdfjs-dist to 4.2.67 or later and rebuild
3. Replace vendored static copies with the patched build
4. Add CI checks that fail when a known-vulnerable PDF.js version appears in a build output
5. Audit Electron applications and coordinate with vendors that ship affected applications

Hardening that pays dividends beyond this CVE:

• Render uploaded PDFs in an isolated origin (sandboxed iframe with a unique origin or a dedicated subdomain) to limit same-origin impact
• Process PDFs server-side in a containerized, network-isolated worker with no secrets mounted
• Use Content-Security-Policy headers that prohibit inline script and restrict connectable origins on any page that embeds PDF.js
• Add a PDF-layer scanner to the ingestion pipeline that rejects documents with suspicious font metadata

Organizations with mature supply-chain tooling can also add allowlist policies that refuse to build releases containing PDF.js below the fixed version.

What are the supply chain implications?

The supply chain implications are broad because PDF.js is a long-tail dependency that many teams forgot they had shipped. The npm download statistics understate the real footprint because vendored copies and CDN-hosted asset builds do not show up in dependency counts. During the patch window, security researchers documented vulnerable PDF.js copies across:

• Government document-submission portals
• Healthcare patient-record review tools
• Banking statement download features
• Corporate expense and invoice review systems
• Legal discovery and case-management platforms
• Enterprise note-taking applications with PDF annotation

Each of those categories represents a cross-vendor exposure path because an attacker who compromises a customer-facing document upload gains access to the target organization's user population. Several incident reports published through 2024 attributed initial-access phases to PDF-delivered payloads that exploited PDF.js embedders, although detailed campaign attribution remains limited.

Questions to push to vendors whose products embed PDF.js:

• Which PDF.js version does the current release contain
• How long between upstream security releases and downstream patch availability
• Is PDF.js run in an isolated rendering context within the vendor's product

How Safeguard.sh Helps

Safeguard.sh inventories PDF.js across the dependency graph through 100-level dependency depth analysis that walks npm dependencies, vendored static assets, and binary artifacts inside Electron application packages and server-side container images. Reachability analysis cuts 60 to 80 percent of findings by confirming which PDF.js instances actually render untrusted PDFs versus those embedded in read-only internal flows, so the patch queue reflects genuine exploit paths. Griffin AI autonomously drafts patch strategies for vendored copies, proposes CSP and origin-isolation policies for web applications that embed PDF.js, and generates dependency-update pull requests across the affected repositories. Container self-healing rebuilds images that embed vulnerable PDF.js against patched bases, and SBOM generation and ingest captures Electron applications and vendor products whose SBOMs typically miss embedded PDF.js copies.