Security 7 min read 15 October 2026

PDF JavaScript Security: Risks, Exploits, and Safe Handling

PDF has supported embedded JavaScript since PDF 1.3, and it has been a persistent attack surface ever since. This guide explains what JavaScript can do inside a PDF, the history of major PDF JS exploits, how enterprise security policies handle PDF scripting, and how to safely open unknown PDFs without exposing systems to script-based attacks.

JavaScript in PDF is a powerful — and dangerous — feature. It enables dynamic forms that recalculate totals, validate input, and submit data to servers. It also provides a recurring attack surface that has produced some of the most severe PDF-related security vulnerabilities ever disclosed, including remote code execution bugs in Adobe Acrobat and PDF.js that required no user interaction beyond opening a file. This guide explains how PDF JavaScript works at the technical level, reviews the most significant exploit categories, covers the security decisions made in modern PDF viewers, and explains how organisations can enforce JavaScript-disabled PDF policies to reduce their attack surface.

How JavaScript works in PDF

PDF JavaScript is based on an Adobe-defined extension of ECMAScript (JavaScript) called Acrobat JavaScript, with APIs specific to the PDF model. Scripts can be attached at multiple points in a PDF: Document-level scripts — Run when the document opens. Specified in the document catalogue's /JavaScript name tree. Used for global variable definitions, helper functions, and startup logic. Action triggers — JavaScript can be attached to many PDF event triggers: - /OpenAction — Runs when the document opens (before document-level scripts) - /AA (Additional Actions) — Per-page, per-field triggers: /O (Open), /C (Close), /F (Formatting), /K (Keystroke), /V (Validate), /Fo (Focus), /Bl (Blur) - Link annotation /Action /S /JavaScript — Run when a link is clicked - Bookmark actions — Run when a bookmark is activated Acrobat JavaScript API — The API exposes the entire PDF object model: this.getField() accesses form fields; this.pageNum gets the current page; app.alert() shows dialogs; this.submitForm() submits form data to a URL. The app.launchURL() and file I/O APIs (app.openDoc()) are the historically most-exploited capabilities.

Major exploit categories and historical vulnerabilities

PDF.js vulnerabilities (browser-side) — Mozilla's PDF.js, which renders PDFs in Firefox and is used by many web applications, had a serious JavaScript sandbox escape vulnerability (CVE-2024-4367, disclosed 2024) where specially crafted PDF font names could execute arbitrary JavaScript in the browser's rendering context, bypassing the PDF sandbox entirely. This was exploitable by a malicious PDF file viewed in Firefox. Earlier PDF.js CVEs include cross-origin data leaks and prototype pollution vulnerabilities. Adobe Acrobat RCE vulnerabilities — Acrobat has historically had multiple critical-severity RCEs (Remote Code Execution) in its JavaScript engine and PDF parsing. The JavaScript API's file system access functions (util.printf() format string bugs, app.doc property access), combined with memory corruption in the PDF renderer, have produced exploit chains requiring no user interaction beyond opening the document. Adobe's Patch Tuesday bulletins regularly address Acrobat JavaScript CVEs. Heap spray via JavaScript — Early (pre-2015) exploits commonly used JavaScript to spray the heap with shellcode in preparation for a separate memory corruption exploit in the PDF renderer or font handler. JavaScript could allocate large arrays or strings of controlled content, making heap addresses predictable for exploit reliability. Social engineering via JavaScript dialogs — Even without code execution, app.alert() can display convincing dialog boxes asking users to enter credentials, enable macros, or approve actions. This low-sophistication vector has been used in phishing PDFs distributed via email. Data exfiltration via submitForm — this.submitForm() can POST form field data (including sensitive content pre-filled in hidden fields) to an attacker-controlled server without user awareness. Combined with JavaScript that reads environment data, this has been used for fingerprinting and credential harvesting.

How modern PDF viewers handle JavaScript security

