Ghost in the Script: Hidden Risks

November 4, 2026 · 7 min read ·Fabius Artrel

Recently, Hacktron AI revealed “HEIF Heist” , a class of vulnerabilities in libheif demonstrated to affect several vendors and applications. Not long before that, XBOW discovered critical image processing vulnerabilities affecting Microsoft’s Bing Images. Although developers have significantly improved at securing the application layer, they continue to implicitly trust lower-level dependencies. This presents an attractive target for attackers seeking widespread impact, with AI making these vulnerabilities easier to identify and exploit.

While image upload or conversion features may appear to have a narrow attack surface, they often expose a much larger stack of underlying native code. Back in May, Liondawn Labs also investigated this increasingly prominent attack surface, with a focus on Ghostscript’s native TrueType font interpreter. This blog presents the findings of that research and outlines defensive strategies that reduce exposure to similar vulnerabilities that have yet to be discovered.

Hidden Risks of Image Processing

Image processing has a long history of serious security failures. Beyond recent disclosures, ImageTragick stands out as a particularly notable reference point. Ghostscript also has a vulnerability history riddled with sandbox escapes and memory corruption flaws leading to code execution.

This isn’t very surprising when you consider that image processing involves file parsers, converters, and interpreters openly processing potentially hostile data and subjecting it to complex transformations.

In March of 2026, pwn.ai published research showcasing several interesting ImageMagick vulnerabilities. Among their findings, we found the PostScript format detection bypass they demonstrated to be especially intriguing:

PWN.AI PDF Bypass

Most interestingly, the vendor’s position was largely that the behavior belonged in deployment policy and does not appear to have been addressed as a product vulnerability. As a result, we are left with a known format detection bypass that attackers may continue to use against affected applications.

A Familiar Attack Surface

When we began our research in May, Ghostscript was new territory for us, but PostScript was not.

As part of Team Cluck , I helped discover and exploit vulnerabilities in Lexmark printers for Pwn2Own . Success required us to understand PostScript deeply enough to reason about Lexmark’s proprietary PostScript interpreter and identify where its implementation broke down.

While Ghostscript may have been a different codebase, it was speaking a language we already knew how to attack. PostScript is a large, flexible language, and PostScript interpreters have to connect high-level semantics to low-level parsers, memory management, font processing, graphics subsystems, and device-specific behavior. There are a lot of places for assumptions to fail.

Breaking into Ghostscript

We gave ourselves a narrow research objective: “Find an exploitable memory corruption issue in Ghostscript.”

Our research began with a focus on Ghostscript’s TrueType bytecode interpreter. Font parsers are notoriously prone to memory corruption issues, and PostScript’s ability to embed font data gives the engine yet another complex binary format to parse within an already complex language runtime.

The use of AI played a significant role in handling the volume of work required. We used it throughout the research process, from mapping out the codebase and understanding unfamiliar implementations to investigating observed behavior and testing ideas through dynamic experimentation. Although AI helped with the volume of work, the quality of work still heavily depended on researcher judgment and expertise.

Out-of-bounds Write in TrueType SHC/SHZ Instructions

Within a few days, our research produced an out-of-bounds write vulnerability in Ghostscript’s processing of embedded TrueType fonts:

Ghostscript -> Native TTF Interpreter -> TTF OOB Write -> TTF OOB Read -> TTF Storage Pointer Hijack -> Arbitrary Read/Write -> Disable “path_control_active” -> %pipe%/bin/sh

Type 42 encapsulated TrueType fonts contain small programs used by Ghostscript’s native TrueType interpreter to adjust glyph geometry during rendering. When executing the SHZ (Shift Zone) and SHC (Shift Contour) instructions, Ghostscript validates a point index against the glyph’s main point array before using it to write into a smaller scratch array, modifying out-of-bounds memory.

To exploit this vulnerability, we groomed the TrueType interpreter heap such that useful interpreter state values were adjacent to the undersized twilight array. Abusing the vulnerability to manipulate adjacent state values helped us transform the out-of-bounds write into an out-of-bounds read/write primitive. This allowed us to hijack the TrueType interpreter’s storage pointer and achieve arbitrary read/write within the Ghostscript process. With this, we cleared the “path_control_active” flag, allowing us to write to "%pipe%/bin/sh" and achieve arbitrary command execution.

