Processing Untrusted PDFs Safely: Sandboxing Ghostscript and Document Converters

A PDF upload is a file you asked someone else’s program to open. Usually that program is a thumbnail generator, a print pipeline or a conversion queue, and it runs with more access than anyone remembers granting. The question here is not whether the Ghostscript bug is serious. It is which layers between an uploaded file and your server actually stop it, and which ones only make the incident harder to explain.

Before you read: Our piece on How to Sandbox AI Agents makes the case for default-deny egress and for boundaries that sit outside the process being attacked. This article applies the same logic to a converter you did not write and cannot easily patch line by line.

Why now: On October 13, 2026, BleepingComputer reported a critical heap buffer overflow in Ghostscript’s interpreter and rendering engine, tracked as CVE-2026-39919, that can lead to remote code execution through a crafted PDF. Wordfence found it on August 23, and Artifex shipped the fix in Ghostscript 10.08.0 on September 8. The news is the trigger. The problem was already sitting in your PDF pipeline.

Table of contents

• Low Reliability Is Not Safety
• The Overflow Happens Below the Layers You Configure
• Layer 1: Patch, Then Verify the Patch
• Layer 2: SAFER Is a Fence, Not a Wall
• Layer 3: Give the Converter Nothing to Reach
• Layer 4: Put a Clock and a Page Count on Every Job
• Layer 5: Remove the Features You Are Not Using
• A Test Plan You Can Run Without the Exploit
• What Each Layer Buys You
• Fun Facts
• Sources

Low Reliability Is Not Safety

Wordfence’s two proof-of-concept exploits wrote 1,024 bytes into a 256-byte buffer, a fourfold overrun. Run in a lab against Linux packages, they executed 10,240 times without achieving remote code execution. They did succeed on a purpose-built test server, and changing fonts, language settings, font configuration and one core library helped, though not reliably.

Read that as a lab result, not a safety result. 10,240 failures comfort a maintainer. A patient attacker only needs one environment that happens to line up. Wordfence tested ten Linux environments, including an official WordPress Docker image snapshot, and found the vulnerable code in every one. Being in the default package set is the common condition, not the rare one.

Wordfence’s stated affected range is 9.21 through 10.07.1. Fixes were also backported to older branches, so check the revision details in your distribution’s advisory rather than comparing version numbers alone.

The Overflow Happens Below the Layers You Configure

The crafted PDF in this case carries a JPEG 2000 image, and the overflow sits in image decoding during rendering. It is not a PostScript operator. That distinction decides what each control can see.

In my reading of the Ghostscript documentation, SAFER works at the PostScript level, controlling file access, device selection and some device parameters. The same page says its file controls apply to everything going through Ghostscript’s C file interface, then adds that Artifex has no control over third-party code. A bounds error inside a decoder is not a file access. SAFER never gets a vote.

That does not make SAFER useless. It makes it a different tool, aimed at a different part of the attack. The table below is my reading of the sources, not a test result.

Control	What it acts on	Stops the overflow itself	Limits damage after code runs
Patch to 10.08.0 or a backport	The bug	Yes, for this bug	No
-dSAFER (default since 9.50)	PostScript file, device and parameter access	No	Partly, for file and device access the interpreter performs
Permit lists (—permit-file-read and friends)	Which paths can be read or written	No	Partly, for paths outside the list
Container with no network and read-only root	Network, filesystem view, processes	No	Yes, if configured tightly
Memory, process and time limits	Resources and runaway runs	No	Caps resource use and stops runaway runs
Disabling PDF in the ImageMagick policy	Exposure	Removes that route	Removes that route

Layer 1: Patch, Then Verify the Patch

Upgrade to 10.08.0 or later, or to a distribution backport that carries the fix. Then check what is actually running: dpkg -l ghostscript on Debian and Ubuntu, and gs --version on the binary itself.

Do the same check inside the image you deploy. The host and the container often ship different packages, and a stale base image is an easy way to believe you are patched when you are not.

Layer 2: SAFER Is a Fence, Not a Wall

SAFER has been the default since 9.50, and the docs say save and restore cannot undo it, unlike the old implementation. Once .activatepathcontrol runs, a later .addcontrolpath call is a fatal error. That is a good sign: the design is meant to lock, not negotiate.

The real work happens with the permit-list flags: --permit-file-read, --permit-file-write, --permit-file-control, --permit-file-all and --permit-devices. Here is the subtle one. Paths you pass on the command line, such as -I or -sFONTPATH, are added to the read list automatically. The font directory you pointed at for rendering is now readable by anything running in that process, including whatever an attacker managed to run. Audit those paths the same way you audit the upload path.

A conversion command that keeps the defaults visible:

gs -dSAFER -dBATCH -dNOPAUSE -dQUIET -dPDFSTOPONERROR -dFirstPage=1 -dLastPage=1 -dPDFFitPage -sDEVICE=png16m -r72 -sOutputFile=/work/out/thumb.png /work/in/upload.pdf

SAFER is already the default, so writing it down is for the reader. -dPDFSTOPONERROR stops on broken input instead of letting lenient parsing carry on. The page limits and -dPDFFitPage keep the job to the one page a thumbnail needs.

Layer 3: Give the Converter Nothing to Reach

