CVE-2026-101258: Ghostscript: ghostscript: -dsafer sandbox bypass via type 5 shading oob write and procedure-stream use-after-free
A flaw was found in Ghostscript. When Ghostscript renders a crafted PostScript or EPS document, it can bypass the -dSAFER sandbox and execute arbitrary shell commands in the context of the Ghostscript process. The issue chains memory corruption in document parsing with disabling of internal path access controls at runtime. An attacker can deliver the document directly or through formats that delegate rendering to Ghostscript (for example EPS import or print conversion workflows). Successful exploitation can compromise confidentiality, integrity, and availability of data accessible to the process running Ghostscript.
Other sources
Ghostscript's -dSAFER sandbox can be bypassed by a crafted PostScript document that chains two memory-safety bugs to achieve arbitrary command execution in the Ghostscript process context.
Bug 1 , Procedure-source filter stream use-after-free (psi/zfproc.c): The sprocreadcontinue function stores a procedure's returned string via a raw C assignment (ss->data = opbuf at line 323) without a save/restore write barrier. A procedure stream created in global VM can be tricked into holding a reference to a local-VM string; after save/restore frees that string, the stale reference enables a heap information leak that defeats ASLR. The 10.09.0 source contains a cross-space copy defense (sproccopystring, lines 313-321) and save-ID tracking (sprocrecorddata/sprocdatavalid), but the PoC was confirmed working on versions through 10.07.1, suggesting these defenses are either recent additions or bypassable.
Bug 2 , Shading Function array out-of-bounds heap write (base/gsshade.c, base/gsfunc3.c, psi/zshade.c): checkCBFD validates the number of output components for a shading Function, but when the Function is an array, it checked only the ArrayedOutput (AdOt) wrapper's n field (set to the array length). A single-element array wrapping a sub-function with many outputs passes the n==ncomp check. At evaluation, fnAdOtevaluate (gsfunc3.c line 643-648) calls gsfunctionevaluate for each sub-function passing out+i as the output pointer, assuming 1 output per sub-function. If the sub-function actually writes multiple outputs, this overruns the color buffer. The 10.09.0 source contains a fix in checkCBFD (lines 82-93) that validates each sub-function declares exactly 1 output.
The exploit chain: (1) UAF leak recovers a PIE code pointer and heap pointers; (2) Type 5 shading OOB write overwrites a SubFileDecode stream's read cursor to build an arbitrary-read primitive; (3) Structural memory scanning locates gslibctxcoret.pathcontrolactive; (4) Shading write sets pathcontrolactive to 0; (5) Normal PostScript %pipe% support executes the command.
The PoC was publicly released by V12 Security on 2026-09-26 at https://github.com/v12-security/pocs/tree/main/ghostscript following a talk at BSides Canberra 2026. Confirmed working on Ghostscript 10.00.0 through 10.07.1 across Alpine, Arch, Debian, Fedora, and Ubuntu. Dynamic testing in sandbox confirmed the UAF leak primitive works on GS 10.06.0 (Fedora) but full exploitation failed due to aarch64 architecture mismatch (PoC targets x86-64). The GhostPDL 10.09.0 source contains apparent fixes for both bugs.
Red Hat dynamic verification (RHEL 10.2 x8664 lab host): ghostscript-10.02.1-16.el10 (CentOS Stream 10) and ghostscript-10.02.1-16.el100 (UBI 10) both executed a shell command with -dSAFER; gs exited with signal 139 after proof file write.
Reporter: Akiyoshi Kurita (ticket submitter); original research by V12 Security. PSIRT ticket: PSIRTSUPT-24732
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Ghostscriptto a version that resolves this vulnerability.Fixed in 10.09.0