Wordfence Argus Discovers Critical Vulnerability in Ghostscript, the Program That Turns Uploaded PDFs into Thumbnails on Your Server

On September 8, 2026, Artifex released Ghostscript 10.08.0, closing a critical heap buffer overflow that the Wordfence Threat Intelligence team, using Wordfence Argus, discovered and reported sixteen days earlier. It is tracked as CVE-2026-39919 and carries a CVSS score of 9.8 out of 10. A crafted PDF containing a JPEG 2000 image can make Ghostscript write attacker-influenced bytes past the end of a memory buffer. We developed that corruption into unauthenticated remote code execution on a purpose-built WordPress test site.

If you run a WordPress site, there isn’t a WordPress plugin to update. Ghostscript is supplied by the operating system or the container image, so most site owners will get the fix through their distribution or hosting provider. Containerized sites need to be rebuilt and redeployed from an updated base image. We tested ten Linux package environments on September 15, and the official WordPress Docker image snapshot we tested was one of the vulnerable ones.

Wait, what’s Ghostscript, and what does it have to do with WordPress?

Ghostscript is a document engine. It reads PDF and PostScript files and turns their pages into images that other software can display, print, or preview. It sits underneath many applications that never mention Ghostscript by name, which is why many site owners run it without knowing they do.

WordPress does not render PDF previews itself. Since WordPress 4.7, core can generate an image of a PDF’s first page when it creates attachment metadata. On a server using the PHP Imagick extension, WordPress calls ImageMagick, which then launches Ghostscript to render the PDF.

The chain is WordPress, then Imagick, then ImageMagick, then Ghostscript. Ghostscript runs as a separate program, usually under the same account as the web server. It only starts when something asks for a picture of the PDF. A form that saves an uploaded file to disk and does nothing else with it never starts Ghostscript. A form that adds the file to the Media Library can start it when WordPress builds a preview, provided the required software and policy settings are in place.

This is not a vulnerability in WordPress or in the form plugin we used for testing. WordPress and the plugin were simply how the file reached Ghostscript. The bug is in Ghostscript.

This is a critical CVSS 9.8 vulnerability. Should I be worried?

You should patch it, but the score describes a worst case rather than a guarantee.

The CVE record assigns a CVSS 3.1 score of 9.8 and a CVSS 4.0 score of 9.3. Those scores describe a network-facing application that accepts PDFs without a login or user action. They describe the possible impact, not whether a particular site exposes Ghostscript or whether one PDF will work against its build. Successful code execution runs with the permissions of the account processing the PDF, which is not automatically root access.

Modern systems randomize memory locations and lock down sensitive parts of a program. Those protections often turn memory corruption into a crash, but they do not fix the bug. On our purpose-built test server, we still reached code execution.

We also tested whether one exploit works everywhere. We built two working proof-of-concept exploits for our lab build, then ran them 10,240 times across ten other Linux package environments on 64-bit Intel and AMD systems: Debian, Ubuntu, Fedora, AlmaLinux, Alpine, and the official WordPress container. Neither succeeded once outside the matching build, while both continued to work on that build. We then kept the Ghostscript executable the same and changed fonts, language settings, font configuration, and one core system library. The same exploit still succeeded in all four setups, although it did not succeed on every attempt.

That makes the exact build important, but our experiment did not measure how easily an attacker could identify it remotely or how long adapting an exploit would take. A targeted attacker may have better information, and a hosting platform may expose the same build across many sites. On our purpose-built form, failed attempts returned a successful upload response while Ghostscript crashed in the background. Other sites may log, block, or rate-limit repeated uploads.

Our two files did not work unchanged across the mixed package set. That is strong evidence against treating either file as a universal exploit, but it does not rule out a different file or a set of files prepared for common builds. We did not measure package prevalence or remote build identification, so we cannot give a success rate across the Internet. Site owners should patch, especially if they accept public documents or run many sites from one shared image.

What HEIF Heist tells us about this vulnerability

Heap buffer overflows are sometimes dismissed as too unreliable to matter on modern servers. Memory randomization and other protections do make them harder to exploit, and a working exploit may need to be tailored to a particular software build. But harder is not the same as safe.

That is the important connection between this Ghostscript vulnerability, our earlier libheif finding, and Hacktron’s HEIF Heist research. Both Wordfence Argus findings are heap buffer overflows in native file-processing code that can be reached through an uploaded file. In both cases, our working code-execution exploit depended on the target build rather than serving as one universal payload.

