Wordfence’s AI Finds a Ghostscript Flaw Rated 9.8 in the CVE and Moderate by Red Hat

Wordfence disclosed on October 12 that its AI-assisted testing system, Wordfence Argus, found a heap buffer overflow in the JPEG 2000 code Ghostscript uses when it turns PDF pages into images. Artifex fixed the flaw, tracked as CVE-2026-39919, in Ghostscript 10.08.0 on September 8, 34 days before Wordfence’s write-up. Wordfence says it developed the bug into unauthenticated remote code execution on “a purpose-built WordPress test site,” and says it has “found no public evidence that it is being exploited today.”

The public records give several severity answers for this one bug. The CVE record, supplied by VulnCheck as the CVE numbering authority, scores it 9.8. Red Hat rates it Moderate with a 7.8 score, and Ubuntu lists it at medium priority. The gap comes down to a deployment question: a person opening a PDF on a desktop is a different exposure from a server that converts PDFs strangers upload, and Wordfence notes that many site owners run Ghostscript without knowing it.

What Wordfence disclosed, and what the public record confirms

Wordfence’s account matches the public records we could read. The table combines Wordfence’s own timeline with commit metadata from the Ghostscript repository on GitHub, the CVE record and vendor advisories. Artifex’s commit message credits the original report to Alex Thomas “of Wordfence Argus (AI),” so the AI label appears in the upstream record as well as in Wordfence’s post.

How the bug works and what the patch changes

The CVE record places the flaw in base/sjpx_openjpeg.c, Ghostscript’s JPEG 2000 output adapter. When an image’s components declare different subsampling factors and its samples are smaller than eight bits, the code allocates a row buffer sized for packed output but writes a full byte per output column. Wordfence’s worked example is a row of 1,024 two-bit samples: the packed size is 256 bytes, and the loop writes 1,024. It says the surplus bytes come from image samples the file’s author chooses and land on bookkeeping Ghostscript uses to manage allocated objects, which is how a crash becomes code execution. Wordfence traces the vulnerable block to Ghostscript 9.21, and the 9.21 tag’s copy of the file contains a variable named ppbyte1, the number of samples packed per byte, that the 9.20 tag’s copy lacks.

The patch is small: seven lines added and three removed in that one file. The loop now advances its sample index once per sample, so each pass packs several samples into one byte, and it checks the index against the row width before each read. The commit message says the fix “exposed an interesting bug in a regression file” whose samples were 10 bits deep, so the patch also adds a guard, which the message describes as “Added a guard in decode_image to error out on images which have BPS which we don’t support.” This is the guard, from the 10.08.0 tag:

if (state->bpp != 1 && state->bpp != 2 && state->bpp != 4 && state->bpp != 8 && state->bpp != 16)
    return ERRC;

It sits after an existing line that maps 12-bit samples to 16, so in effect this decoder path now refuses any sample depth other than 1, 2, 4, 8, 12 or 16 bits, and files with other depths produce an error there.

One detail matters if you track fixes by commit hash. The CVE record, Red Hat’s page and Wordfence all link commit 0a8bf88e39, which was made on master on September 10, two days after the release. We compared it with the 10.08.0 tag through GitHub’s API, and the tag does not contain it: the two histories diverge. The tag does contain an identical patch, 8ddaa67d13, committed on September 7, and that is the commit Debian’s security tracker cites. The 10.08.0 tag’s sjpx_openjpeg.c has the new guard; the copies in 10.07.1 and 10.08.0rc1 do not. A check that only asks whether the linked commit is an ancestor of a release tag would report 10.08.0 as unpatched.

One CVE, several severity answers

The vectors show where the readings split. Red Hat’s is local with user interaction, a person opening a file; the CNA’s is network with none, a service processing whatever arrives. Red Hat’s statement says exploitation “typically necessitates user interaction, such as opening a malicious file,” and its mitigation advice is to “avoid processing untrusted or suspicious PDF documents with Ghostscript.” Wordfence describes the other case: the CVSS scores “describe a network-facing application that accepts PDFs without a login or user action.” Both can be right for their deployments. The risk is a triage rule that reads a vendor’s label without asking where Ghostscript runs, because a converter on a public upload path sits in the second category whatever the label says. CISA’s entry, which marks it automatable with total technical impact, reads closer to that server-side view.

Who has shipped a fix, as of October 12

We read each project’s tracker or advisory on October 12. The package revision matters more than the output of gs --version: Wordfence points out that Ubuntu 22.04’s fixed package, 9.55.0~dfsg1-0ubuntu5.14, still reports Ghostscript 9.55.0, and Ubuntu’s data confirms that revision as the fixed one.

Trackers lag, so a distribution that is not in the table, or a row that disagrees with your own package manager, should be settled by that distribution’s advisory.

What Wordfence showed, and what it did not

