How malicious PDFs actually work, and how to spot one

9 September 2026

Why PDF, specifically

Attackers keep coming back to PDF for a simple reason: nobody is suspicious of it. An .exe attachment gets blocked or side-eyed by anyone who has used a computer since 2005. A PDF invoice, HR form, or shipping notice does not. Security researchers have consistently found PDF among the most common file types carried in phishing and malware email over the past several years, not because the format is unusually broken, but because it is unusually trusted.

The format also happens to be flexible in ways most people never see. A PDF is not just text and images — it is a container that can hold JavaScript, launch actions, embedded files, forms that submit to a URL, and encrypted streams. Almost none of that is visible when you look at a page. It sits in the document's object structure, waiting for a reader to interpret it.

The techniques that actually get used

Embedded JavaScript. A PDF can carry a script that runs the moment the file opens, using the same /JS object type that lets a form auto-fill a date or validate a field. That same mechanism can trigger a download or exploit a bug in the reader. This was the dominant technique for years, but it has a weakness for attackers: it is loud. Modern readers and mail scanners are good at flagging PDFs that carry active script, so this approach has become less common as defenses caught up.

Auto-launch and open actions. Separate from embedded JavaScript, a PDF can define an action that fires automatically when the document opens or a page is viewed — launching another file, opening a URL, or submitting a form in the background, all without any click from the person reading it.

Hidden or disguised links. This is where most current attacks actually live. A button, an image, or a block of text can carry a link to a credential-harvesting page while displaying something entirely different — a company logo, a “View Invoice” button, a blank-looking area. Because the visible content and the underlying action are two separate things in a PDF, what you see is not a reliable guide to where a click goes.

QR codes. A newer and effective variant: instead of a clickable link a scanner might flag, the PDF contains a QR code as an image. A person scans it with their phone, which is usually outside the reach of whatever security software is watching their laptop, and lands on a phishing page from a device with fewer protections.

Password-protected PDFs, used against the scanner rather than the reader. Encrypting a PDF with a password that is handed to the victim separately (“password is the invoice number”) means automated mail-scanning tools cannot look inside the file at all. The human still can, because they were given the password.

Steganography. The most recent shift: hiding a payload inside the pixel data of an image that already looks completely ordinary — a signature block, a company logo — rather than anywhere a text-based scanner would think to look.

The social engineering matters as much as the technical part

None of the above works without a reason to open the file in the first place. The envelope is almost always the same handful of stories: an invoice that needs urgent payment, a delivery that failed, a document requiring a signature, a final notice before some account is suspended. These work because they are mundane. Nobody double-checks a shipping notice the way they'd double-check a message claiming to be from a foreign prince.

What has changed recently is the polish. The grammar mistakes and slightly-wrong logos that used to give phishing away are far less reliable tells now that generating convincing, personalized documents is cheap. Judging a PDF by how professional it looks is no longer a safe test.

What actually reduces the risk

Keep your PDF reader current. Most reader-side exploits target a specific, already-known bug, and the fix usually shipped months before the attack using it shows up.

Turn off JavaScript in your PDF reader's settings unless you specifically need interactive forms. Most people never touch this setting and never need to.

Treat any PDF that asks you to click something, scan something, or enable something as the more dangerous category, distinct from one you are simply reading. Opening a static document and being asked to act on it are different levels of risk.

Verify unexpected invoices or notices through a channel the document did not provide — call the company using a number you already had, not one printed in the PDF.

Be specifically wary of a PDF that requires a password to open that you were given separately, if you were not expecting a protected document from that sender.

Where a tool like Doxly fits, and where it does not

It is worth being precise about this rather than overselling it. Doxly's tools work by reading and rewriting PDF objects directly with a manipulation library, not by rendering the document the way a PDF reader or viewer does. Merging, splitting, or compressing a file through Doxly does not execute embedded JavaScript or trigger an open action, because nothing in that pipeline interprets those parts of the file as instructions. That is a genuine, structural difference from opening the same file in a full reader.

That is not the same as malware protection, and it would be dishonest to describe it that way. It does not tell you whether a file is safe, does not scan for known malware signatures, and a file can still carry a phishing link that leads somewhere bad after you open the result. For that reason we built a separate, plainly-scoped PDF Safety Check that looks for exactly the structural red flags described above — embedded scripts, auto-launch actions, embedded files, suspicious link actions — and tells you what it found. It is a heuristic check, not an antivirus scanner, and it says so.