Ghostscript writes temporary files to /tmp unless TMPDIR or TEMP overrides it. That is the only writable place a converter normally needs, apart from its output. Build the container around that fact:

docker run --rm --network none --read-only --tmpfs /tmp:rw,size=64m --memory 256m --pids-limit 32 --cap-drop ALL --security-opt no-new-privileges --user 65534:65534 -v $PWD/in:/work/in:ro -v $PWD/out:/work/out gs-converter:patched gs -dSAFER -dBATCH -dNOPAUSE -dQUIET -dPDFSTOPONERROR -sDEVICE=png16m -dFirstPage=1 -dLastPage=1 -sOutputFile=/work/out/thumb.png /work/in/upload.pdf

gs-converter:patched is a placeholder for your own image. Each flag removes something. --network none removes the route out, so an exploit’s callback has nowhere to go. --read-only and a small tmpfs leave one scratch space. --cap-drop ALL and no-new-privileges strip Linux capabilities and block privilege gain through setuid binaries. --memory and --pids-limit cap the damage from a process that goes off the rails. The input mount is read-only, so the converter cannot rewrite the file it was handed.

The critical point: containers share the host kernel. This configuration narrows what an attacker with code execution can reach. It does not turn the kernel into a wall, and a kernel bug is a different problem from this one. For high-volume untrusted input, the next step is a stronger boundary such as gVisor or a microVM, which puts a separate kernel between the converter and the host. I have not measured what this command blocks, and I would not make a claim about it until someone does.

Layer 4: Put a Clock and a Page Count on Every Job

A converter that runs forever is a denial of service with a nice logo. Wrap the call in a timeout, and set the number from your slowest legitimate document rather than a guess: timeout 20s gs ....

Process only what you need. Ghostscript renders only the requested pages when you give -dFirstPage, -dLastPage or -sPageList, so a thumbnail job should never touch page 400 of a scanned manual. Cap the upload size before Ghostscript starts. That check costs nothing and runs outside the process you are worried about.

Ghostscript’s current policy is to try to render broken PDFs and print a warning. That serves a person with a damaged invoice. On a public upload endpoint, it means the parser keeps going through input a stricter tool would refuse. -dPDFSTOPONERROR is the switch that makes it stop instead.

Layer 5: Remove the Features You Are Not Using

-dDOPS enables PostScript streams inside PDFs. The docs say it is not recommended for security-conscious applications, and it is off by default. The trap is the wrapper. Any script or library that launches Ghostscript can add flags you never typed, so grep the wrapper and the ImageMagick policy for DOPS and for PDF coders.

PDF was built to look the same on every screen. It can also carry PostScript streams, which is a programming language, and the switch that lets them run is off by default. Of all the reassuring defaults in this article, that one is the most reassuring.

If your site only needs PDF thumbnails for a media library, the cheapest control is to disable PDF in the ImageMagick policy. BleepingComputer lists it as a mitigation. It removes the route, not the bug, and it does nothing for direct Ghostscript calls.

A Test Plan You Can Run Without the Exploit

I am not publishing a harness for the public proof of concept, and you do not need one. Test the boundaries with benign files instead. Build two images in a lab: one patched, one pinned to a version you are trying to leave behind. Then run probes that ask for things a converter should never do:

1. A PostScript file that tries to read /etc/passwd with the file operator, for example (/etc/passwd) (r) file. Under SAFER it should be refused. Record the exact error.
2. The same probe for writing, first to /tmp and then to a path outside the write list.
3. A PDF with an excessive page count, to check that -dLastPage and the timeout behave as you expect.
4. A deliberately malformed PDF, to compare output with and without -dPDFSTOPONERROR.

Measure peak memory with /usr/bin/time -v and check the exit code when the timeout fires. Then do the thing the sandbox is supposed to make hard: compare what the process can reach from inside the container with what it can reach from a bare host shell.

Those results, not the flags listed here, should decide your configuration. I have not run any of these tests for this article, so treat every row of the table above as a hypothesis until your numbers replace it.

What Each Layer Buys You

The patch closes the hole. Everything else decides how much of the house leaves with the burglar. SAFER keeps the converter from opening the wrong files, the container keeps it from calling home, and the limits keep one bad document from holding a worker hostage. None of them stops the overflow. If you cannot keep a decoder patched on time, the honest option is to stop feeding it strangers’ files at all.

Fun Facts

• Four times over: The proofs of concept wrote 1,024 bytes into a 256-byte buffer, and the lab runs still failed 10,240 times.
• A default, not a boundary: SAFER has been on by default since 9.50, yet the docs say Artifex has no control over third-party code. Defaults protect the code their authors wrote.
• The temp directory is a decision: Ghostscript writes temporary files to /tmp unless told otherwise, so an unconfigured converter quietly chooses where its scratch files live.

Sources

• BleepingComputer, “Ghostscript flaw lets hackers hijack servers via PDF uploads” (October 13, 2026): https://www.bleepingcomputer.com/news/security/ghostscript-flaw-lets-hackers-hijack-servers-via-pdf-uploads/
• Ghostscript documentation, Use (version 10.09.0 docs, last updated October 13, 2026): https://ghostscript.readthedocs.io/en/latest/Use.html