Ghostscript CVE-2026-39919: two exploits failed 10,240 times on other builds and worked on the matching one

0 of 10,240: what the number measures, and what it does not

Wordfence's researchers built two exploit files for CVE-2026-39919, a heap buffer overflow in the JPEG 2000 decoder inside Ghostscript, and ran them 10,240 times across ten other Linux package environments. Neither file worked once outside the build it was made for. That is 0 successes in 10,240 attempts, or 0 per cent (derived). The same post says both files kept working on the build they were made for, and that the same exploit still worked in all four setups that shared that exact Ghostscript executable after the fonts, the language settings, the font configuration and one core system library were changed, though not on every attempt.

So the number measures how portable two files are. It does not measure how hard the flaw is to exploit. With zero successes in 10,240 tries, the 95 per cent upper bound on the per-attempt success rate of those two files on those ten builds is about 0.03 per cent (derived: 3 divided by 10,240 is 0.0293 per cent, the rule of three). That bound says nothing about a file prepared for a build the attacker has already identified. Wordfence says as much: its experiment "did not measure how easily an attacker could identify it remotely", or how long adapting an exploit would take.

What the record establishes is narrower and still serious. A crafted PDF can crash Ghostscript on every one of the ten tested package environments. Wordfence reports code execution on a purpose-built WordPress test site with Ghostscript's own sandbox switched on. The fix has been public since 8 September, the CVE record since 15 September, and no exploitation is reported. The sections below set out each of those, what the headline versions of the story get wrong, and what a UK organisation should do.

This briefing reads Wordfence's post (dated 12 October 2026, 18:10 UTC, read on its page and in the publisher's own feed), the CVE record, the NVD entry, the CISA Known Exploited Vulnerabilities (KEV) catalogue, Artifex's release data and patch message, the Debian, Ubuntu, Red Hat, AlmaLinux, Alpine, Fedora and SUSE trackers, ImageMagick's security policy page, and the NCSC, Cyber Essentials and ICO pages named in the UK section. BleepingComputer's report of 13 October was read in full and is used only for what it reports. All were read on Wednesday 14 October 2026 between 06:19 and 06:46 BST. Wordfence is part of the security company Defiant, which sells WordPress protection, and its post calls the finding "exactly why we built Wordfence Argus", the AI-assisted system it promotes, so every claim below that rests only on Wordfence is attributed to it.

The clock: 16 days to a fix, 7 to a CVE record, 34 to the write-up

The public record is older than the coverage. The table lists each dated event and the days from Ghostscript 10.08.0, the fixed release of 8 September. Day counts are derived.

Dated events for CVE-2026-39919, from Wordfence's post, the GitHub release list, the CVE record, NVD, CISA, Ubuntu, Red Hat and AlmaLinux. Days are counted from 8 September 2026 (derived).

Date (2026)	Event and who reports it	Days from fix
18 Aug	Release candidate 1 of 10.08.0 published (GitHub). Wordfence says it reports 10.08.0 and is not fixed.	-21
23 Aug	Wordfence says its Argus system discovered the flaw during a WordPress 7.1 assessment, and that it reported it privately to Artifex.	-16
24 Aug	Artifex confirmed the report (Wordfence). The fix commit in Artifex's repository is dated 24 August.	-15
8 Sep	Ghostscript 10.08.0 released with the fix (GitHub release, 12:29 UTC).	0
15 Sep	CVE record published by VulnCheck as the CVE Numbering Authority, CVSS 3.1 score 9.8. NVD entry the same day, status "Awaiting Analysis" when read. Wordfence tests ten package environments.	7
14 to 20 Sep	CISA's weekly bulletin for the week of 14 September lists it at 9.8. CISA's enrichment data, stamped 20 September, records exploitation "none", automatable "yes", technical impact "total".	6 to 12
21 Sep	Ubuntu publishes USN-8791-1 for 22.04, 24.04 and 26.04.	13
1 to 6 Oct	Red Hat fixes for RHEL 10 (1 Oct), 9 (2 Oct) and 8 (6 Oct); AlmaLinux 10 on 2 Oct.	23 to 28
12 Oct	Wordfence publishes the full write-up (18:10 UTC).	34
13 Oct	BleepingComputer reports it (17:33, US Eastern time).	35
14 Oct	This briefing reads the trackers and the KEV catalogue.	36

