There’s a phrase you’ll see in security news every few months: “attackers are exploiting a vulnerability in PDF files.” It’s a slightly misleading way to put it, and the correction is genuinely useful.
The vulnerability is almost never in the file. It’s in the program that opens the file.
That distinction changes what you should do about it. If the danger lived in the document, you’d need a way to clean documents. Because it lives in the reader, the things that help are the ones that make your reader a harder target — and there are only about four of them worth bothering with.
If you haven’t read it yet, can a PDF contain a virus covers the simpler half of this story: the harmful things a PDF can do using entirely normal features. This article is about the harder half.
Why PDF readers are such a tempting target
Showing you a page of a PDF sounds like one job. It’s actually dozens.
To put that page on your screen, the reader has to unpack compressed data, decode any images (which might be in half a dozen different formats), install and interpret the embedded fonts, work out the layout, handle transparency and colour, and build any form fields. Each of those steps is handled by a different chunk of code. Each one accepts whatever the file gives it.
Fonts are worth pausing on, because they surprise people. An embedded font isn’t a picture of some letters — it’s closer to a tiny program describing how to draw each character. Your reader runs that description. Image decoders are similar: complex, built for speed, and expected to cope with damaged files without crashing.
So a PDF arrives from a stranger and gets fed straight into a dozen pieces of complicated software. That’s the attack surface, and it’s why this has been a productive target for attackers for twenty years.
It also explains a piece of advice that sounds sensible but isn’t much help: “just don’t click any links in the document.” The risky part usually happens while the page is being drawn — before there’s anything to click.
How an exploit actually works
You don’t need the technical detail to make good decisions, but the rough shape is useful because it explains why some precautions work and others only feel like they do.
An attack has three parts.
Something malformed — a font with an impossible size written in it, an image whose dimensions don’t add up, a structure nested far deeper than anyone anticipated. Its only job is to confuse the reader’s code.
The confusion itself — the code ends up writing to a part of memory it shouldn’t touch. On its own, this usually just crashes the program.
Turning the crash into control — this is the hard part, and it’s where scripting inside the document earns its place. The script isn’t the attack. It’s the tool that arranges memory into a predictable state first, so the crash lands somewhere useful instead of just killing the program.
That third step is the practical takeaway. Turning off scripting in your reader doesn’t fix a single underlying flaw — and it still makes attacks substantially harder, because it takes away the most convenient tool for making an unreliable trick work reliably.
Why “just scan it” isn’t enough
A reasonable question at this point: can’t security software just look inside the file and spot the bad part?
Sometimes. But the PDF format offers several completely legitimate ways to make a document harder to inspect. Content can be compressed several times over, so a word only appears after repeated unpacking. Names can be written in an alternative notation, so a scanner searching for one spelling misses another that means the same thing. Parts of a file can be tucked inside compressed bundles that a simple search never opens.
None of that is a flaw. It’s all in the specification, and there are ordinary reasons for every one of those features. It just means that inspecting PDFs properly requires software that genuinely takes the file apart, rather than searching through it — which is a real limitation on simple scanning, not a reason to distrust your antivirus.
What to do, in order of how much it helps
1. Install reader updates promptly. This is the one that actually removes vulnerabilities rather than making them harder to reach. If you do nothing else on this list, do this. Adobe, Foxit and the browser makers all ship security fixes regularly, and attacks overwhelmingly target flaws that were patched months ago.
2. Turn scripting off. Preferences → JavaScript in Adobe Acrobat Reader. It doesn’t close the hole; it removes the ladder.
3. Leave the sandbox switched on. Modern Acrobat Reader, Chrome and Firefox all open PDFs inside a restricted area, walled off from the rest of your computer. If it’s called “Protected Mode”, “Protected View” or similar, leave it alone. A successful attack then has to escape that box before it means anything — a second problem, and a much harder one.
4. Switch off the extras you never use. 3D content, embedded video, automatic form submission. Every optional feature is another piece of code handling input from strangers. If you’ve never knowingly used one, you lose nothing by disabling it.
And one thing to stop doing: treating conversion as cleaning. Running a suspicious PDF through a converter still means feeding it to software that has to read it first. You’ve changed which program takes the risk, not whether the risk exists.
What this looks like when it goes wrong
It’s worth being clear about what a successful attack actually achieves, because the mental image is often either too dramatic or too vague.
You open a document. It displays normally — that’s the point, since a file that crashed your reader would prompt questions. In the background, code the attacker supplied is now running with your permissions. Not administrator rights, necessarily, but yours: your documents, your saved passwords, your network connections.
From there it’s a foothold rather than a finale. The usual next step is to fetch something larger from the internet, establish a way back in that survives a reboot, and go quiet. The damage that gets reported months later — the ransomware, the drained account, the leaked archive — often traces back to a document someone opened without noticing anything at all.
Which is why “nothing happened when I opened it” is not evidence of much. Nothing happening is the intended experience.
Where working offline helps — and where it doesn’t
I built PDF Manipulator because I wanted my own documents to stop travelling to servers I don’t control. That’s the honest scope of what local processing gives you: no copy on a converter’s hard drive, no privacy policy to read, no data breach at a company you used once in 2023.
What it doesn’t give you is protection from a malicious document. Any program that processes a PDF has to read it first — mine as much as anyone’s. Local processing is a privacy guarantee, not a security scanner, and anyone who tells you otherwise is selling something.
Two questions, two answers. Who else ends up with a copy of this file? — working locally handles that one. Is this file trying to attack my computer? — updates, a sandbox, and a little suspicion handle that one.
The short version
PDF exploits target your reader, not your document. That’s good news, because it means the fix is on your side of the screen: keep the reader updated, turn off scripting, leave the sandbox on. Three settings, ten minutes, and the overwhelming majority of this problem stops being yours.
Work with your PDFs without uploading them anywhere — PDF Manipulator is free →
Sources
- Didier Stevens, PDF Tools
- Didier Stevens, Malicious PDF Documents Explained, Black Hat EU 2012
