How PDF tools get exploited: a software engineer's look at the attack surface

PDF looks like the most boring file on your computer. Under the hood it’s anything but. I write software as well as practice law, and from an engineer’s seat the PDF is one of the largest, gnarliest attack surfaces in everyday computing. It quietly carries fonts, images, scripting, embedded files, and even whole XML forms. Every tool that opens one inherits that complexity, and complexity is where bugs live. Here’s how PDF tools actually get exploited, and what genuinely reduces the risk.

Why PDF is such a big attack surface

A PDF isn’t a document so much as a container. The specification runs to hundreds of pages, and a single file can embed subset fonts with their own hinting programs, multiple image codecs, JavaScript, interactive forms (the XML-based XFA), other files attached wholesale, and instructions inherited from PostScript’s Turing-complete past. To open one, a tool has to parse all of that, from a file it did not create and cannot trust. That is the textbook definition of a dangerous boundary: complex parser, untrusted input. Decades of those parsers were written in C and C++, where a single mishandled length field becomes a memory-corruption bug.

Where the exploits actually live

They cluster into a few families. Knowing them is most of the battle:

Memory-safety bugs in the parser/renderer. The classic remote-code-execution path: a malformed object, font, or image overflows a buffer and the attacker lands code. Reader and engine vulnerabilities like this have shown up for years across desktop and server tooling, and not only in old C code. Mozilla’s pdf.js had CVE-2024-4367, where a crafted font let a PDF run arbitrary JavaScript in the page that opened it. Even modern, sandboxed, JavaScript-based parsers get caught.
Active content inside the file. PDFs can embed JavaScript, “launch” actions, and attached files. Viewers that honor those features turn a document into a small program, which is exactly what malware authors want.
Server-side conversion stacks. This is the one web engineers underestimate. “HTML to PDF” renderers (wkhtmltopdf, headless browsers) will happily follow file:// URLs or internal addresses if you let untrusted input reach them, turning a PDF generator into local-file disclosure or server-side request forgery (SSRF) against cloud metadata endpoints. PostScript/PDF pipelines built on Ghostscript have repeatedly had sandbox bypasses, such as CVE-2023-36664. And anything parsing the XML in forms can be hit by XXE.
Resource exhaustion. Deeply nested objects and compression “bombs” (a few kilobytes that expand into gigabytes) can knock over a service that didn’t set limits. It is a denial-of-service with almost no effort.

A recent example: the Adobe Reader zero-day (CVE-2026-34621)

None of this is hypothetical. In April 2026, Adobe shipped an emergency fix for CVE-2026-34621 (CVSS 9.6), a flaw in Acrobat Reader’s JavaScript engine that was reported as a prototype-pollution bug. Researchers at EXPMON found it had been exploited in the wild since at least December 2025, and the earliest sample dates to late November. Simply opening a crafted PDF was enough: the file ran obfuscated JavaScript, pulled further payloads from a remote server, and harvested local data, with the chain reaching toward full remote code execution and a sandbox escape. The lures were Russian-language oil-and-gas documents, so this was a targeted campaign rather than a smash-and-grab.

It captures the whole problem in one incident. The victims didn’t do anything reckless. They opened a PDF in a mainstream, fully patched reader, and a logic bug in the tool’s scripting engine turned “view a document” into “run an attacker’s code and exfiltrate my files.” And notice whyit could steal local files at all: a desktop reader runs with your user account’s access to the filesystem. A PDF tool confined to a browser tab can’t reach your disk to begin with, so the same sandbox boundary that makes “just open it” so dangerous on the desktop is what contains it on the web.

The part most people miss: uploading hands your file to someone else’s parser

When you drag a document into an online PDF tool, two things happen at once. Your data goes to a third party, which is the privacy story I and others have written about. But you’re also feeding your file into a server-side parsing stack you don’t control and can’t see. If that internet-exposed service is running an unpatched engine, your upload sits in the same blast radius as everyone else’s when it’s attacked. You inherit both their vulnerabilities and their data handling, with zero visibility into either.

Does client-side processing fix it?

Honestly: not magically, and I’d distrust anyone who says otherwise. Your browser still has to parse the PDF, and as the pdf.js example shows, client-side libraries have bugs too. What changes is the blast radius:

No server-side surface. There’s no shared, internet-facing service to SSRF, no other tenants’ files to read, no multi-tenant storage to breach. The whole category of server exploits simply doesn’t apply.
The work runs in a hardened sandbox. A browser tab (and a WebAssembly module inside it) executes with no filesystem and no network access by default. That is a dramatically smaller cage than a server process with a real OS underneath it.
Your file never leaves the device. It’s never queued, logged, cached, or backed up by a stranger. The only machine that touches it is the one you already trust enough to be reading this on.

That’s the design choice behind QuietPDF: it compresses, merges, and extracts text fromPDFs entirely in your browser tab, with nothing uploaded. It doesn’t make PDF parsing risk-free, because nothing does, but it deletes the entire server-side half of the problem and keeps your documents off other people’s infrastructure.

If you build or pick PDF tools

A short checklist I’d hand any team, or use to judge a tool before trusting it with a file:

Treat every PDF as untrusted input. Parse in a sandbox or an isolated, least-privilege process. Never let the parser reach the filesystem or network unless it truly must.
Disable active content. Turn off JavaScript, launch actions, and external-entity resolution unless you have a concrete reason not to.
Block the SSRF paths. For any HTML/URL-to-PDF step, deny file://and private/link-local IP ranges, and don’t let user input pick the fetch target.
Set hard resource limits. Cap memory, time, and output size so a decompression bomb fails closed instead of taking the box down.
Patch the engine, and prefer memory-safe ones. Most PDF RCEs are old bugs in unpatched libraries; keeping current is the cheapest defense there is.
Minimize what leaves the device. The file you never upload is the one nobody else can mishandle.

For the document-level companion to this, covering whether a PDF itself can carry malware and the risks of uploading, see can a PDF have a virus? and is it safe to compress a PDF online?

Two habits sit outside the file itself but cover the same threat model: a VPN to encrypt the connection you fetch and send documents over, and a password manager so one leaked credential can’t open everything else. The ones I use are NordVPN and NordPass; there’s more on why on the privacy toolkit page.

These are affiliate links: if you sign up through them, QuietPDF may earn a commission at no extra cost to you. We only suggest tools that fit the same privacy-first habit as the rest of the site.

General security information, not a vulnerability assessment of any specific product. The CVEs referenced are illustrative and current as of mid-2026; check vendor advisories for the state of any tool you actually rely on.