Three things follow. First, the CVE record, with a score of 9.8, was public 27 days before Wordfence's write-up and the fix 34 days before it (derived). A team that waited for the coverage learned of the flaw 34 days after the fix existed. For distribution packages the fixes themselves arrived 13 to 28 days after the upstream release (derived), so part of that exposure was not the team's to remove. Second, Artifex's release notes say only that 10.08.0 "addresses a number of potential security issues" and do not name the CVE; the patch message names the bug and credits "Wordfence Argus (AI)". Third, the date of the Wordfence post is 12 October, not 13 October: the 13th is BleepingComputer's report.

The 16 days from report to release sit well inside the 90 days that Artifex asks researchers to keep a report confidential, about 18 per cent of that window (derived). Artifex's documentation page for 10.08.0 carries dates that do not match the release: its heading shows 2026-05-19, which is the date of 10.07.1 on the release-dates page, and its footer shows 18 August 2026. This briefing therefore takes 8 September from the GitHub release record and from Wordfence's post, which agree.

BleepingComputer and Wordfence: where the two accounts differ

BleepingComputer's report is a fair short summary on most points. On one, its wording reads as the reverse of the post; on one it words the AI system's role more broadly than the post does; and on one it reports a backport that the primaries describe as distribution work. The table sets each point beside what the primary sources say.

BleepingComputer, 13 October 2026, against Wordfence's post of 12 October, the GitHub release list, the CVE record, CISA's KEV catalogue and CISA's enrichment data, as read on 14 October 2026.

Point	BleepingComputer	What the primary sources say
Fonts, language settings, a core library	Changing the PDF's fonts, language settings, font configuration and one core system library "enabled the exploit to succeed, although not reliably".	The exploits were built for a lab build. With the same Ghostscript executable kept and those items changed, "the same exploit still succeeded in all four setups", though not on every attempt. The changes did not stop it; they did not enable it.
Who built the exploits	"Using Argus, the researchers developed two exploits."	The post says "we built two working proof-of-concept exploits". Argus found the flaw during an assessment the post says was led and validated by a researcher. How much exploit work Argus did itself is not stated.
Backports	Fixes "were also backported to older versions".	Wordfence says distributions "often add the fix" to the version they ship. Artifex's GitHub list shows one fixed release, 10.08.0, and nothing after it.
Exploitation	Wordfence "has not seen any in-the-wild exploitation".	The post says Wordfence has "found no public evidence" of exploitation. CISA's enrichment entry says none (20 Sep). The CVE is not in the KEV catalogue (release 2026.10.13).
Affected versions	Any online system running Ghostscript 9.21 through 10.07.1.	The post adds "when the OpenJPEG decoder path is present", and that all ten tested environments had it. The CVE record says "before 10.08.0", with no lower bound.
Date of the report	13 October.	The Wordfence post is dated 12 October. The CVE record is dated 15 September.

What a rate of zero says about a lab, and what it leaves open

A lab rate of zero is a statement about two files and ten builds. The table separates what each figure in Wordfence's post establishes from what it does not.

Figures from Wordfence's post of 12 October 2026, with this briefing's derived readings. The last column is the negative column.

Figure	What it establishes	What it does not establish
0 of 10,240 attempts, two files built for one build, ten other builds	Those two files are not portable across those builds. Upper bound on their per-attempt success there: about 0.03 per cent (derived).	That the flaw is hard to exploit. That a file prepared for another build would fail. Any rate on the internet: Wordfence says it "cannot give a success rate across the Internet".
Worked on the lab build and in all four same-executable setups, not every attempt	Code execution is real on a purpose-built WordPress test site, with Ghostscript's -dSAFER sandbox on.	The per-attempt success rate (not given). How many attempts a real site tolerates: on the test form, failed attempts returned a success response while Ghostscript crashed in the background; other sites may log, block or rate-limit.
10 of 10 environments carried the vulnerable code	All ten package revisions tested on 15 September contained the vulnerable path.	How many production servers run those revisions. Wordfence did not measure package prevalence.
Crashed on the first test file: 9 of 10. Debian 12: 28 of 40 variations crashed (70 per cent, derived)	A crafted file can crash the converter on every tested build, so a denial of service is shown (10 of 10, derived).	That a crash is code execution. That a file which does not crash a server proves it safe: Wordfence says it does not.
10,240 = 10 x 1,024 (derived)	If the attempts were split evenly there would be 1,024 per environment. The post does not give the split.	How many attempts each of the two files made on each build.

