- Wordfence found CVE-2026-39919, a Ghostscript flaw a crafted PDF can use to run code. WordPress needs four conditions; other apps rendering untrusted PDFs may be exposed.
- The risk sits in a background tool that PDF preview features call, so it can be hidden from application inventories.
- Confirm Ghostscript is at 10.08.0 or a patched backport, rebuild Docker images, and limit who can upload PDFs.
The risky part is the tool you never chose
Most organisations know which applications they run. Fewer know which tools those applications call in the background. A PDF preview feature is a small example. The thumbnail on a file upload looks like a feature of the website. In practice it hands the file to a chain of other software.
A newly detailed flaw in one link of that chain, Ghostscript, shows the problem. The lesson here is that your exposure includes every tool your features quietly call, not only the software on your asset list.
What Wordfence found
Researchers at Wordfence, the security platform from Defiant, reported CVE-2026-39919 in Ghostscript. BleepingComputer, which covered the report on October 13, calls it a critical heap buffer overflow. The researchers say a specially crafted PDF can lead to remote code execution, meaning an outsider runs commands on the server.
Wordfence found the flaw on August 23 with Argus, its AI-powered system. It affects Ghostscript 9.21 through 10.07.1. The maintainer, Artifex, shipped the patched release, 10.08.0, on September 8.
Older branches received the fix separately. So a version number below 10.08.0 does not, on its own, prove a system is exposed. Check the revision details for each system.
How a PDF becomes a foothold
Ghostscript is software that reads PDF and PostScript files. It turns PDFs into images, builds thumbnails and shrinks files. A buffer overflow happens when a program writes more data than the space set aside for it. The extra data spills into neighbouring memory and corrupts it. Here, the exploits push 1,024 bytes into a 256-byte space.
The trigger is a JPEG 2000 image embedded in the PDF. Ghostscript handles it wrongly when the image stores very few bits per sample, or when its components have different resolutions.
In WordPress, the route to Ghostscript has several hops. To build a PDF preview, WordPress can call PHP's Imagick extension. Imagick calls ImageMagick, and ImageMagick starts Ghostscript.
Wordfence says four things must hold on a WordPress site. An attacker must be able to get a PDF onto the site, either anonymously or with a low-privileged account. The site must generate a preview from that file. The software chain must reach Ghostscript, with settings that permit PDF rendering. And that Ghostscript must still carry the vulnerable decoding code.
Wordfence points out that a default WordPress install blocks anonymous visitors from adding to the Media Library.
Those four conditions describe WordPress only. The researchers say the flaw reaches any application that passes outsider-supplied PDFs to the affected Ghostscript code. Whether an attacker needs an account depends on the application.
What the lab results do and do not show
Every Linux environment the team checked held the flawed code. There were ten, spanning distributions such as Debian and Ubuntu. So did an official WordPress Docker image snapshot.
Having the code is not the same as a working attack. The team ran its two proof-of-concept exploits 10,240 times against Linux packages in a lab. None achieved remote code execution. On a purpose-built test server, code did run.
The researchers also found that changing the PDF's fonts and language settings, the font configuration and one core system library let the exploit succeed. Even then it did not succeed reliably. The source does not say whether those changes were the ones used on the test server. The researchers say the flaw is exploitable once the payload is adjusted to the environment.
Wordfence also said it has not seen exploitation of CVE-2026-39919 in the wild yet. That statement is about this flaw. It is not a verdict on how hard the four WordPress conditions are to meet. A narrow lab path is not the same as no path.
What the AI detail asks of a leader
Wordfence used Argus to find the flaw and to develop two proof-of-concept exploits. Those exploits depended on the target environment. They failed against standard Linux packages in the lab and worked only unreliably after tuning.
The source gives no timeline for the work. It does not show how fast an AI-assisted team moved from discovery to a working attack. So treat speed as a question, not a finding. If a defender's tool can go from finding a bug to proof-of-concept code, what do your patch schedules assume about attackers with similar tools?
Questions to put to your team
Ask which systems render PDFs that outsiders can supply. Include upload forms, support portals and document tools, not only the main website.
Ask which Ghostscript version each system runs, and whether it is 10.08.0 or later or a backport with the fix. For WordPress sites, the source advises confirming this through the hosting provider. Ask in writing.
Ask whether Docker images have been rebuilt on an updated base image. The WordPress image snapshot tested contained the vulnerable code.
If patching has to wait, the source advises stopping PDF uploads from reaching the server, or switching off PDF rendering in ImageMagick. Also ask who can upload at all. In WordPress, that is the first of the four conditions.
A website's attack surface is not what you built. It is everything your features quietly call.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: BleepingComputer.
