CVE-2024-4367 – Arbitrary JavaScript execution in PDF.js

Original Article ↗ Hacker News Discussion ↗

A newly disclosed vulnerability in Mozilla’s PDF.js library (CVE-2024-4367) allows arbitrary JavaScript execution when a crafted PDF is opened, affecting Firefox versions prior to 126 and any web or Electron apps that embed PDF.js. Commenters note that while Firefox now isolates its built‑in PDF viewer under a special origin, many Electron and web apps do not, turning the flaw into a powerful XSS primitive and, in poorly sandboxed desktop apps, potential native code execution. The thread also touches on the long‑standing complexity and fragility of the PDF format, the importance of rapid browser updates, and hardening measures such as strict origin separation and Content Security Policy.

Vulnerability and impact

  • Bug in PDF.js lets attackers execute arbitrary JavaScript when a malicious PDF is opened.
  • In Firefox itself, PDF.js runs in a special resource://pdf.js origin: no local file access, but with some extra powers (file download prompts, access to path of opened file).
  • In web apps that embed PDF.js in their own origin, this becomes an XSS primitive on that domain, enabling data theft, account takeover, or malicious actions.
  • In Electron/Tauri apps that expose native APIs and don’t sandbox JS correctly, the same bug can escalate to native code execution (RCE).

Who is affected / where PDF.js is used

  • All Firefox versions <126 are said to be affected; new versions and ESR builds have patches, sometimes backported.
  • Discussion about which Electron apps embed PDF.js by default (several guesses, no confirmation).
  • Some think parts of the Microsoft ecosystem might be affected; others note Edge uses PDFium/Word-based rendering, suggesting it’s probably not.

Disclosure, patching, and updates

  • Some argue publishing the blog post 6 days after Firefox’s fix is risky given slow updates in many Electron apps and some Linux distros.
  • Others note most Firefox users on Windows/macOS auto-update quickly; ESR builds are patched separately.
  • Mixed views on Snap and other package managers: quick to ship 126 in some cases, but also reports of lags and users needing manual updates.

PDF format debates

  • Thread revisits long‑standing criticism of PDF as overly complex and “paper‑centric.”
  • Alternatives mentioned: PDF/A, OpenXPS, DjVu. PDF/A praised for dropping JS/media, but it’s noted the current bug is unrelated to PDF’s own scripting and instead about font handling (/FontMatrix).
  • Long subthread on how badly copy‑paste and semantics often work in PDFs. Some argue it’s an inherent design flaw; others say the format supports proper tagging and ToUnicode maps, and the problems are mostly in generators/viewers.

Security practices and mitigations

  • Debate over a historic Stack Overflow answer that called the risk “only XSS” and “tiny”:
    • Critics say downplaying exploitability and XSS impact is irresponsible.
    • Defenders say it correctly scoped the attack as XSS, not RCE, and suggested sound mitigations (separate origin).
  • General agreement that XSS is serious today, especially on sensitive origins or in Electron apps.
  • Suggested mitigations:
    • Serve PDF viewers on a separate origin, avoiding relaxed subdomain policies.
    • Strong Content Security Policies for pages that embed PDF.js.
    • Disable script evaluation in PDF.js where possible, though one commenter notes this specific vuln works even with scripting disabled.
  • Some advocate “no JavaScript” or using only built‑in browser/desktop PDF viewers; others counter that JS renderers are needed for in‑app workflows (text extraction, authenticated form filling, signatures, onboarding flows).

JS PDF viewers vs. native PDF rendering

  • Several argue most JS PDF viewers perform poorly; best UX is often to serve PDFs directly and let the browser/OS handle them.
  • Others emphasize valid business cases where tightly integrated, JS-based PDF handling in the web app is necessary, despite the extra attack surface.