PDF is trusted as a safe, static format, yet a PDF file can carry JavaScript, forms that submit data, embedded files, links that launch other content and hidden layers that survive a careless redaction. That gap between perception and capability makes PDFs a staple of phishing attachments and a regular source of data leaks when "redacted" documents are published. This guide explains the parts of the PDF format that create risk, how to harden Adobe Acrobat and Reader and browser-based viewers, how to handle PDFs safely in email and upload pipelines, and how to redact so the data is actually gone. It is written for endpoint and email security teams, application developers who accept or generate PDFs, and legal, privacy and records teams who publish redacted documents.
Key takeaways
- A PDF is a container, not a picture. Actions, JavaScript, form submission, embedded files and multiple revisions all live inside the file, and any reader that supports them exposes them.
- Reader patching is a KEV-level priority. CISA's Known Exploited Vulnerabilities catalogue lists 24 Adobe Acrobat and Reader vulnerabilities (catalogue version 2026.10.21), including entries added in 2026.
- Turn off what you do not use. Disabling Acrobat JavaScript, enabling Protected Mode and Protected View, and restricting privileged locations removes most of the scripted attack surface.
- Treat inbound PDFs as untrusted content. Detonate or disarm them in email and upload pipelines, and render them in a sandbox rather than on a server with credentials.
- Black boxes are not redaction. Covered text, metadata, earlier revisions and attachments remain recoverable unless content is removed and the file is sanitised and checked.
Where the risk lives in a PDF
The current core specification is ISO 32000-2 (PDF 2.0); the 2020 dated revision has been available at no cost from the PDF Association since April 2023. Readers implement the specification to different depths, which is why the same file can be inert in one viewer and active in another. The features that matter for security:
| Feature | What it does | Security concern |
|---|---|---|
Document and page actions (/OpenAction, /AA) | Run an action when the document opens, a page is shown or a field changes | Triggers JavaScript or navigation without the user clicking anything |
JavaScript (/JavaScript, /JS) | Scripts for calculation, validation and interactivity | The most common route to exploiting reader memory bugs (MITRE ATT&CK T1059.007 JavaScript) |
Launch and URI actions (/Launch, /URI) | Open another file or application, or a web address | Lures to credential phishing pages, or attempts to start local programs |
| Forms: AcroForm and XFA | Fillable fields; /SubmitForm sends field data to a URL. XFA is Adobe's XML-based form technology, deprecated in PDF 2.0 | Data sent to an attacker-controlled endpoint; XFA adds a large, rarely needed parser |
Embedded files (/EmbeddedFiles) and attachments | Carry other files inside the PDF | Delivers executables, scripts or Office documents past filters that only inspect the outer file |
| Incremental updates | Edits are appended to the file rather than rewriting it | Earlier revisions, including text that was later "removed", can remain in the file |
| Fonts, images and streams | Embedded fonts and compressed streams decoded by the reader | Memory corruption in parsers; obfuscation of content (T1027 Obfuscated Files or Information) |
Browser viewers are not immune. Mozilla's advisory MFSA 2024-21 describes CVE-2024-4367 in PDF.js, the viewer built into Firefox: a missing type check in font handling allowed arbitrary JavaScript execution in the PDF.js context, rated High and fixed in Firefox 126. Any application that embeds PDF.js to show user documents inherited the issue until it updated its copy of the library.
How malicious PDFs are used
- Exploit delivery: a crafted PDF triggers a memory bug in the reader, often through JavaScript or a malformed object, giving code execution when the file is opened (T1203 Exploitation for Client Execution). The KEV catalogue's Acrobat and Reader entries span almost two decades of CVE identifiers, from CVE-2007-5659 to CVE-2026-34621, a prototype pollution flaw added on 13 April 2026.
- Phishing carrier: the far more common case today. The PDF contains no exploit, just a convincing page and a link or QR code to a credential harvesting site. Because the link sits inside an attachment, some URL filters never see it (T1566.001 Spearphishing Attachment, T1204.002 Malicious File). See the QR Code Phishing (Quishing) Guide.
- Payload wrapper: an embedded file or a link to a download, with instructions persuading the user to open it.
- Data capture: a form that looks like an official document and submits entered data to an external URL.
- Server-side attack: PDFs uploaded to a web application exploit the library that generates previews, extracts text or converts documents (T1190 Exploit Public-Facing Application). Ghostscript, which many conversion pipelines use, has a KEV entry (CVE-2017-8291).
Hardening Adobe Acrobat and Reader
Adobe's Enterprise Toolkit documents the controls administrators can set and lock. The sandbox protections are Windows-only and lockable; settings below are quoted from Adobe's Application Security pages, with <product> and <version> standing for the installed product.
| Control | Setting and location | Effect |
|---|---|---|
| Disable JavaScript | bEnableJS = 0 under HKCU\Software\Adobe\<product>\<version>\JSPrefs (UI: Preferences > JavaScript, "Enable Acrobat JavaScript") | Removes the main exploit and automation path; may break calculated forms |
| JavaScript API blocklist | tBlackList under HKLM\SOFTWARE\Policies\Adobe\<product>\<version>\FeatureLockDown\cJavaScriptPerms, a pipe-separated list of Object.Method names | Blocks specific APIs when JavaScript must stay on; if a blocked API appears, other scripts in the document are blocked too. Does not apply to 3D JavaScript |
| Menu item JavaScript | bEnableMenuItems in JSPrefs; off by default since Acrobat 7.0 | Limits privileged JavaScript invoked from menus |
| Protected Mode (Reader sandbox) | bProtectedMode = 1 under HKCU\Software\Adobe\<product>\<version>\Privileged | PDF and image parsing, JavaScript and 3D rendering run with limited privileges behind a broker process |
| Protected View (Acrobat) | iProtectedView under ...\TrustManager: never (default), files from untrusted locations (recommended), or always | Read-only view of untrusted files until the user trusts them; requires Protected Mode |
| AppContainer | bEnableProtectedModeAppContainer = 1 under ...\Privileged | Adds Windows application-level sandboxing; requires Protected Mode |
| Sandbox exceptions | bUseWhitelistConfigFile with ProtectedModeWhitelistConfig.txt | Relaxes specific restrictions; review any use, as it widens the sandbox |
Privileged locations: files, folders and hosts added as privileged locations run in a trusted context and can bypass JavaScript and other restrictions; Adobe also lets a certified document with a valid signature from an approved trust anchor override blocklist settings. Lock privileged locations through FeatureLockDown so users cannot trust arbitrary network shares or download folders, and review which certificates are trusted for high-privilege JavaScript.
Other readers: apply the equivalent controls in whichever reader you deploy: disable scripting, keep its sandbox on, and block launching of external applications. Opening PDFs in a modern browser viewer is a reasonable default for most users who never need scripted forms, provided the browser is patched quickly. Users who need XFA or complex scripted forms can be given the full reader as an exception.
Handling PDFs in email and upload pipelines
- Email: detonate PDF attachments in a sandbox, extract and rewrite URLs and QR codes found inside them, and block PDFs that contain embedded executables or launch actions. See the Malware Sandbox Guide and the Microsoft Defender for Office 365 Configuration Guide if you use that platform.
- Content disarm and reconstruction (CDR): rebuild the PDF without active content (JavaScript, actions, embedded files, XFA) or flatten it to images. The OWASP File Upload Cheat Sheet recommends CDR for document types such as PDF where applicable. Flattening is the strongest option but destroys text search and accessibility. See the Content Disarm and Reconstruction buyer's guide.
- Web uploads: validate the file signature, cap page count and file size, and run text extraction, thumbnailing or conversion in an isolated worker with no network access and a time limit. The same sandboxing approach as for media files applies; see the FFmpeg and Media Processing Security Guide and the Secure File Upload Handling Guide.
- Serving PDFs back: serve user-uploaded PDFs from a separate domain or as downloads, so a viewer flaw cannot run script in your application's origin. If you embed a JavaScript viewer, keep it current and disable script evaluation options it offers.
- Generating PDFs: HTML-to-PDF converters that fetch remote resources can be pushed into server-side request forgery if user input reaches the template. Disable remote resource loading or allowlist hosts.
Redaction failures and how to prevent them
NSA's guidance "Redacting with Confidence" put the problem plainly: information hidden or covered in an electronic document can almost always be recovered. Drawing a black rectangle, changing text colour to white or covering an image with a shape changes what is displayed, not what is stored. Common ways redacted data leaks:
| Failure | Why the data survives | Prevention |
|---|---|---|
| Box or highlight drawn over text | The text object is still in the page content and can be copied or extracted | Use a true redaction tool that removes the underlying content, then apply it |
| Redaction marked but never applied | Some tools mark areas first and remove content only when the redaction is applied and saved | Make "apply and save as new file" a mandatory step; check the output, not the working file |
| Incremental save | Earlier revisions remain appended in the file | Save as a new, fully rewritten file after sanitising |
| Metadata and hidden data | Author, document properties, comments, bookmarks, form field values, attachments and hidden layers carry sensitive content | Run the reader's sanitise or remove hidden information function; Adobe Acrobat Pro offers this after applying redactions |
| Source file redaction | Content is deleted in the word processor but tracked changes, comments or the attached source file survive conversion | Follow NSA's process: work on a copy, delete in the source, replace with same-length placeholders, copy into a new document, disable source attachment and document information on conversion |
| Scanned or image-based pages | OCR text layers sit behind the image and are not covered by drawing on the image | Redact both the image and the text layer, or rasterise the final output |
Verification is the control that catches all of these. Before release, a second person should open the output file, select all text and paste it into a plain text editor, search for the redacted terms, inspect document properties and attachments, and check the file size against expectations. Organisations that publish redacted material regularly should make this a documented procedure tied to their records and privacy obligations; see the Data Loss Prevention (DLP) Guide for scanning outbound documents.
Implementation roadmap
- Inventory readers: list PDF readers and versions on endpoints, and every server component that parses or generates PDFs (preview services, converters, e-signature integrations, document AI pipelines).
- Patch: put Acrobat, Reader and browser updates on the fast-track patch cycle you use for KEV entries.
- Audit JavaScript use: before disabling it, ask business owners which workflows rely on scripted forms. Pilot the hardened configuration (JavaScript off, Protected Mode and Protected View on, locked privileged locations) with one department for two weeks.
- Roll out by policy: deploy settings through Group Policy, Intune or your management tool using the
FeatureLockDownkeys so users cannot reverse them. Rollback is removing the policy; keep an exception group for users who need scripted forms in the full reader. - Harden the pipelines: enable PDF detonation and URL extraction in email, add CDR where business need allows, and isolate server-side PDF processing.
- Fix redaction: standardise on a tool with true redaction and sanitisation, write the verification procedure, and train the teams that publish documents.
Decision guidance
- Browser viewer or full reader: a browser viewer has a smaller feature set and updates automatically; choose it as the default. Keep the full reader for users who sign, edit or fill complex forms, with JavaScript off unless required.
- JavaScript off or blocklist: disable it entirely where forms are not scripted. Use
tBlackListonly when a business-critical form needs scripting, and pair it with Protected Mode. - CDR or detonation: detonation preserves the original file but can miss evasive content; CDR removes active content reliably but can break forms and signatures. Many organisations use CDR for external email and detonation for files that must stay intact.
- Small organisations: rely on automatic browser updates, an email security service that scans attachments, and Adobe's settings deployed through your device management. Large organisations add CDR, central reader configuration baselines and a redaction review procedure.
Detection and measurement
- Reader spawning processes: alert when the reader or browser PDF process starts a shell, script host or unexpected executable.
- Attachment telemetry: count PDFs with JavaScript, launch actions, embedded files or external form submission arriving by email, and which were blocked or disarmed.
- Clicks from PDFs: URL clicks originating from PDF attachments, especially to newly registered domains.
- Configuration drift: devices where
bEnableJS,bProtectedModeoriProtectedViewdiffer from the baseline.
Metrics: percentage of endpoints with JavaScript disabled and Protected Mode enforced; median days to deploy reader security updates; share of inbound PDFs sandboxed or disarmed; redaction verification checks performed versus documents released; number of redaction errors caught before publication.
Common failure patterns
- Exceptions that never expire: a whole department gets JavaScript re-enabled for one form and keeps it for years.
- Privileged locations on shared drives: adding a network share or downloads folder as trusted turns every file saved there into a trusted document.
- Bundled outdated viewers: web applications ship an old copy of a PDF library and never update it, inheriting fixed flaws such as CVE-2024-4367.
- Scanning only the outer file: filters that ignore embedded files and links inside PDFs miss the payload.
- Trusting the visual result: redaction is checked on screen rather than by extracting text and inspecting the saved output.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-3 Malicious Code Protection; SC-18 Mobile Code; SC-44 Detonation Chambers; CM-6 Configuration Settings; SI-12 Information Management and Retention | Attachment scanning; controlling embedded JavaScript; sandbox detonation; reader baselines; handling of released documents |
| NIST CSF 2.0 | PR.PS-01; PR.DS-01; DE.CM-09 | Reader configuration management; protecting data in published documents; monitoring endpoint behaviour |
| CIS Controls v8.1 | Control 3 (Data Protection), 4 (Secure Configuration), 7 (Continuous Vulnerability Management), 9 (Email and Web Browser Protections), 10 (Malware Defenses) | Redaction and data handling, reader hardening, patching, email filtering, anti-malware |
| ISO/IEC 27001:2022 Annex A | A.8.7 Protection against malware; A.8.9 Configuration management; A.8.11 Data masking; A.8.12 Data leakage prevention | Malicious PDF defence, reader baselines, redaction, outbound document checks |
| MITRE ATT&CK | T1566.001 Spearphishing Attachment; T1204.002 Malicious File; T1203 Exploitation for Client Execution; T1059.007 JavaScript | Delivery and execution techniques for malicious PDFs |
| MITRE D3FEND | D3-FA File Analysis; D3-DA Dynamic Analysis | Static inspection of PDF structure; sandbox detonation |
Practitioner checklist
NHI Mgmt Group recommends the following checks.
- Inventory PDF readers, browser viewers and server-side PDF libraries, with versions.
- Patch Acrobat, Reader, browsers and embedded PDF libraries on your KEV timescale.
- Disable Acrobat JavaScript by policy, or use
tBlackListwhere scripting is essential. - Enforce Protected Mode, set Protected View for untrusted files and enable AppContainer.
- Lock privileged locations and review trusted certificates for high-privilege JavaScript.
- Sandbox or disarm inbound PDF attachments and extract embedded links and QR codes.
- Process uploaded PDFs in isolated workers with no network access, and serve them from a separate origin.
- Adopt a redaction procedure: true redaction, sanitise hidden data, save as new file, independent text-extraction check.
Standards and references
- PDF Association: ISO 32000-2 (PDF 2.0)
- Adobe: Enterprise Toolkit, JavaScript Controls
- Adobe: Enterprise Toolkit, Sandbox Protections
- NSA: Redacting with Confidence
- Mozilla: Security Advisory MFSA 2024-21 (CVE-2024-4367)
- CISA: Known Exploited Vulnerabilities Catalog
- OWASP: File Upload Cheat Sheet
- MITRE ATT&CK: Spearphishing Attachment
Related NHI Mgmt Group resources: Phishing Guide · Macro Malware Guide · Malware Sandbox Guide · Data Loss Prevention (DLP) Guide