Ghostscript Vulnerability CVE-2026-39919: How a PDF Upload Reaches Your CMS Server

A Ghostscript vulnerability, CVE-2026-39919, lets a crafted PDF corrupt memory on the server that turns it into a thumbnail. Artifex fixed it in Ghostscript 10.08.0, released September 8, 2026. The public write-up came on October 13, when BleepingComputer reported that Wordfence had shown how a PDF upload to WordPress can reach the flaw.

Most CMS sites never call Ghostscript on purpose. They reach it through ImageMagick, which hands PDFs to Ghostscript whenever a site makes a preview image. WordPress does this for PDFs in the Media Library. Drupal sites can do it through the ImageMagick toolkit and PDF preview modules. This piece covers what the Ghostscript vulnerability is, how to tell if your server runs Ghostscript, how to patch it, and what to switch off if you cannot patch today. Facts are as of October 14, 2026.

The short version: update the Ghostscript package on every server that accepts PDF uploads. On Debian and Ubuntu, the fixed package keeps an older version number, so check the full package version as well as gs --version. If you cannot patch yet, block PDF handling in ImageMagick’s policy file or turn off PDF thumbnails in WordPress. No plugin or module update fixes this, because the flaw sits in a server package.

What the Ghostscript vulnerability is

Ghostscript is the open source PDF and PostScript interpreter from Artifex. The Ghostscript vulnerability is in the code that decodes JPEG 2000 images inside a PDF.

The VulnCheck advisory describes a heap-based buffer overflow. A PDF carries a JPEG 2000 image whose color components use mismatched subsampling factors. Ghostscript sizes a row buffer for packed output, then writes a full byte per column. The overflow corrupts the memory allocator, which can lead to code execution.

The fix commit is a small change to one file, seven lines added and three removed. Its message credits Alex Thomas of Wordfence Argus, Wordfence’s AI-assisted research system, with the report.

Key facts:

• CVE: CVE-2026-39919, published September 15, 2026.
• Affected: Ghostscript before 10.08.0. BleepingComputer, citing Wordfence, narrows it to 9.21 through 10.07.1.
• Fixed: Ghostscript 10.08.0, plus backported fixes in distribution packages.
• Severity: CVSS 4.0 score of 9.3 from VulnCheck. Ubuntu also lists a CVSS 3.1 score of 9.8.

Is the Ghostscript vulnerability being exploited?

Not that anyone has reported. According to BleepingComputer, Wordfence has not seen attacks in the wild.

Wordfence did build two proof-of-concept exploits. It ran them 10,240 times against Linux distribution packages and did not get code execution. It did get code execution on a test server built for the purpose, though not every time.

Patch soon. The research is now public, and the fix commit shows where the bug is.

The scores also disagree. Red Hat rates it Moderate at 7.8, because someone has to process a crafted PDF. On a website that makes previews of every upload, the upload itself is that step. For CMS servers, treat it as high priority.

How a PDF upload reaches Ghostscript in WordPress and Drupal

WordPress has made PDF previews since version 4.7. The WordPress core announcement says the previews come from the Imagick image editor. They need the PHP Imagick extension, ImageMagick and Ghostscript on the server. When all three are present, WordPress renders the first page of each PDF in the Media Library as an image.

BleepingComputer lists four conditions for an attack on WordPress:

1. An attacker can upload a PDF, either anonymously or with a low-level account.
2. The site makes a preview or thumbnail from it.
3. The processing reaches Ghostscript.
4. The vulnerable decoding code is still on the server.

Stock WordPress does not allow anonymous Media Library uploads. The risk comes from plugins and roles that let more people upload. Think of membership sites where members can post files, job boards that accept resumes, abstract and award submission forms, and document libraries.

Drupal works the same way through a different path. The ImageMagick module lets Drupal’s image system use ImageMagick. Its project page says Ghostscript must be installed if PDF or PostScript support is needed. Core Drupal image styles do not turn PDFs into images on their own. A Drupal site is exposed when a contributed module makes PDF previews through ImageMagick or Ghostscript.

How to tell if your site uses Ghostscript

Start with the server. If Ghostscript is not installed, the flaw cannot be reached through it.

