Can a PDF contain malware?

Yes. PDFs support embedded JavaScript, automatic URL launching, executable file attachments and form submission actions. A malicious PDF can execute code the moment you open it using /OpenAction directives, drop payloads through embedded file streams, harvest credentials via /SubmitForm actions and redirect you to attacker-controlled domains through /URI entries. PDFs are the second most common malware delivery vector after Microsoft Office documents.

How do I check if a PDF is safe?

Open the PDF in a reader that exposes threat metadata before rendering content. Sherlock Forensic PDF Editor's Threat Inspector panel shows all /OpenAction, /Launch, /SubmitForm, /URI and embedded file entries before the document renders. You can also use command-line tools like pdfid.py to scan for suspicious keywords. Never open an unexpected PDF attachment in a standard reader without inspection first.

What makes Sherlock PDF Editor different from Adobe Reader?

Sherlock Forensic PDF Editor is built on a safe-by-default Rust parser that blocks all automatic code execution. It never runs /OpenAction JavaScript, never launches embedded executables and makes zero outbound network connections. The Threat Inspector panel displays every potentially dangerous element before the document renders. It ships as a single 12 MB executable with no cloud account required, compared to Adobe Reader's 300+ MB install and mandatory Adobe Cloud sign-in.

Why Every PDF You Open Is a Security Risk

The File You Trust Most Is the One That Gets You

You open PDFs every day. Invoices. Contracts. Resumes. Tax documents. Board reports. You treat them like inert paper. They are not.

PDFs are the number two malware delivery vector on the internet, second only to Microsoft Office documents. According to CISA and multiple threat intelligence reports from MITRE ATT&CK, attackers have been weaponizing PDFs for over a decade because the format is universally trusted and universally misunderstood.

Here is what most people do not know: the PDF specification is not a document format. It is a container format that supports embedded JavaScript execution, automatic URL redirection, executable file launching and silent data exfiltration. Every time you double-click a PDF, your reader may be executing code, phoning home to external servers and rendering active content. You never gave permission. You were never asked.

This is not a theoretical risk. It is the mechanism behind thousands of successful phishing campaigns, targeted attacks and malware infections every month. And your current PDF reader is designed to make it happen seamlessly.

How PDF Exploits Work (Plain English)

The PDF specification, maintained by ISO 32000, includes features that were designed for legitimate business automation. Attackers repurpose every one of them. Here is what a malicious PDF can do the moment you open it:

/OpenAction: Runs JavaScript automatically when the document opens. No click required. No prompt shown. The code executes before you see the first page. Attackers use this to fingerprint your system, check your PDF reader version and stage the next phase of the attack.
/Launch: Spawns an executable file on your system. A PDF can carry a Windows .exe, a PowerShell script or a batch file as an embedded object and launch it directly. Some readers show a warning. Many users click through it because the document looks legitimate.
/SubmitForm: Sends form data to an attacker-controlled server. If the PDF contains form fields (visible or hidden), this action silently submits whatever data those fields contain to any URL the attacker specifies. This includes data the PDF pre-populated without your knowledge.
/URI: Opens a URL in your default browser without asking. No confirmation dialog in many readers. The URL can point to a credential harvesting page, a drive-by download or a command-and-control server. The user sees a PDF. The browser opens a trap.
Embedded file streams: PDFs can carry any file type as an embedded attachment: executables, scripts, archives, even other PDFs. When combined with /Launch or social engineering ("click the attachment icon to view the full report"), these embedded files drop payloads directly onto the target system.
XFA forms: XML Forms Architecture is a legacy feature that supports full JavaScript execution within form elements. XFA forms have been the basis for multiple critical Adobe Reader vulnerabilities. The feature was deprecated in PDF 2.0 but is still supported by Adobe Reader for backward compatibility.

None of these require a software vulnerability. They are features of the PDF specification working exactly as designed. The attacker does not need a zero-day. They need a PDF reader that follows the spec, which is all of them.

If your organization handles sensitive documents, this is why incident response teams treat PDF attachments as a primary attack vector during investigations.

The Phishing PDF Playbook

Attackers do not need sophisticated exploits when social engineering works. The most common PDF-based phishing campaigns in 2025 and 2026 follow a simple playbook that bypasses email security gateways because the PDF itself contains no malware. The malware is the behavior it triggers.

Fake DocuSign and Microsoft 365 Login Pages

The PDF renders a pixel-perfect replica of a DocuSign signing page or a Microsoft 365 login screen. The entire page is a clickable /URI action that redirects to an attacker-controlled credential harvesting site. The URL often uses a legitimate-looking subdomain on a compromised domain. Email security tools scan the PDF for known malware signatures and find nothing because there is no malware in the file. The attack happens in the browser after the click.

"Click to Verify" Buttons

A professional-looking PDF tells the recipient they need to "verify their identity" or "confirm delivery" or "review the attached document." The button is a /URI annotation layered over a graphic element. It looks like a button. It behaves like a hyperlink to a phishing page. The recipient sees a document that looks official. They click. Their credentials are harvested in seconds.

Homograph Domain Tricks

The /URI target uses internationalized domain names (IDN) to create URLs that look identical to legitimate domains in the PDF but resolve to attacker infrastructure. The Cyrillic "a" (U+0430) is visually identical to the Latin "a" (U+0061) in most fonts. A URL that appears to point to accounts.google.com actually points to a completely different server. Your PDF reader displays the visual text. Your browser resolves the actual domain.

QR Codes to Credential Harvesting

The newest variant embeds a QR code in the PDF. "Scan with your phone to verify." The QR code points to a mobile-optimized phishing page. This bypasses desktop security tools entirely because the attack vector shifts from the computer to the phone, which typically has fewer security controls. The PDF itself is clean. The QR code is just an image. The attack surface is the user's phone.