Why would the zero be expected? A memory-corruption exploit is built around how one build lays out its memory. Run on a different build, it tends to crash the program rather than take it over. That is inference from how such exploits generally work and from Wordfence's own conclusion that the files were "specific to the Ghostscript build they were prepared for"; the post does not run the experiment that would prove it. It also means the 10,240 failures cost an attacker only crashes. Wordfence's post says a hosting platform, or any group of servers built from one image, may present the same build to many sites, which is the case where one matched file is enough.

The ten tested environments, and where each stands on 14 October

Wordfence tested these package revisions on 15 September, when each was affected. The third column is what the trackers show now. A distribution fix usually keeps the old version number, so the revision, not the version, is the thing to compare.

The ten environments in Wordfence's table (tested 15 September 2026) against the Debian, Ubuntu, Red Hat, AlmaLinux, Alpine and Fedora pages read on 14 October 2026.

Platform	Revision Wordfence tested	Fix status, read 14 October
Official wordpress Docker image	`10.05.1~dfsg-1+deb13u1`	Its Debian 13 base has a fixed package (below). Whether the current image carries it was not inspected.
Debian 13 trixie	`10.05.1~dfsg-1+deb13u1`	Fixed in the security repository, `10.05.1~dfsg-1+deb13u3`, advisory DSA-6516-1.
Debian 12 bookworm	`10.0.0~dfsg-11+deb12u8`	Tracker still lists it as vulnerable at the same revision.
Ubuntu 22.04 LTS	`9.55.0~dfsg1-0ubuntu5.13`	Fixed, `9.55.0~dfsg1-0ubuntu5.14` (USN-8791-1, 21 Sep).
Ubuntu 24.04 LTS	`10.02.1~dfsg1-0ubuntu7.8`	Fixed, `10.02.1~dfsg1-0ubuntu7.9`.
Ubuntu 26.04	`10.06.0~dfsg-3ubuntu1`	Fixed, `10.06.0~dfsg-3ubuntu1.1`.
Fedora 44	`10.06.0-2.fc44`	Tracker bug open, no fixed-in version. Stable package page still `10.06.0-2.fc44`. The updates system was not readable.
AlmaLinux 10	`10.02.1-16.el10_0`	Fix published 2 Oct (ALSA-2026:74464), `10.02.1-16.el10_2.1`.
Alpine 3.22	`10.05.1-r0`	Package page still `10.05.1-r0`. Alpine's security database lists no fix.
Alpine 3.23	`10.06.0-r0`	Package page still `10.06.0-r0`. Alpine's security database lists no fix.

Counting from the trackers (derived): a fixed package is published for five of the ten (the three Ubuntu releases, Debian 13 and AlmaLinux 10), one is undetermined (the WordPress image, which depends on when it was last rebuilt), and four show no fix on the pages read (Debian 12, Fedora 44, Alpine 3.22 and 3.23). Wordfence reported on 9 October that Fedora 44 and both Alpine releases still listed the older revisions; on 14 October the pages read still do. Sources: the Debian, Ubuntu, Red Hat, AlmaLinux, Alpine and Fedora trackers, and the Fedora 44 package page. The Fedora update system and Artifex's bug tracker answered with a bot check and were not read.

One flaw, five labels: critical, important, moderate, medium and "none"

Severity depends on who scores it and where they imagine Ghostscript running. The labels below are all real and they do not agree.

Ratings for CVE-2026-39919 as read on 14 October 2026 from the CVE record and NVD, Red Hat, SUSE, Ubuntu, AlmaLinux, CISA's enrichment data and FIRST's EPSS service.

