Ghostscript vulnerability puts PDF previews at risk

A Ghostscript vulnerability fixed in version 10.08.0 can allow remote code execution when an affected server processes a specially made PDF containing a JPEG 2000 image, according to Wordfence Threat Intelligence research.

The flaw is tracked as CVE-2026-39919 and has a CVSS 3.1 severity score of 9.8 out of 10. The CVE record also assigns a CVSS 4.0 score of 9.3. Artifex released Ghostscript 10.08.0 on September 8, 2026, after Wordfence reported the issue sixteen days earlier. Wordfence says the bug is a heap buffer overflow, a memory error where a program writes beyond the space it reserved, in Ghostscript’s JPEG 2000 decoding path.

Ghostscript is a document engine used to read PDF and PostScript files and turn pages into images for previewing, printing or conversion. Many website owners may never install it directly, because it is often pulled in by the operating system, a container image or another tool. In a common WordPress path, WordPress uses the PHP Imagick extension, Imagick calls ImageMagick, and ImageMagick launches Ghostscript to render a PDF preview. Wordfence stresses that this is not a WordPress core or form plugin vulnerability. WordPress and the test plugin were simply a route for an uploaded file to reach Ghostscript.

The issue matters for hosting and website security because it sits below the application layer. Wordfence says a crafted PDF with a JPEG 2000 image can cause Ghostscript to write attacker-influenced bytes past the end of a heap buffer. In its purpose-built WordPress test site, Wordfence developed that memory corruption into unauthenticated remote code execution, meaning code execution without logging in first. The code would run with the permissions of the account processing the PDF, not automatically with root privileges.

Affected upstream Ghostscript versions are 9.21 through 10.07.1 when the OpenJPEG decoder path is present, according to Wordfence. The CVE record states the affected range as before 10.08.0, while Wordfence says the vulnerable sub-byte sampling block was introduced in 9.21. Artifex fixed the issue in Ghostscript 10.08.0. Distributions may also backport the patch into older package versions, so Wordfence warns that the output of gs --version is not enough by itself. The full package revision is what matters.

Wordfence’s testing shows why site owners should not treat the high severity score as a simple yes-or-no statement about every website. Wordfence built two proof-of-concept exploits for its lab build, then ran them 10,240 times across ten other Linux package environments on 64-bit Intel and AMD systems. Those environments included Debian, Ubuntu, Fedora, AlmaLinux, Alpine and the official WordPress container. The two files did not succeed outside the build they were prepared for, while they continued to work on the matching build.

That does not make the vulnerability harmless. Wordfence then kept the same Ghostscript executable and changed fonts, language settings, font configuration and one core system library. The matched exploit still succeeded in all four setups, although not on every attempt. Wordfence says this supports concern about targeted attacks and groups of servers that share the same build, such as sites deployed from the same hosting image or container base. Wordfence also says it has found no public evidence that this Ghostscript flaw is being exploited today.

Wordfence tested ten package environments on September 15. The affected set included the official WordPress Docker image snapshot tested, Debian 13, Debian 12, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Ubuntu 26.04, Fedora 44, AlmaLinux 10, Alpine 3.22 and Alpine 3.23. The official WordPress Docker image snapshot contained Ghostscript 10.05.1, the Imagick extension and a working PDF preview path. Stock WordPress still did not allow anonymous visitors to upload PDFs to the Media Library, so Wordfence says an attacker would need a plugin, form, application route or account that provides that upload path.

Since those tests, Wordfence says fixed packages have shipped for several systems. Ubuntu fixed 22.04, 24.04 and 26.04. Debian fixed 13 through its security repository, while Debian 12 remained listed as vulnerable. AlmaLinux 10 published its fix on October 2. As of October 9, Wordfence says the official package pages for Fedora 44, Alpine 3.22 and Alpine 3.23 still listed the older tested revisions. Administrators should check their distribution advisory for the exact fixed package revision.

For WordPress site owners, the practical exposure depends on four conditions being true at once: a visitor or low-privileged user can upload a PDF, something on the site creates a preview or thumbnail from that PDF, the server has Imagick or another tool that calls Ghostscript, and the installed Ghostscript package does not include the fix. If PDFs are only stored and never processed, this specific path is not exposed, but Wordfence notes that many site owners will not know what happens behind the scenes.

The fix is not a WordPress plugin update. On Debian and Ubuntu systems, Wordfence recommends checking the full Ghostscript package revision with dpkg -s ghostscript. On Fedora and Red Hat family systems, it recommends rpm -q ghostscript. Containers should be rebuilt and redeployed from an updated base image, not merely restarted from the old image. Wordfence also warns that a 10.08.0 release candidate reports 10.08.0 but is not fixed, so administrators need the final release or a distribution package carrying the fix.

If immediate patching is not possible, Wordfence recommends stopping PDFs from visitors and low-privileged users, disabling PDF reads in ImageMagick’s security policy, and limiting the number of files per submission with rate limits on upload forms. These steps reduce exposure or attacker opportunities, but they do not repair Ghostscript. Wordfence also says Ghostscript’s -dSAFER sandbox should not be treated as a fix, because its testing reached the flaw with that sandbox enabled.

The issue is not limited to WordPress. Any application that sends untrusted PDFs to an affected Ghostscript build may be exposed, including document management systems, print services, invoice processors, mail gateways and conversion APIs. Searching application code for the word Ghostscript may miss the dependency, because ImageMagick or another library often sits between the web application and the converter.

For readers running customer-facing websites, the hosting layer matters because the vulnerable component may be supplied by the server image rather than the site code; AEU Hosting is relevant here as managed WordPress hosting, secured end to end. The immediate action remains the same for every environment: confirm whether untrusted PDFs are rendered, install a fixed Ghostscript package, follow restart guidance from the vendor or host, and rebuild containers from updated base images.