Every one of these campaigns succeeds because the PDF format is trusted implicitly. Your email gateway passes it through. Your PDF reader opens it without inspection. The attack chain relies on that trust. For organizations that want to understand their exposure, a penetration test that includes social engineering scenarios will reveal exactly how many employees click.

What Your Current PDF Reader Does Wrong

Adobe Acrobat Reader is installed on over 500 million devices. It is the default PDF reader for most enterprises. It is also the largest attack surface you voluntarily install on every endpoint in your organization.

Here is what Adobe Reader does by default:

Executes /OpenAction JavaScript immediately. The moment you open a PDF, any JavaScript defined in the document's open action runs. Adobe Reader includes a full JavaScript engine. It supports file system access, HTTP requests and application-level scripting. This engine has been the target of dozens of critical CVEs over the past fifteen years.
Renders embedded JavaScript in form fields. Even without /OpenAction, JavaScript embedded in form fields, page actions and annotation triggers executes during normal document interaction. Scrolling past a page, hovering over an annotation or clicking a form field can trigger code execution.
Ships with a 300+ MB attack surface. Adobe Reader is not a document viewer. It is a full application platform with support for 3D rendering, multimedia playback, digital rights management, cloud storage integration and a JavaScript runtime. Every one of these features is an attack surface. The more code that runs, the more bugs exist.
Requires an Adobe Cloud account. As of 2024, Adobe Reader prompts users to sign in with an Adobe ID. This means your PDF reader maintains a persistent authenticated session to Adobe's cloud infrastructure. Your document viewing activity is tied to a cloud account that stores metadata about what you open and when.
Phones home on launch. Adobe Reader checks for updates, validates licenses and sends telemetry data on every launch. This means outbound network traffic is normal and expected behavior. An attacker who compromises the update mechanism or spoofs the telemetry endpoint has a direct channel into every endpoint running Reader.

The fundamental problem is the security model. Adobe Reader was designed to execute everything the PDF specification allows and then patch the vulnerabilities as they are discovered. This is a reactive model. You are always one undisclosed CVE away from compromise.

This is the same philosophy that makes kernel-level vulnerabilities so dangerous: the assumption that the software will behave correctly until proven otherwise. The proof usually arrives in the form of an incident.

A Different Approach: Sherlock Forensic PDF Editor

We built Sherlock Forensic PDF Editor because we got tired of telling clients their systems were compromised by a PDF attachment and then watching them go back to using the same reader that let it happen.

Sherlock Forensic PDF Editor takes the opposite approach to Adobe Reader. Instead of executing everything and patching later, it executes nothing by default and lets you decide what to allow.

Safe-by-default Rust parser: The PDF parser is written in Rust with no unsafe blocks in the parsing pipeline. Memory safety is enforced at compile time. Buffer overflows, use-after-free and type confusion bugs that plague C/C++ PDF parsers are structurally impossible. The parser rejects malformed PDF structures rather than attempting to render them.
Threat Inspector panel: Before the document renders, the Threat Inspector displays every /OpenAction, /Launch, /SubmitForm, /URI, embedded file and JavaScript block in the PDF. You see the threat surface before you see the content. Each item is flagged with a severity level. You can remove dangerous elements with one click or allow them individually.
Zero outbound network traffic: Sherlock Forensic PDF Editor makes zero network connections. No update checks on launch. No telemetry. No cloud account. No license validation calls. If a PDF tries to trigger a /URI action or a /SubmitForm submission, it is blocked and logged. The application is completely air-gapped by design.
12 MB single executable: The entire application ships as a single 12 MB .exe file. No installer. No runtime dependencies. No .NET framework requirement. No Java. Copy it to a USB drive and run it on any Windows machine. The small footprint means a small attack surface. There is less code to exploit because there is less code.
$29/year vs. $240/year: Adobe Acrobat Pro costs $19.99/month ($240/year). Sherlock Forensic PDF Editor costs $29/year for a single-user license. For organizations that deploy PDF readers across hundreds of endpoints, the cost difference is significant. But the real value is not the price. It is the reduced incident response cost when your PDF reader stops being the entry point for attacks.

This is not a stripped-down viewer. Sherlock Forensic PDF Editor supports full editing, annotation, form filling, digital signatures and redaction. It does everything you need a PDF editor to do. It just refuses to execute code without your explicit consent.

Self-Check: Is Your PDF Workflow Secure?

Answer these questions honestly. If you answer "no" or "I don't know" to more than two, your PDF workflow is a liability.

Do you know what happens when you open a PDF? Can you describe what /OpenAction directives your reader executes? If not, you are running code blindly on every document you receive.
Does your PDF reader show you embedded JavaScript before executing it? If your reader executes JavaScript without showing you the code first, every PDF you open is a potential compromise.
Does your PDF reader make network connections? Open your firewall logs. If your PDF reader phones home on launch, it has an attack surface you cannot control.
Can you inspect a suspicious PDF without rendering it? If you have to open a PDF to determine if it is safe, your inspection process is the attack. You need a reader that inspects before it renders.
Do you have a policy for PDF attachments from unknown senders? If your employees open every PDF that arrives in their inbox, your phishing training has a gap that costs real money when it fails.
When was your last penetration test that included PDF-based social engineering? If the answer is "never," you do not know how your organization responds to the number two malware delivery vector.
Does your incident response plan cover PDF-delivered malware? If a weaponized PDF lands in your CEO's inbox tomorrow, do you have a documented process for containment and forensic analysis?

If those questions made you uncomfortable, good. That discomfort is the gap between what you assume about PDF security and what is actually happening on your endpoints every day.

Get a baseline on your overall security posture with our free security scorecard. It takes five minutes and covers more than just PDF risks.