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

Original Article ↗ Hacker News Discussion ↗

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.