HEIF Heist shows why that limitation should not be mistaken for protection. Hacktron used AI-assisted exploit development to turn a heap buffer overflow in libheif into reliable code execution against OpenAI’s Discourse forum. Its broader research found paths to code execution or data exposure in other real services and products, including Next.js applications. Hacktron reported that adapting an exploit to each new company usually took one or two days, even when the team initially knew little about the target environment. Some attempts required thousands of uploaded images, but the team still reached code execution or read data from server memory.

Our Ghostscript experiments point to the same threat model. The two files we built failed in 10,240 attempts across ten different package environments, but a build-matched exploit continued to succeed in all four setups that shared the exact Ghostscript executable. Attackers do not need one PDF that works everywhere if they can focus on a known target or many servers built from the same image. HEIF Heist does not prove that this exact Ghostscript flaw can be adapted in one or two days, and we have found no public evidence that it is being exploited today. It does show why the difficulty of exploiting a heap overflow is not a defense and should not delay patching.

Is my WordPress site affected?

If visitors or users with limited permissions can upload PDFs to your WordPress site, you should assume the site is affected until your host confirms otherwise. This attack reaches Ghostscript when WordPress or another tool creates a preview, thumbnail, or image from the PDF. If uploaded PDFs are only stored and never processed, this path is not exposed, but many site owners will not know what happens behind the scenes. Ask your hosting provider whether uploaded PDFs reach Ghostscript. If they do, use the package guidance below to confirm that the fix is installed.

Install the fixed Ghostscript package supplied by your operating system or hosting provider. Artifex fixed the flaw in Ghostscript 10.08.0, but Linux distributions often add the fix to the older version they already ship. That means gs --version may not tell you on its own whether you are patched. Ubuntu 22.04, for example, fixed this in package 9.55.0~dfsg1-0ubuntu5.14, which still reports Ghostscript 9.55.0. Check the full package revision using dpkg -s ghostscript on Debian and Ubuntu, or rpm -q ghostscript on Fedora and the Red Hat family. Install the fixed package and follow your vendor or host’s restart guidance. For containers, rebuild and redeploy from an updated base image rather than restarting the old container.

Your site can be attacked this way only if all of these are true at once:

1. A visitor, or someone with a low-privileged account, can upload a PDF
2. Something on your site then asks for a preview or thumbnail of that PDF
3. Your server has Imagick, or another tool that calls Ghostscript to make that picture
4. Your installed Ghostscript does not have the fix

Source history places the affected code in Ghostscript 9.21 through 10.07.1 when the OpenJPEG decoder path is present. All ten package environments we tested contained that path. A version in that range shows that the package was originally affected, but only the full package revision or your distribution’s advisory can tell you whether the fix was added later. What each system ships changes over time, so this table records the exact packages we tested on September 15:

For comparison, the final Ghostscript 10.08.0 release contains Artifex’s fix. The table covers only the dated distribution and container packages we tested, so the official 10.08.0 release is not included.

Our test PDF crashed Ghostscript on nine of the ten systems. Debian 12 rendered that particular file without crashing, but when we changed the dimensions inside the image and tried again, 28 of 40 of those variations crashed it too. A file that does not crash your server is not proof that your server is safe.

Since we ran those tests, fixed packages have shipped for several of these systems. Ubuntu has fixed 22.04, 24.04, and 26.04. Debian has fixed 13 through its security repository, while Debian 12 remains listed as vulnerable. AlmaLinux 10 published its fix on October 2.

As of October 9, the official package pages for Fedora 44, Alpine 3.22, and Alpine 3.23 still listed the older revisions shown in our table. Check your distribution’s advisory for the exact fixed package revision.

The release candidate for 10.08.0 also reports 10.08.0 and is not fixed, which is what our own test machine was running. Confirm you have the final release, or a distribution package that carries the fix.

The exact official WordPress Docker image snapshot we tested already contained the vulnerable Ghostscript package and the software needed to reach it. It contained Ghostscript 10.05.1, the Imagick extension, and a working PDF preview path. Stock WordPress still did not give anonymous visitors a way to upload a PDF for preview. An attacker would need a plugin, form, application route, or account that provides that path. If you use the official image, pull an updated base, rebuild without relying on a cached layer, and redeploy.