Browser-based viewers (Chrome, Firefox/PDF.js) — Run JavaScript in a sandboxed process isolated from the main browser content. Chrome's built-in PDF viewer disables JavaScript execution entirely — PDF JS is never run. Firefox's PDF.js runs in a Web Worker with restricted API access; post-CVE-2024-4367, JavaScript execution from PDFs is disabled by default. Adobe Acrobat Reader / Pro — Runs PDF JavaScript but in a sandboxed environment (Protected Mode on Windows, introduced in Acrobat X). File I/O APIs are restricted; network access from JavaScript requires whitelisting in the Trust Manager. Acrobat's JavaScript console is available in Pro for debugging. Disabling JavaScript in Acrobat — Edit > Preferences > JavaScript > Enable Acrobat JavaScript (uncheck). This disables all PDF JavaScript execution system-wide. For organisations deploying Acrobat via Group Policy, this can be set in the registry: HKCU\Software\Adobe\Acrobat Reader\24.0\JSPrefs\bEnableJS = 0. Enterprise policy deployment — Adobe provides an Application Toolkit for enforcing Acrobat settings via registry or MDM. The key settings for JavaScript security: bEnableJS (disable all JS), iJavaScriptSecurity (security level for JS execution). Microsoft Intune and Group Policy can distribute these registry keys to all corporate endpoints. PDF viewers that never run JavaScript — Apple Preview (macOS/iOS), Foxit Reader (unless explicitly configured), Sumatra PDF, and most Linux PDF viewers do not execute PDF JavaScript at all. For organisations where interactive PDF forms are not required, deploying a non-JS-executing viewer as the default PDF handler eliminates the entire PDF JavaScript attack surface.

Frequently asked questions

Can a PDF give my computer a virus just by opening it?

Yes, historically, and to a lesser extent today. Before 2015, simply opening a malicious PDF in an unpatched Adobe Reader could execute code without any user interaction. Modern PDF viewers are significantly hardened: sandboxing isolates the rendering process; JavaScript is disabled by default in most browsers; known vulnerability classes are continuously patched. However, zero-day vulnerabilities continue to be discovered in PDF renderers. The risk is not zero, especially with: unpatched older versions of Acrobat Reader; business email attachment workflows where PDFs from unknown senders are routinely opened; and environments where Interactive PDF JavaScript is enabled. Mitigation: keep PDF viewers updated, disable JavaScript in Acrobat if forms are not needed, use a viewer that never executes JavaScript (Apple Preview, Sumatra PDF) for viewing untrusted documents.

Are PDF forms with JavaScript safe?

PDF forms that use JavaScript for field validation, calculation, and formatting are safe when: (a) the PDF comes from a trusted source (your own organisation, a known government entity, a financial institution you chose to engage with); (b) you are using a reasonably up-to-date PDF viewer; and (c) the JavaScript does not attempt to access external URLs or system resources (which should be blocked by modern viewer sandboxes). Interactive tax forms from the IRS, fillable contracts from law firms, and similar professional forms use PDF JavaScript safely. The risk is primarily from unsolicited PDF attachments in email, where the sender and file origin are unknown. The Acrobat trust model lets you mark specific URLs or certificate issuers as trusted, which is appropriate for known form providers.

How can I check if a PDF contains JavaScript?

Several approaches: (1) Adobe Acrobat Pro: Edit > Search > Advanced Search > check "JavaScript" in the search scope to find JS actions. (2) pdfid.py (open-source, part of Didier Stevens' PDF tools): run `python pdfid.py document.pdf` — it counts the occurrences of /JavaScript, /JS, /OpenAction, /AA, /Launch, and other potentially dangerous keys without executing any content. (3) qpdf: `qpdf --qdf document.pdf - | grep -c "/JavaScript"` decompresses and pretty-prints the PDF, making it greppable. (4) VirusTotal: uploading the PDF to VirusTotal scans it with multiple antivirus engines including PDF-aware scanners that flag suspicious JavaScript patterns. For high-risk scenarios (untrusted attachment, financial content), scanning before opening is the safest approach.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Edit PDF Protect PDF Redact PDF Open editor