Who	Rating	What it rests on
CVE record and NVD (VulnCheck, as the CVE Numbering Authority)	CVSS 3.1 9.8, CVSS 4.0 9.3, Critical	Network attack vector, low complexity, no privileges, no user interaction. NVD's own analysis: "Awaiting Analysis".
Red Hat	CVSS 3.1 7.8, Moderate	Local attack vector and user interaction required. Rated lower because exploitation "typically necessitates user interaction, such as opening a malicious file".
SUSE	7.8 (v3), 8.5 (v4), important	SUSE's own scores, shown beside the CNA's 9.8 and 9.3: local attack vector, user interaction required (passive in v4).
Ubuntu, AlmaLinux	Priority medium, severity moderate	Ubuntu's priority is medium although its page also shows 9.8. AlmaLinux follows Red Hat.
CISA enrichment data (20 Sep)	Exploitation none, automatable yes, technical impact total	A prioritisation record, not a score. "Exploitation: none" was true on 20 September.
FIRST EPSS (13 Oct)	0.784 per cent, 54.9th percentile	A statistical model's estimate of exploitation. It cannot see whether you render strangers' PDFs.

These do not contradict each other. A 9.8 describes Ghostscript behind a web application that takes PDFs from strangers. A 7.8 describes Ghostscript opening a file on someone's desktop. The deployment is the one thing a score cannot see, and it is the one fact only you hold. For UK certification the labels matter less than they seem: Cyber Essentials counts any update that fixes a vulnerability with a CVSS v3 base score of 7 or above, and even the lowest score on this record, 7.8, is over that line (derived). A "Moderate" from a vendor does not move the requirement.

The friendly names: thumbnail, optimisation, validation, sandbox, version

A comforting label is not a control. Six labels in this story do the work of a control without being one.

Labels that stand in for a control in this story, and what the sources say stands behind each. Sources: Wordfence, ImageMagick, Ubuntu, the CVE record.

The label	What it hides	What the source says
"Thumbnail generation", "image optimisation"	A full interpreter runs on a stranger's file.	Ghostscript is a PDF and PostScript engine. It starts only when something asks for a picture of the PDF; a form that merely saves the file never starts it.
"Upload validation"	Extension, content type and basic structure checks do not see the problem.	Wordfence: a valid PDF holding a valid JPEG 2000 image can differ from a harmless control file by a single byte, and ordinary extension, MIME type or basic structure checks do not identify it.
"The sandbox" (-dSAFER)	It limits what a document may do, not memory corruption.	Wordfence: "Do not treat -dSAFER as a fix", and the flaw was reached with it enabled.
"The version number"	It does not say whether the fix is present, in either direction.	Ubuntu 22.04's fixed package still reports 9.55.0. Release candidate 10.08.0rc1 reports 10.08.0 and is not fixed. Wordfence: the full package revision matters more than the output of gs --version.
"Imagick recognises PDF" in WordPress Site Health	It shows that a format is recognised, not that policy permits it or that Ghostscript is patched.	Wordfence says Site Health is only a starting point, and that your host, package manager or container supplier is the authority on the fix.
"A security policy is in place"	ImageMagick is open unless told otherwise.	ImageMagick's page says its model is "everything allowed unless denied" and that it is intentionally open by default for controlled environments such as Docker containers.

The ImageMagick row deserves a second look, because it is the stopgap everyone is told to use. Wordfence says to disable PDF reads in ImageMagick's security policy, and notes that this also disables PDF previews. The ImageMagick page documents a coder rule that stops reading PDF, PostScript and XPS and a module rule that stops interpreting them, and shows a command that lists the policy actually loaded. It also says that before version 7.1.1-16 pattern matching is case sensitive and names should be upper case, while its own module example is written in lower case, and it does not reconcile the two. A rule that is written down is not a rule that works: list the loaded policy, then upload a harmless PDF and confirm that previews stop.