Securing the Pipeline: Defense in Depth

After we reported this vulnerability to Artifex, they informed us that Ghostscript 10.08 would remove support for the native TrueType interpreter entirely . Following the release of Ghostscript 10.08 in September, the issue is now considered to have been addressed and no CVE is expected to be assigned.

However, the vulnerability remains present in all versions of Ghostscript prior to 10.08, leaving downstream applications that depend on these versions exposed. This includes applications relying on outdated distribution packages (such as those provided by Ubuntu, Debian, and Fedora), as well as applications that bundle vulnerable versions or explicitly reference them in their configurations.

Thankfully, the existence of dangerous Ghostscript vulnerabilties does not imply that every application using Ghostscript is exploitable. There are several layers at which secure design and configuration may restrict access to the affected attack surface:

Secure the Application Endpoint

  • Validate all uploaded files on the server side. Do not rely on browser or client-side restrictions.
  • Only accept the file types the application actually requires.
  • Check the file extension, detected MIME type, and magic bytes before processing the file.
    • Reject the upload if these checks do not agree.
  • Do not trust the Content-Type header supplied with the request.
  • Use the file’s magic bytes as the primary indicator of its actual type before passing it to a parser or conversion library.

Define a Robust ImageMagick Policy

  • For applications that use ImageMagick, configure a restrictive policy.xml.
  • Start with a deny-by-default policy and explicitly enable only specific exceptions as required.
  • Disable formats that are not required by the application.
  • Disable PDF, PostScript, and SVG processing if the application does not need to support them.
  • Disable unused coders and delegates to reduce the available attack surface.

Harden Ghostscript Processing

  • For applications that use Ghostscript, ensure it runs with SAFER enabled.
  • Do not override or disable Ghostscript’s default security restrictions.
  • Keep Ghostscript up to date and avoid exposing functionality the application does not need.

Securely Contain File Processing

  • Do not process untrusted files inside the main application process where possible.
    • Send file-processing jobs to a separate low-privilege worker.
    • Give the worker access only to the commands, files, and services required for processing.
    • Do not expose application secrets, credentials, or unnecessary environment variables to the worker.
  • Avoid mounting host directories unless they are required.
  • Block unnecessary access to internal services and outbound network connections.
  • Use a read-only filesystem where practical.
  • Apply limits for CPU, memory, disk usage, file size, and execution time.

Ultimately, attack surface reduction remains one of the most effective defenses against zero-day exploitation. We believe few architectural decisions can do more to strengthen an application’s security posture, particularly as we confront this era of AI-assisted vulnerability discovery.

A Paradigm Shift in Application Security

A sufficiently determined, dedicated, or well-resourced attacker will eventually find a way through security defenses.

For years, this caveat served as a meaningful qualifier for a surprising number of security risks. However, the cost of meeting that threshold has fallen sharply. Threat models developed prior to 2026 should therefore reassess their assumptions about the likelihood of zero-day exploitation. Vulnerability management programs must be reassessed as well, given that serious vulnerabilities may be known to attackers long before receiving a CVE, if one is ever assigned at all.

The long tail of attack surface has not suddenly become more vulnerable. Instead, more of it has crossed the threshold of being worth investigating. Secure design and configuration are therefore more critical to application security than ever before.

Liondawn Labs

While effective security architecture may turn a serious vulnerability into a dead end, effective testing can tell you whether yours actually does. If you want to know if similar risks are exposed by your applications and what happens when one of the components underneath them fails, then let’s talk!

Timeline

  • 05/07/2026 - Liondawn Labs discovers the TTF vulnerability in Ghostscript.
  • 05/09/2026 - Liondawn Labs confirms the vulnerability is exploitable.
  • 08/23/2026 - Liondawn Labs reports the vulnerability to Artifex.
  • 08/24/2026 - Artifex responds: “In the upcoming 10.08.0 release, the entire (legacy) TTF bytecode interpreter is disabled, so the problematic code never gets called.”
  • 09/08/2026 - Artifex releases a patched version of Ghostscript.
  • 10/12/2026 - Liondawn Labs publicly discloses the vulnerability.