A heap buffer overflow in the widely deployed Ghostscript interpreter could let attackers execute code on a server simply by getting it to process a malicious PDF file, according to a report published by BleepingComputer.
The flaw, tracked as CVE-2026-39919, affects the Ghostscript rendering engine and interpreter itself. BleepingComputer's account describes the bug as a heap buffer overflow that can be triggered through specially crafted PDF documents, potentially yielding remote code execution in the context of the vulnerable service. Organisations running Ghostscript directly, or indirectly through tools that shell out to it, should treat this as a patch-now issue.
Why the attack surface is wider than it looks
What makes this class of bug especially concerning is not the vulnerability in isolation but the deployment pattern around it. In many production environments, PDF conversion, thumbnailing, print spooling, and file-upload sanitisation are fully automated and unattended. An uploaded document is routed to a server-side converter with no human in the loop, meaning a single crafted file can reach the vulnerable code path the moment it lands in a queue.
The dependency chain is easy to miss. Ghostscript frequently sits beneath higher-level applications rather than being invoked directly: ImageMagick and GraphicsMagick commonly enable ghostscript (or gs) delegates by default, and those delegates are often forgotten during asset audits. The practical consequence is two-fold:
- Application-level updates may not be enough. Patching ImageMagick or GraphicsMagick does not necessarily update the underlying Ghostscript library. Only updating the operating system's Ghostscript package closes the gap at the interpreter layer.
- Restart services after patching. Long-running conversion workers keep their loaded libraries in memory. A package update alone will not protect a daemon that has been running since before the fix was released — a restart is required before the new code takes effect.
For teams that want to check exposure quickly, inspecting the enabled delegates in ImageMagick's policy and configuration files, or checking which Ghostscript package version is installed on each host, is the fastest route to knowing whether unintended PDF-to-Ghostscript paths exist.
Patch checklist
BleepingComputer's report is the reference point for affected and fixed versions; administrators should confirm the specific fixed release against their distribution's security advisory rather than relying on version heuristics. A pragmatic same-day response looks like this:
- Inventory hosts where the
gsbinary is present or where ImageMagick/GraphicsMagick delegates reference it. - Apply the vendor or distribution package update for Ghostscript on every one of those hosts.
- Restart the conversion services, queue workers, and web applications that load the library — this step is routinely skipped and is not optional.
- If patching cannot be completed immediately, block or quarantine inbound PDF uploads at the edge until the interpreter is updated.
- Retain the advisory reference and track whether the CVE is subsequently added to known-exploited vulnerability catalogues, which changes the remediation posture for many compliance regimes.
Disclosure status
As of publication, the disclosure details and exploitation status rest on BleepingComputer's reporting; this article does not assert that public proof-of-concept code exists or that in-the-wild exploitation has been observed. Given the unattended nature of typical conversion pipelines, however, the practical exposure window for unpatched servers begins as soon as the flaw is publicly understood.
Relevance for Hong Kong teams
Plenty of Hong Kong organisations run Linux-based document conversion, print, or upload workflows that quietly depend on Ghostscript — often through an ImageMagick delegate nobody remembers configuring. Any team in that position should verify their package version today and restart their workers after updating; the library-level fix is the only one that reliably closes this hole.
據 BleepingComputer 發布的報告指，廣泛部署的 Ghostscript 解譯器存在一個堆積緩衝區溢位（heap buffer overflow）漏洞，攻擊者只需讓伺服器處理一份惡意 PDF 檔案，便可能在該伺服器上執行任意代碼。
該漏洞編號為 CVE-2026-39919，影響 Ghostscript 渲染引擎及解譯器本身。BleepingComputer 的報道將此缺陷描述為可透過特製 PDF 文件觸發的堆積緩衝區溢位，最終可能在受影響服務的權限上下文中實現遠端代碼執行（remote code execution）。無論是直接執行 Ghostscript 的機構，或透過其他工具間接呼叫它的系統，都應視此為需即時修補的項目。
攻擊面比表面看來更廣
這類漏洞之所以格外令人擔憂，關鍵並非漏洞本身，而是其周邊的部署模式。在許多生產環境中，PDF 轉換、縮圖生成、列印佇列處理（print spooling）及檔案上載檢查均為全自動化、無人值守的流程。上載的文件會直接送往伺服器端轉換器處理，中間沒有人工介入，這意味著單一特製檔案一進入佇列，便可立即接觸到存在漏洞的程式路徑。
依賴關係往往容易被忽略。Ghostscript 通常位於較高階應用程式「之下」運作，而非被直接呼叫：ImageMagick 及 GraphicsMagick 一般預設啟用 ghostscript（或 gs）delegate，而這些 delegate 往往在資產盤點時被遺漏。實際影響有兩方面：
- 只更新應用程式未必足夠。 修補 ImageMagick 或 GraphicsMagick 並不代表底層的 Ghostscript 函式庫同步更新。唯有更新作業系統的 Ghostscript 套件，才能在解譯器層面封堵漏洞。
- 修補後必須重新啟動服務。 長時間執行的轉換 worker 會將已載入的函式庫保留在記憶體中。僅更新套件並不能保護那些在修補程式發布前已啟動的常駐服務（daemon）——必須重新啟動，新代碼才會生效。
希望快速評估風險暴露程度的團隊，最直接的方法是檢查 ImageMagick 的 policy 及設定檔中已啟用的 delegates，或逐一確認各主機安裝的 Ghostscript 套件版本，以判斷是否存在非預期的 PDF 至 Ghostscript 處理路徑。
修補清單
BleepingComputer 的報告列出了受影響及已修復的版本，管理員應對照所用發行版的安全公告（security advisory）確認具體的修復版本，而非依賴版本號推測。務實的即日應對措施如下：
- 盤點所有存在
gs執行檔，或 ImageMagick／GraphicsMagick delegate 引用到 Ghostscript 的主機。 - 在上述每一台主機上套用原廠或發行版提供的 Ghostscript 套件更新。
- 重新啟動所有載入該函式庫的轉換服務、queue worker 及 Web 應用程式——此步驟經常被略過，但絕非可選。
- 如未能即時完成修補，應在邊緣節點（edge）封鎖或隔離所有進入的 PDF 上載，直至解譯器更新完畢。
- 保存安全公告參照資料，並追蹤該 CVE 日後是否被列入已被利用漏洞目錄（known-exploited vulnerability catalogue）——一旦納入，多種合規框架下的修補要求將隨之改變。
披露狀況
截至本文刊出時，有關披露細節及漏洞是否已被利用，均以 BleepingComputer 的報道為依據；本文並未斷言公開的概念驗證（proof-of-concept）代碼已經存在，亦未指稱已在實際環境中觀察到 exploit 活動。然而，考慮到典型轉換 pipeline 全程無人值守的特性，未修補伺服器的實際風險暴露時間窗，自缺陷被公開理解的那一刻起便已開始。
對香港團隊的啟示
不少香港機構運行的 Linux 文件轉換、列印或上載流程，其實一直悄悄依賴 Ghostscript——通常是透過一個連團隊自己都忘記曾設定的 ImageMagick delegate。任何身處此情況的團隊，都應今日立即核實其套件版本，並在更新後重新啟動 worker；唯有函式庫層面的修補，才是可靠封堵此漏洞的唯一方法。