The same chain has been hit before this year, by a different bug. WordPress 7.0.4, released on 12 August, fixed an authenticated remote code execution flaw (CVE-2026-65640) through a file upload on sites that use Imagick and Ghostscript. That is a separate CVE; the WordPress post does not tie it to this flaw. It shows the route, upload then Imagick then Ghostscript, as one that has been used for a vulnerability before.

Who is plausibly reachable: the chain, four prerequisites and the other applications

Wordfence's WordPress chain is WordPress, then the PHP Imagick extension, then ImageMagick, then Ghostscript as a separate program, usually under the web server's own account. Its post lists four things that must all be true: a visitor or low-privilege account can upload a PDF; something then asks for a preview or thumbnail; the server has Imagick or another tool that calls Ghostscript; and the installed Ghostscript lacks the fix. Stock WordPress does not let anonymous visitors upload PDFs to the Media Library, so a plugin, form, route or account has to supply the path. The official WordPress Docker image snapshot Wordfence tested had Ghostscript 10.05.1, Imagick and a working PDF preview path.

Beyond WordPress, the post names document management systems, print services, invoice processors, preview generators, mail gateways and conversion APIs as places that may send untrusted PDFs to an affected build. That list is Wordfence's reasoning, not a test result: the post reports one purpose-built WordPress site and the form plugin used to reach it, and it says the same question applies anywhere Ghostscript is used. It also warns that searching your application code for the word Ghostscript may miss the dependency, because ImageMagick or another library usually sits in between.

Two details in the post are useful to a defender. WordPress's Imagick loader retries a failed preview with a different setting, so Wordfence measured one Ghostscript process for a harmless PDF and two for a crashing one, and three attachments produced six processes. And on its test form a failed attempt still returned a success response to the uploader. A crash on the server is therefore not visible to the person who caused it, and has to be looked for on the server.

Wordfence ties its result to Hacktron's HEIF Heist research on image decoders. Hacktron, a security research company that offers its services on that page, describes probing upload endpoints to fingerprint the library version, then using a payload matched to that version, with some attempts landing only after thousands of uploads, and says AI assistance cut exploit development to roughly 1 to 3 days. Wordfence's post paraphrases that as one or two days and adds that HEIF Heist does not prove this flaw can be adapted so quickly. It concerns a different library. Taken together this is inference, not a finding: for Ghostscript, whether a build can be identified from outside was not measured, so the 0 of 10,240 is the price of guessing the build wrong, and says nothing about an attacker who identifies it first.

Stated and not stated: the record, line by line

"Not stated" means not found in the sources read. It does not mean the information does not exist.

What the primary sources state about CVE-2026-39919 and what they do not, as read on 14 October 2026.

The question	Stated	Not stated
Exploitation in the wild	Wordfence "found no public evidence". CISA's enrichment entry says exploitation none (20 Sep). Not in the KEV catalogue, release 2026.10.13, 1,741 entries. EPSS 0.784 per cent. A GitHub search for the CVE identifier on 14 October returned no repositories.	Any telemetry from Wordfence's firewall or from hosting providers. What the "public evidence" search covered. A search of one site is weak evidence, and absence of reports is not absence of use.
How many servers expose the chain	The four prerequisites. One official WordPress image snapshot with Ghostscript 10.05.1, Imagick and a PDF preview path.	Package prevalence. How many sites accept PDF uploads. How many ImageMagick policies allow PDF.
How reliable the build-matched exploit is	It worked on the lab build and in all four same-executable setups, not on every attempt.	A success rate per attempt. The number of attempts needed. The exploit files themselves, which were not published.
Whether other applications are practically reachable	Wordfence names document management, print, invoice, preview, mail gateway and conversion services as possibly exposed.	Any test of them. Which of them run ImageMagick with PDF enabled.
Whether Argus verified exploitability	Argus discovered the flaw. The assessment was led and validated by a researcher. Researchers reduced the file, confirmed the corruption with a diagnostic build and a matched control file, and demonstrated code execution.	How much of the exploit work Argus did itself. BleepingComputer says Argus developed the exploits; the post says "we built" them.
A fix on every platform	Fixes for Ubuntu 22.04, 24.04 and 26.04, Debian 13, RHEL 8, 9 and 10, AlmaLinux 10, and SUSE products.	Fixes on the pages read for Debian 12, Fedora 44, Alpine 3.22 and 3.23. Ubuntu 16.04, 18.04 and 20.04 are "needs-triage". RHEL 6 and 7 are "Out of support scope".
A public trigger file	The post refers to a 1,029-byte "public test file" and a "minimal public test case" for the flaw.	Where it is published. This briefing did not look for it. A public trigger is not a public exploit.
A protective rule from Wordfence's own products	Nothing in the post mentions one.	Whether Wordfence's firewall blocks this.