Wordfence reduced the flaw to a 1,029-byte PDF that, it says, differs from a harmless control file by a single byte, in a field describing the transparency component’s resolution. It built two working exploits for its own lab build, then ran them 10,240 times across ten other Linux package environments: Debian, Ubuntu, Fedora, AlmaLinux, Alpine and the official WordPress container. Neither succeeded once outside the matching build. When it kept the Ghostscript executable identical and changed fonts, language settings, font configuration and one core system library, the same exploit still worked in all four setups, though not on every attempt. Wordfence’s own summary: “The two proof-of-concept exploits we built were specific to the Ghostscript build they were prepared for.” It also says Debian 12 rendered its test PDF without crashing, but 28 of 40 variants with changed image dimensions did crash it, so a file that does not crash a server is not proof that the server is safe.

That leaves two realistic threats in Wordfence’s telling: a targeted attack on a known build, and an attack on many sites that share one hosting or container image. It cites Hacktron’s HEIF Heist research as a warning against reading build-specific as harmless. Hacktron’s report says that adapting a libheif exploit to each new company “usually took only one or two days.” Wordfence adds that this “does not prove that this exact Ghostscript flaw can be adapted in one or two days.”

What the public record does not show is the code-execution claim itself. We could not inspect or reproduce either exploit, so the overflow rests on Artifex’s own fix, the CNA record and the distribution advisories, while the remote-code-execution result rests on Wordfence’s lab. Artifex’s Bugzilla entry for the bug (number 709666), the page Wordfence links for more details, answered our fetch with a proof-of-work bot check, so we did not read it. On exploitation, CISA’s entry in the CVE record, dated September 20, says exploitation is “none,” and the Known Exploited Vulnerabilities catalog, in the newest version we could read (2026.10.08), does not list the flaw.

What to check on your servers

Start with the package, not the version string. Wordfence’s commands are dpkg -s ghostscript on Debian and Ubuntu and rpm -q ghostscript on Fedora and the Red Hat family. Compare the full revision with your distribution’s advisory, because distributions often add the fix to the older version they already ship. For containers, Wordfence says to rebuild and redeploy from an updated base image rather than restart the old container.

Then ask whether Ghostscript is reachable at all. Wordfence says a WordPress site can be attacked this way only if all four of these are true:

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

WordPress has made first-page images of uploaded PDFs since 4.7, and its developer note says the feature works “if a WP_Image_Editor is available that supports PDF.” Wordfence describes the chain as WordPress, then Imagick, then ImageMagick, then Ghostscript, and says a Site Health screen showing PDF support in Imagick “does not prove ImageMagick’s policy permits PDF reads” and does not show whether Ghostscript is patched. Outside WordPress, the same question applies to document management systems, print services, invoice processors, mail gateways and conversion APIs. If you are on managed hosting, ask the host whether its Ghostscript package includes the fix for CVE-2026-39919 and whether customer-uploaded PDFs are previewed anywhere on its systems.

If you cannot patch yet, Wordfence lists three stopgaps: stop accepting PDFs from visitors and low-privileged users; disable PDF reads in ImageMagick’s security policy, which also disables PDF previews; and limit files per submission and rate-limit upload forms, which reduces attempts without closing the hole. It also warns: “Do not treat -dSAFER as a fix,” because its testing reached the flaw with Ghostscript’s sandbox switch enabled. If you cannot patch every system at once, Wordfence suggests running document conversion in a separate, locked-down service that cannot read site secrets, which limits the damage without fixing anything. ImageMagick’s documentation shows how to deny reads of the PostScript family while still allowing writes:

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

The same page says “ImageMagick ships in an open state so it can be embedded into controlled environments, containers, pipelines, or isolated servers, where administrators can then tighten the policy to match their needs.” It also says ImageMagick generally evaluates policies using a “last matching policy wins” model, so a later rule can undo this one. We did not test the line, because we have no ImageMagick install to test against; treat it as documentation, and confirm with your host what the live policy.xml says.

Wordfence’s earlier Argus disclosure, the libheif flaw we covered on September 19, also sat in a media library behind an upload form, and as we reported, WordPress 7.1.1 credited Anthropic and pwn.ai in a release that fixed eleven bugs. Both point the same way: the flaws that matter to a WordPress site can sit well below WordPress, and a vendor’s severity label tends to describe the deployment the vendor pictured. Patch the package first, then find out whether anything on your servers hands other people’s PDFs to a converter.

Sources and method

We read Wordfence’s post through its RSS feed, the CVE record, the NVD record and the VulnCheck advisory for CVE-2026-39919, and GitHub’s API for the fix commits, the 10.08.0 release and the repository’s tags, including raw copies of base/sjpx_openjpeg.c at the 9.20, 9.21, 10.07.1, 10.08.0rc1 and 10.08.0 tags. We also read the Debian, Ubuntu, Red Hat, AlmaLinux and SUSE advisories, the Alpine package pages and security database, CISA’s Known Exploited Vulnerabilities feed, Hacktron’s report, ImageMagick’s security-policy documentation and the WordPress 4.7 developer note. Every distribution status was read on October 12 and will change. We did not build or run any exploit, and we did not check Fedora.