WordPress fills that Site Health line by running gs --version. If the host blocks PHP’s exec function, it shows that it cannot tell. In that case, ask the host or check from a shell.

A quick practical test is to upload a small PDF to the Media Library on staging. If a preview image appears, the full chain is in place. If you see only a generic document icon, WordPress did not reach Ghostscript for that file.

How to patch the Ghostscript vulnerability

The fix for the Ghostscript vulnerability goes into the operating system or the container image. A WordPress plugin or a Drupal module update does not change the Ghostscript package.

Debian and Ubuntu backport the fix into older version numbers. An Ubuntu 24.04 server can report Ghostscript 10.02.1 and still be patched. Compare the full package version with the table below.

The Ubuntu rows come from the Ubuntu CVE page, which points to USN-8791-1. The Debian rows come from the Debian security tracker. Red Hat’s page did not show its errata list when we checked, so confirm your RHEL release in the Red Hat Customer Portal.

Debian 12 matters for agencies. Many older WordPress and Drupal servers still run it, and it had no fixed package on October 14. Those servers need the mitigations in the next section until a fix ships.

For Docker deployments, rebuild from a patched base image and redeploy. Wordfence found the vulnerable code in an official WordPress Docker image snapshot, according to BleepingComputer. A running container does not pick up host updates.

On managed platforms such as Pantheon or WP Engine, the host controls the server packages. The fix is theirs to install. Check their status page or ask support for a statement on CVE-2026-39919, and keep the reply in the client file.

Short-term mitigations if you cannot patch today

There are two levels. The ImageMagick policy blocks PDF processing for everything on the server. The WordPress filter stops WordPress core from making PDF previews. Use the first if you can.

Block PDF in ImageMagick’s policy file. ImageMagick reads a policy.xml file that can deny whole formats. On Debian and Ubuntu, it usually sits in /etc/ImageMagick-6/. The identify -list policy command shows the exact path. Add a line inside the <policymap> block:

<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,PDF,XPS}" />

This uses the coder syntax from the ImageMagick security policy guide. It covers PDF and the other formats ImageMagick hands to Ghostscript. Restart PHP-FPM or Apache afterward, then test a PDF upload on staging. Check first whether your policy file already has a rule like this.

Turn off PDF previews in WordPress. The fallback_intermediate_image_sizes filter sets which image sizes WordPress makes for PDFs. Returning an empty array stops them. WordPress core then skips loading the PDF into the image editor at all. Put this in a small must-use plugin:

add_filter( 'fallback_intermediate_image_sizes', '__return_empty_array' );

This covers WordPress core only. A plugin that builds its own PDF previews through Imagick can still reach Ghostscript, so the policy file is the broader fix. Previews already created stay in place.

Limit who can upload PDFs. Review which roles and forms accept PDF files. Remove upload rights that are no longer needed. We covered this kind of review after the WordPress file upload flaws under attack in September, and the same audit applies here.

What this means for Drupal sites

Drupal sites with PDF previews need the same server patch. The Drupal version does not matter for this Ghostscript vulnerability. Check composer.json for ImageMagick, Imagick or PDF preview modules, then run the server checks above.

This also lands in the same weeks as other Drupal patching. The Drupal core security release on October 14 still needs to go out on many sites. Bundle the Ghostscript check into that maintenance window.

We explained the deadline in what Drupal 10 end of life means for your site. For the questions to send a vendor, see our plain-language Webform advisory guide.

A Ghostscript vulnerability checklist for agencies

1. List every server that accepts PDF uploads: WordPress, Drupal, document libraries, job boards, submission systems.
2. Run the checks in the table above on each one, and record the package version.
3. Patch the package or rebuild the container image. Debian 12 servers have no fix yet, so they go to the next step.
4. Apply the policy file rule on any server you cannot patch this week.
5. Ask managed hosts for a written answer, and keep it.
6. Review upload rights for members, applicants and anonymous visitors.

Association, nonprofit and university sites tend to collect PDFs from people they do not know. Abstracts, resumes, grant applications and award nominations all arrive that way. That is the same exposure pattern as the Gravity Forms upload flaw, one layer further down the stack.

Frequently Asked Questions