For contrast, an upload flaw covered earlier on this site, Bricksforge, had exploit attempts from the day it was disclosed. Nothing comparable is reported here, which is a reason to patch on schedule and not a reason to wait.

Nine years of packages: what 9.21 to 10.07.1 means for old images

Wordfence's affected range runs from 9.21, released on 16 March 2017, to 10.07.1, released on 19 May 2026. That is 3,351 days, about 9.2 years (derived), and Artifex's release-dates page lists 28 releases in it (derived count). The CVE record gives no lower bound and says "before 10.08.0". Wordfence says its reading of the source history puts the vulnerable code at 9.21, and only where the OpenJPEG decoder is present. This briefing could not check that reading independently.

The practical meaning is that every package line a distribution still ships is inside the range, and the fixed upstream version is irrelevant to most of them. Red Hat's RHEL 8 carries Ghostscript 9.27, released on 3 April 2019, about 7.5 years before today (derived). RHEL 9 carries 9.54.0, SUSE Linux Enterprise 15 products carry 9.52, Ubuntu 22.04 carries 9.55.0 and Debian 12 carries 10.0.0. Their fixes are distribution patches to those old versions, which is what Wordfence means when it says the revision matters more than the version. Upstream has one fixed release, 10.08.0 of 8 September: the GitHub release list shows 10.07.1 on 19 May, 10.08.0 on 8 September and nothing after it (as read on 14 October), so no older upstream branch has a fix.

Other distribution states read on 14 October 2026 from Red Hat, SUSE, Ubuntu and Debian. Days are counted from the upstream release of 8 September (derived).

Platform	State read on 14 October	Date and days after 8 Sep
Red Hat Enterprise Linux 10	Fixed, `ghostscript-10.02.1-16.el10_2.1` (RHSA-2026:74464)	1 Oct, day 23
Red Hat Enterprise Linux 9	Fixed, `ghostscript-9.54.0-19.el9_8.1` (RHSA-2026:74457)	2 Oct, day 24
Red Hat Enterprise Linux 8	Fixed, `ghostscript-9.27-18.el8_10` (RHSA-2026:76877)	6 Oct, day 28
Red Hat Enterprise Linux 6 and 7	"Out of support scope" in Red Hat's data	No fix from this channel
Ubuntu 16.04, 18.04, 20.04	Listed "needs-triage" on Ubuntu's CVE page	Not assessed on the page read
SUSE	Fixed packages listed for SUSE Liberty Linux 8, 9 and 10 and several SUSE Linux Enterprise 15 products, rated "important"	Dates not read
Debian forky and sid	Fixed, `10.08.0~dfsg-2`	Not dated on the page read

Three consequences for old images and appliances follow, each partly inference. A container built on an old base and not rebuilt keeps the old revision. A rebuild from a base whose repository has no fix still contains the flaw, so confirm the revision inside the running container, not only in the build file. And a product that bundles its own Ghostscript needs the product vendor's update, which no distribution tracker will show.

UK: the 14-day clock, the NCSC table, the ICO duty and the host

Cyber Essentials. The current technical requirements are version 3.3, dated April 2026, effective from 27 April 2026 according to the NCSC's Cyber Essentials resources page. The requirements document says software must be licensed and supported, and updated, including vulnerability fixes, within 14 days of release where the vendor calls the fix critical or high risk, where the update addresses a vulnerability with a CVSS v3 base score of 7 or above, or where no severity is given. It defines software to include operating systems, extensions, interpreters, scripts and libraries, so Ghostscript and ImageMagick count as software on any in-scope server. It does not say whose release starts the clock when a package is rebuilt by a distribution. This briefing reads it as the release of the update available for the software in scope, and a candidate for the assessor to confirm.

