Ghostscriptに深刻な脆弱性、悪意あるPDFでリモートコード実行の恐れ

Ghostscriptに深刻な脆弱性が見つかりました。悪意のあるJPEG 2000画像を埋め込んだ特殊なPDFをアップロードするだけで、攻撃者が脆弱なサーバー上でコードを実行できる恐れがあります。

CVEdatabase access

この脆弱性は「CVE-2026-39919」として追跡されており、ヒープベースのバッファオーバーフローに分類されます。深刻度はCVSS v3.1で10点満点中9.8、CVSS v4.0で9.3と評価されました。認証不要でネットワーク経由のリモートコード実行が可能という、最悪の想定に相当するスコアです。

Wordfence Threat Intelligenceが、WordPress 7.1のセキュリティ評価中にこの問題を発見し、非公開で報告しました。これを受けてArtifexは2026年9月8日、問題を修正したGhostscript 10.08.0を公開しています。

影響を受けるのは10.08.0より前のGhostscriptです。問題はJPEG 2000出力アダプターにあり、特にコンポーネントごとのサブサンプリング係数が一致しない画像を処理するコードに存在します。

該当コードは、パックされた画像出力用にメモリを確保します。ところがその後、ビット深度に関係なく、出力列ごとに1バイト分を丸ごと書き込んでしまいます。

この不整合により、攻撃者が制御するデータがヒープバッファーからあふれ、Ghostscript内部のメモリ管理メタデータが破壊されます。条件が整えば、このメモリ破壊をコード実行に発展させることが可能です。

Wordfenceの研究者は、検証用に構築したWordPress環境で、認証なしのリモートコード実行を実証しました。

この攻撃チェーンはWordPress自体の脆弱性を突くものではありません。WordPress環境で一般的に使われる文書処理スタックを悪用します。

PDFがメディアライブラリに追加されると、WordPressはImagickを使うことがあります。ImagickはImageMagickを呼び出し、さらにImageMagickがGhostscriptを呼び出して、文書1ページ目のプレビュー画像を生成します。

つまり、悪意あるPDFは、PHPやWordPress本体を直接狙わなくても、脆弱なGhostscriptのプロセスに到達できます。

このため、匿名の訪問者や顧客、寄稿者、低権限ユーザーからPDFを受け付けるWebサイトでは、特に注意が必要です。

アップロードフォーム、文書ポータル、請求書処理システム、印刷サービス、メールゲートウェイ、プレビュー生成ツール、ファイル変換APIなども同様です。信頼できないPDFをGhostscriptで処理している場合、同じ攻撃対象領域にさらされる可能性があります。

Wordfenceの研究者によると、この脆弱性は、サブバイト単位のサンプル精度を持ち、コンポーネントごとに解像度が異なるJPEG 2000画像をGhostscriptが処理する際に発生します。

Ghostscriptの脆弱性

ただし、深刻度スコアが高いからといって、1つのエクスプロイトファイルですべてのサーバーが侵害されるわけではありません。Wordfenceの検証では、概念実証(PoC)のエクスプロイトはビルド固有でした。ある Ghostscript環境向けに作成したファイルは、10種類のLinuxパッケージ環境のすべてで、そのままでは成功しませんでした。

とはいえ、この制約があってもリスクがなくなるわけではありません。攻撃者は特定のソフトウェアビルドを狙ったり、共通のコンテナイメージを使うホストを見つけ出したり、一般的なホスティング環境向けにペイロードを調整したりできます。

ビルド固有の攻撃は、汎用的な攻撃より難しくなります。しかし、同一構成のインフラを運用する組織にとっては、依然として危険です。

Wordfenceが検証した公式WordPress Dockerイメージのスナップショットには、脆弱なGhostscriptパッケージと、動作するPDFプレビュー経路が含まれていたと報告されています。

標準のWordPressは、デフォルトでは匿名ユーザーによるPDFのアップロードを許可していません。しかし、プラグインやカスタムフォーム、会員機能、アプリケーションのルート、認証済みユーザーのロールによって、アップロード経路が提供される場合があります。

管理者は、WordPressのメディアライブラリだけでなく、PDFを受け付けて処理するすべてのワークフローを見直す必要があります。

CVE-2026-39919を修正するWordPressプラグインのアップデートはありません。対処はOSまたはコンテナイメージの層で行う必要があります。

管理者は、Linuxディストリビューションが提供する修正済みのGhostscriptパッケージをインストールし、ベンダーの再起動ガイダンスに従ってください。コンテナも、更新したベースイメージから再ビルドする必要があります。

ディストリビューションは、上流のバージョン文字列を古いまま保ちつつセキュリティ修正をバックポートすることがあります。そのため、Ghostscriptのバージョン表示だけで判断すると、誤解を招く恐れがあります。

Securityincident response

すぐにパッチを適用できない組織は、信頼できないPDFのアップロードを停止するか、ImageMagickのセキュリティポリシーでPDFレンダリングを無効にしてください。

文書変換を、権限を最小限に絞った隔離サービスで実行すれば、侵害後の被害を抑えられます。ただし、根本にあるメモリ破壊の脆弱性そのものは解消されません。

今回の問題は、Webアプリケーションが抱えるサプライチェーン上の現実を浮き彫りにしています。日常的なファイルアップロード機能の裏側で、アプリケーション層の下にある複数の隠れた依存コンポーネントが呼び出される場合があるのです。

今回のケースでは、WordPressがPDFをImagick、ImageMagick、そして最終的にGhostscriptへ引き渡す可能性があります。ネイティブの文書レンダリングコンポーネントに脆弱性があれば、アップロードが発生したコードをはるかに超えて、サーバー侵害のリスクにつながり得ます。

平均対応時間(MTTR)を21分短縮し、被害が出る前にサイバー脅威を阻止します。ANY.RUNのサンドボックスをSOCに統合する。

翻訳元: https://gbhackers.com/ghostscript-vulnerability/

本記事は gbhackers.com の記事を翻訳・要約したものです。