Yes. CISA added CVE-2017-8291 to its Known Exploited Vulnerabilities catalogue on 24 May 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Artifex Ghostscript allows -dSAFER bypass and remote command execution via .rsdparams type confusion with a "/OutputFile. Any organisation running the affected product should treat remediation as urgent.
How to treat an exploited Ghostscript CVE like this one
A KEV listing changes the operational question from “is this vulnerable?” to “can we still justify exposure?” For a Ghostscript flaw that enables remote command execution, the practical priority is to identify every host, application, or workflow that can invoke Ghostscript on untrusted files, then verify whether the vulnerable code path is reachable in production, testing, or user-upload handling.
When a product sits inside a document-processing or image-conversion pipeline, exploitability is often determined by reachability rather than installation alone. A system that never processes attacker-influenced PostScript or PDF content may have a lower immediate exposure than one that accepts uploads, previews files, or converts documents automatically. The latter is where active exploitation becomes operationally meaningful.
For a broader triage method that combines exposure discovery, prioritisation and remediation workflow, the Zero-Day and Exploited Vulnerabilities Guide is the right internal reference point.
What the Ghostscript attack path usually looks like
The core abuse pattern is not just “a buggy parser”, but trust in a file format that the application assumes will remain inert. With Ghostscript, an attacker can use crafted content to trigger type confusion and then drive code execution through the interpreter. If the application treats uploaded or fetched content as safe because it is only a document, that trust boundary is already broken before the payload executes.
This matters most where Ghostscript is embedded behind another business service, such as content management, office automation, conversion microservices, web upload handlers, or security tooling that rasterises files. In those environments, exploitation can turn an ordinary document workflow into a remote command execution path. The response should therefore include a review of where untrusted files enter the system, not just whether the package is installed.
For a practical comparison point on how application-layer exposure and reachability affect prioritisation, see the Application Security Posture Management (ASPM) Guide.
What to do if patching or removal is delayed
If immediate remediation is not possible, the safest interim step is to reduce the set of inputs that can reach Ghostscript and to isolate the process as tightly as possible. That means restricting who can upload files, constraining the file types accepted, preventing automatic conversion of untrusted content where feasible, and running the component in a heavily sandboxed context with minimal filesystem and network access.
Because active exploitation is already established, compensating controls should be treated as temporary risk reduction, not a substitute for remediation. Teams should preserve evidence of exposure, confirm whether the affected service has internet-facing or partner-facing reach, and review logs for suspicious file uploads, unexpected process spawning, child shells, or outbound connections from the conversion host.
The operational playbook for this kind of emergency response is well covered by the Vulnerability Management Guide, especially for KEV-driven prioritisation and post-remediation verification.
Risk and Threat Considerations
Exploitability is high when Ghostscript is exposed through any workflow that accepts attacker-controlled documents, because the vulnerability can convert a content-processing dependency into code execution. The practical risk is not limited to the vulnerable binary itself, but to every upstream service that trusts file content, plus any downstream system reachable from that host.
Failure mechanism: A crafted file reaches Ghostscript, the interpreter mishandles the input, and the attacker gains execution inside the conversion context, which can then be used to pivot or persist depending on local privileges and network access.
Impact: The immediate impact can include arbitrary command execution, application compromise, data exposure, and lateral movement into adjacent services that share credentials, mounts, or network trust with the affected host.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed flaws demand rapid identification and remediation of exposed assets. |
| Recommendation — Prioritise and remediate the exposed Ghostscript instances immediately. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | The question hinges on confirming exposure and identifying vulnerable systems. |
| RS.MI-01 — Incidents are contained | Active exploitation makes containment and blast-radius reduction immediately relevant. | |
| Recommendation — Inventory every Ghostscript deployment and determine which instances are reachable. Contain the affected service and limit its network and file-system reach. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This CVE requires vulnerable-instance discovery and exposure verification. |
| SI-2 — Flaw Remediation | The central action is urgent remediation of a known exploited vulnerability. | |
| Recommendation — Scan for all Ghostscript uses and verify where the flaw is reachable. Apply the vendor fix or approved mitigation as soon as operationally possible. | ||
Practitioner Guidance
What to verify: Confirm whether Ghostscript is reachable from any internet-facing or externally influenced workflow, then validate whether the service runs with filesystem, network, or shell privileges that would make code execution materially dangerous. If you cannot prove non-reachability, treat the instance as exposed.
Decision rule: If the component processes untrusted files and cannot be immediately removed or updated, isolate it first, then reduce input sources and execution privileges while the fix is prepared. If the host is already privileged or broadly connected, prioritise containment before extended forensics so the blast radius does not widen.
Practitioner takeaway: With a KEV-listed RCE in a document-processing path, the real question is not whether the package exists, but whether untrusted content can still drive execution anywhere in the workflow.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org