The 14-day Cyber Essentials window counted from each release, as read on 14 October 2026 (derived). Release dates from Wordfence's post, Ubuntu, Red Hat and AlmaLinux.

Release	Fourteenth day	State on 14 October
Upstream 10.08.0, 8 Sep	22 Sep	22 days past
Ubuntu USN-8791-1, 21 Sep	5 Oct	9 days past
RHEL 10, 1 Oct	15 Oct	1 day left
RHEL 9 and AlmaLinux 10, 2 Oct	16 Oct	2 days left
RHEL 8, 6 Oct	20 Oct	6 days left

For managed services, the same document's cloud table says security update management is shared between the customer and the provider for infrastructure as a service and for platform as a service, and is the provider's for software as a service. A virtual server running WordPress is the first kind: host and customer each own part of the updates, and the customer may be the only party who knows that uploads become previews.

NCSC patching. The NCSC's vulnerability management guidance, version 2.1, reviewed on 1 May 2026, gives best-practice timescales that apply to all updates regardless of severity: 5 days for internet-facing services and software, 7 days for operating systems and applications, 14 days for internal or air-gapped systems. Against the 5-day figure, the Ubuntu fix of 21 September fell due on 26 September (derived). The same page says the most reliable way to automate is to replace the running image or code with the updated version, which is the container rebuild Wordfence asks for. Its triage step says that where no update is available you need a process to triage and prioritise, and that a temporary workaround should be time-bounded and tracked. The NCSC's patch wave blog of 1 May 2026 tells organisations to prioritise their external attack surface first. No NCSC publication on this CVE was found; the NCSC site search could not be read as a static page, so that check is limited.

Handling untrusted files. The NCSC's Safely Importing Data pattern, published on 15 July 2018 and not revised on the page, lists rapid patching of all services and applications used to open or interpret content, including library dependencies and the underlying operating systems, and non-persistence and sandboxing of rendering applications. It says a PDF can be made of thousands of interrelated objects, that transforming a complex format into a simple one is a way to neutralise content, and that the transformation engine itself could be vulnerable, so it should be assumed compromisable and contained. A thumbnail is exactly that transformation. The NCSC's denial of service guidance, reviewed on 25 March 2024, adds an upload rule written for another purpose that also removes the anonymous route here: accept uploads only from authenticated users or systems.

The ICO and UK GDPR. Article 32 of the UK GDPR requires appropriate technical and organisational measures for a level of security appropriate to the risk, including "a process for regularly testing, assessing and evaluating" their effectiveness (Article 32). The ICO's data security guide adds periodic checks that measures remain appropriate and up to date, and says a controller must choose a processor that gives sufficient guarantees about its security measures and must have a contract requiring Article 32 measures. A personal data breach that is not unlikely to result in a risk to people must be notified within 72 hours of becoming aware of it where feasible (Article 33, which as read on legislation.gov.uk names "the Commission" as the recipient). The ICO page carries a banner that its guidance is under review because of the Data (Use and Access) Act. The ICO has said nothing about this flaw. That a controller which knew of a fixed critical flaw and a reachable upload path then did nothing would struggle to call its measures appropriate is this briefing's inference, not an ICO statement.

Hosting providers and managed WordPress. Wordfence advises managed hosting customers to ask the host whether its Ghostscript package includes the fix and whether customer-uploaded PDFs become previews anywhere on its systems, because customers cannot check most of it themselves. The word "managed" does not say the host patched the package or knows that the preview step exists. Wordfence also flags the supply chain case: groups of sites built from a shared image may present the same build to an attacker, which is the case its 10,240-attempt experiment does not rule out.

What to do, in order

The question that exposes the gap

Wordfence's advice reduces to one question for every system: does this software render PDFs that came from somebody else? A patch table, a severity label and a lab rate of zero are all answers to other questions. The files that failed 10,240 times on other builds say how much an attacker pays for guessing wrong. They say nothing about how many of your servers are already the matching build. Does anyone in your organisation know which of your servers open a stranger's PDF?

Key facts