Site Health is only a starting point. Under Tools → Site Health → Info → Media Handling, WordPress can show whether Imagick recognizes PDF as a format. That does not prove ImageMagick’s policy permits PDF reads, and it does not tell you whether Ghostscript is patched. Your host, operating system package manager, or container supplier is the authority on the installed fix.

If you can’t patch immediately:

• Stop accepting PDFs from visitors and low-privileged users. This keeps those files from reaching the converter at all.
• Disable PDF reads in ImageMagick’s security policy. This also disables PDF previews.
• Limit the number of files per submission and rate limit upload forms. This reduces an attacker’s opportunities, but it does not close the vulnerability.

Regarding that last bullet point: if the first preview attempt fails, WordPress tries again with a different setting. If both attempts fail, WordPress returns an image-processing error; in our form-based test, the upload itself still returned success. This retry is part of WordPress core’s Imagick PDF loader and has been there since version 5.6, as a workaround for an old Ghostscript compatibility problem (Trac #48853). We measured one Ghostscript process for a harmless PDF and two for a crashing PDF. Three attachments produced six processes. Limiting files per submission therefore reduces the number of processing attempts an attacker gets in one request, but it does not fix the vulnerability.

Do not treat -dSAFER as a fix. Ghostscript’s sandbox restricts what a document is allowed to do through supported features. It does not prevent memory corruption, and our testing reached the flaw with the sandbox enabled.

Managed hosting customers can’t check most of this themselves. It’s reasonable to ask your host whether its Ghostscript package includes the fix for CVE-2026-39919, and whether PDFs uploaded by customers get turned into previews anywhere on its systems. High-value sites and groups of sites built from a shared image deserve particular attention, because many systems may present the same build to an attacker.

What this means for everyone else using Ghostscript

Nothing about this flaw is specific to WordPress. WordPress is one route that can deliver an untrusted PDF to Ghostscript, and the same question applies anywhere Ghostscript is used: does this software render PDFs that came from somebody else?

Document management systems, print services, invoice processors, preview generators, mail gateways, and conversion APIs can all do this. If any of them send untrusted documents to an affected Ghostscript build, treat the update as urgent. Searching your application code for the word “Ghostscript” may miss the dependency entirely, because ImageMagick or another library usually sits between the application and the converter.

If you cannot patch every system at once, run document conversion in a separate, locked-down service that cannot read site secrets or connect to anything it does not need. That limits what a compromised converter can reach, but it is not a fix.

Vulnerability Summary

Artifex Ghostscript 9.21 through 10.07.1 – Heap-based Buffer Overflow Can Lead to Remote Code Execution

9.8

CVSS Rating
9.8 (Critical)

CVSS 4.0 Rating
9.3 (Critical)

CVE-ID
CVE-2026-39919

Affected Upstream Version(s)
9.21 – 10.07.1

Upstream Fixed Version
10.08.0

Affected Software

Artifex Ghostscript [ArtifexSoftware/ghostpdl]

Researchers

Alex Thomas

Wordfence Argus

Artifex Ghostscript is vulnerable to a heap-based buffer overflow in its JPEG 2000 decoding path in versions 9.21 through 10.07.1, where the OpenJPEG decoder is present. A crafted PDF containing a JPEG 2000 image with sub-byte sample precision and mismatched component resolutions can write attacker-influenced bytes past the end of a heap buffer and overwrite memory-management data that Ghostscript later uses. In affected applications and server configurations, this can result in remote code execution, and the write occurs even when Ghostscript is run with -dSAFER. The CVE record states the affected range as “before 10.08.0”; the vulnerable sub-byte sampling block was introduced in 9.21. The vulnerability is fixed in Ghostscript 10.08.0.

More Details >

How we found it

We found this vulnerability with Wordfence Argus, our AI-assisted security testing system, during a WordPress 7.1 security assessment.

Argus followed an uploaded file past the PHP code that accepted it. For a PDF preview, that meant tracing the data through Imagick and ImageMagick into Ghostscript and the JPEG 2000 decoder below it. A visible upload handler can validate and store a file perfectly well while a system program mishandles it moments later.

The vulnerabilities that hurt WordPress sites don’t always live in WordPress itself. Some of them live several layers down, in software site owners never chose on their own, reached by a feature as mundane as uploading a document. Defending the platform properly means following the data all the way down. You can read more about Argus in our earlier post.

Our mission is to secure WordPress at every layer. That includes finding vulnerabilities in the software WordPress relies on, alongside our Bug Bounty Program.

How the bug actually works

You don’t need to know C to follow this.

An image is a grid of samples. A grayscale image has one brightness sample for each pixel. An image with transparency adds another set of samples describing how transparent each pixel is. JPEG 2000 calls each set a component.

JPEG 2000 lets those components differ. Components may have different resolutions, and each sample may use fewer than eight bits. With two-bit samples, four samples fit into a single byte.

A program reading an image asks the system for a block of memory big enough to hold it. That block is a buffer. If the program writes more data than the buffer can hold, the extra spills into memory beyond it, which may hold other data or the program’s own bookkeeping. That is dangerous, because corrupting nearby memory can change how the program behaves. If an attacker controls what gets written, they may be able to steer the program into running code of their choosing. This is a buffer overflow.

The bug appears when Ghostscript handles those two JPEG 2000 features together. In the minimal public test case, a row contains 1,024 two-bit samples. The correct packed size is 256 bytes, and Ghostscript correctly reserves 256 bytes. The loop that fills the row then writes one whole byte for each sample instead of packing four samples into each byte. It writes 1,024 bytes into a 256-byte buffer.

Imagine reserving 256 mailboxes because each one holds four small letters. That is enough room for 1,024 letters. The delivery loop forgets the four-per-box rule and puts one letter in each box. After 256 letters it keeps right on delivering, into whatever sits beyond the mailboxes.

In Ghostscript, what sat beyond them was bookkeeping used to manage allocated objects. The 768 bytes that spill out on each row are derived from image samples chosen by whoever made the file. They are constrained by the image format and by Ghostscript’s packing loop, but they can still corrupt memory addresses that Ghostscript follows later while cleaning up. That is how this flaw becomes more than a crash.

Artifex’s fix changes the loop so it counts samples correctly and rejects bit depths that this code path does not support.

The 1,029-byte public test file differs from a harmless control file by a single byte, in a field describing the transparency component’s resolution. Both are valid PDFs containing a valid JPEG 2000 image. The dangerous condition is buried in the image’s internal geometry, so ordinary checks of the extension, MIME type, or basic file structure do not identify it.

Timeline

Conclusion

Wordfence Argus found a critical heap buffer overflow in Ghostscript 9.21 through 10.07.1, several layers beneath an ordinary WordPress document upload. We did not stop after making the vulnerable program crash. On one exact WordPress deployment, we demonstrated that a crafted PDF could be turned into unauthenticated code execution on the server, with Ghostscript’s -dSAFER sandbox enabled.

The two proof-of-concept exploits we built did not work unchanged on ten other package environments, so this is not one universal PDF that can compromise every vulnerable server. The more credible threats are a targeted attack against a known build and an attack against many sites sharing one hosting or container image. Hacktron’s HEIF Heist research is a warning not to mistake that limitation for safety: AI-assisted researchers turned build-specific memory corruption in libheif into successful attacks against real services. That does not establish an exploitation timetable for this Ghostscript vulnerability, but our own tests showed that a matching exploit continued to work across all four setups that shared the exact Ghostscript executable. Build-specific exploitation is harder, not harmless.

This is exactly why we built Wordfence Argus. Securing WordPress means looking beyond WordPress core and plugins, then following untrusted data through every layer that handles it. In this case, Argus followed a document upload into a system program most site owners did not know they were running, found a critical vulnerability, and gave our researchers a path to prove what it could mean on a working WordPress test site.

Whether you’re exposed depends on your Ghostscript package and how your application handles documents. Install the fixed system package, follow your vendor or host’s restart guidance, and rebuild container images from an updated base. If you can’t update yet, stop untrusted PDFs from reaching Ghostscript.

Our thanks go to Ken Sharp and the Artifex team, who confirmed the report the day after we filed it and shipped the fix, and the VulnCheck team for a quick CVE assignment.

If you know someone running a site that accepts document uploads, please share this advisory with them.

The post Wordfence Argus Discovers Critical Vulnerability in Ghostscript, the Program That Turns Uploaded PDFs into Thumbnails on Your Server appeared first on Wordfence.