2026年10月16日、マイナビニュースに「Ghostscriptに深刻な脆弱性」という記事が出ました。
細工したPDFを処理させるだけで、サーバー上で任意のコードを実行されるおそれがある。CVSSは9.8で「緊急」。WordPressがPDFからサムネイルを作るときに通る経路が、名指しで攻撃面として挙げられていました。
読みながら、自分のプラグインのことを考えていました。私はWordPress.orgで「Rapls PDF Image Creator」というプラグインを公開しています。PDFをアップロードすると、表紙の画像を自動で作るプラグインです。中身はImagickでPDFを読み込んで描画しているので、裏ではImageMagickを経由してGhostscriptが動いています。記事に書かれた経路と、ほぼそのまま重なります。
そこで、報道だけで済ませず、CVEの登録情報、ディストリビューションのセキュリティトラッカー、Ghostscript開発元のリリースまでたどって確認しました。この記事は、その確認の記録です。同じようにWordPressでPDFを扱っているサイトの方と、一緒に順を追って見ていければと思います。
発見から報道まで、何が起きたのか
時系列で並べると、話がすっきりします。
始まりは2026年8月23日です。WordPressのセキュリティ企業として知られるWordfence（運営はDefiant）の研究者が、AIを使った解析システム「Argus」で、Ghostscriptの欠陥を見つけました。
Ghostscriptの開発元であるArtifexは、9月8日に修正版の10.08.0を公開しています。報告からおよそ2週間です。9月15日にはCVE-2026-39919として脆弱性情報が登録されました。
その後、10月13日に海外のBleeping Computerが詳しく報じ、10月16日に国内のマイナビニュースが続きました。報道でこの件を知った人の多くにとって、修正版はすでに1か月以上前に出ていたことになります。
この流れを1枚にすると、次の図のようになります。修正の公開から報道まで、ひと月あまり空いているのが分かると思います。
余談ですが、脆弱性の世界では、修正が出てから広く報じられるまでに時間差があるのは珍しくありません。開発元が直し、ディストリビューションが取り込み、そのあとで研究者が詳細を公表する、という順番を踏むことが多いからです。読む側からすると「今ごろ？」と感じますが、その間に直せる人には直す時間が与えられていた、とも言えます。
どんな欠陥なのか
欠陥は、GhostscriptがPDFの中のJPEG 2000画像を処理する部分にあります。ソースでいうと base/sjpx_openjpeg.c という、JPEG 2000のデコードを担うOpenJPEGとの橋渡しの部分です。
JPEG 2000の画像は、色の成分ごとに解像度（サブサンプリングの係数）を変えられます。この係数がわざと食い違うように作られた画像で、しかも1ピクセルが1バイトに満たない低いビット深度のとき、Ghostscriptは行のバッファに本来より多くのデータを書き込んでしまいます。Bleeping Computerの説明では、256バイト分の領域に1,024バイトを書き込ませる、という形です。
はみ出した分が周りのメモリを壊し、条件がそろえば、そこから任意のコードの実行に至ります。分類としては、ヒープベースのバッファオーバーフロー（CWE-122）です。
影響を受けるのは、Ghostscript 10.08.0より前のバージョンです。報道では9.21から10.07.1までとされています。深刻度は、CVSS v3.1で9.8、v4.0で9.3と、どちらの基準でも最高ランクの「Critical」でした。
ただし、「必ず乗っ取られる」わけではない
ここは落ち着いて読みたいところです。
Wordfenceは実際に攻撃コードを2種類作って試しています。結果は、Linuxの標準パッケージ環境では10,240回実行しても任意コード実行に至りませんでした。専用に組んだテストサーバーでは遠隔からのコード実行に成功しましたが、成功したのはフォント、言語設定、フォント構成、基幹ライブラリのどれかを変えたときで、それでも毎回ではありません。
つまり、成否はサーバーの環境に大きく左右されます。そして2026年10月17日の時点で、実際の攻撃に使われたという報告はありません。慌てる必要はありませんが、放っておいていい話でもない、というのが私の受け止め方です。
WordPressのどこを通って届くのか
WordPressは、PHPのImagick拡張が使えるサーバーでは、PDFをアップロードしたときにプレビュー画像を自動で作ります。WordPress 4.7からの標準の動きです。このとき、ImagickがImageMagickを呼び、ImageMagickはPDFを読むためにGhostscriptを呼びます。PDFの中にJPEG 2000画像が入っていれば、そこで今回の欠陥のある処理を通ります。
次の図が、その経路です。私のプラグインのようなPDFサムネイル系のプラグインも、WordPress本体のプレビュー生成も、同じ道を通ってGhostscriptにたどり着きます。
Bleeping Computerは、WordPressで攻撃が成り立つ条件を4つ挙げています。
1. 攻撃者がPDFをアップロードできる
WordPressの初期設定では、匿名でメディアライブラリにアップロードすることはできません。ファイルをアップロードする権限（upload_files）を持っているのは、標準では投稿者（Author）以上です。
気をつけたいのは、フォーム系や会員系のプラグインを入れていて、ログインしていない人や信頼しきれない会員から受け取ったPDFが、メディアライブラリに入ってくる構成です。応募書類や見積もり依頼のPDFを受け付けているサイトは、自分のサイトがこれに当たるかどうかを一度確認しておくと安心です。
2. サイトがそのPDFを処理する
プレビューやサムネイルを作るために、PDFを実際に開いて描画することです。WordPress本体が自動でやりますし、PDFのサムネイルを作るプラグインもやります。
3. 処理がGhostscriptまで届く
サーバーにImagickとImageMagick、Ghostscriptがそろっていて、ImageMagickの設定ファイル（policy.xml）でPDFの読み込みが禁止されていないことです。共用サーバーではPDFを禁止していることが多い、と言われますが、私が2026年8月に確かめた範囲では、Xserverのスタンダードプランは禁止していませんでした。
4. Ghostscriptが修正されていない
最後の条件がこれです。逆に言えば、ここさえ満たさなければ、1から3がそろっていても今回の欠陥は突かれません。
Rapls PDF Image Creatorはどうなのか？
作者として、正直に書いておきます。
Rapls PDF Image Creatorは、プラグインの中からGhostscriptを直接呼び出してはいません。WordPress.orgの規約上もexecのような外部コマンドの実行は使えないので、PDFの描画はすべてImagick経由です。ただ、ImageMagickの内部でGhostscriptが動く以上、今回の経路からは外れません。条件の2と3に、そのまま当てはまります。
一方で、このプラグインを入れたことで新しく危険が生まれるわけでもありません。先ほど書いたとおり、ImagickとGhostscriptが入っているサーバーなら、WordPress本体がPDFのアップロード時に同じ経路で描画しているからです。プラグインを止めても、本体のプレビュー生成は動き続けます。危ないかどうかを決めるのは、プラグインの有無ではなく、サーバーのGhostscriptが修正済みかどうかです。
有料アドオンのPDF Image Creator Proも同じです。Proは、表紙にするページの指定やトリミングといった設定を無料版に渡す作りで、PDFの描画そのものは無料版と同じ経路で行っています。Proをお使いの方も、確認していただくのはサーバーのGhostscriptです。
そして、ここはプラグインの側からは直せません。Ghostscriptはサーバーに入っているソフトなので、更新できるのはサーバーの管理者、共用サーバーならホスティング会社です。
私の手元の環境も確認しました。2026年9月にXserverで計測したときのGhostscriptのバージョンは9.27で、番号だけを見れば影響範囲に入ります。ただ、これだけでは「危ない」とは言い切れません。Linuxディストリビューションのパッケージでは、バージョン番号はそのままに修正だけを古い版に取り込む「バックポート」がよく行われるからです。実際、Debianのセキュリティトラッカーを見ると、trixie（Debian 13）は10.05.1という番号のまま修正済みのパッケージが出ています。一方、bookworm（Debian 12）は10月17日時点で、まだ修正版が出ていませんでした。番号だけで判断すると、どちらの方向にも間違えます。
なお、このプラグインには、サーバーのImageMagickがPDFを読めるかどうかを確かめる環境チェックがあります。チェックのために、数百バイトの小さなPDFをその場で作って読み込ませていますが、このPDFはプラグインが自分で生成するもので、JPEG 2000の画像は含みません。今回の欠陥を突く入力にはならない、ということも念のため書いておきます。
では、何をすればいいのか
やることは、順番に判断していくとシンプルです。次の図のとおり、まず「Ghostscriptが修正済みか」を確かめ、そうでなければ更新、更新できなければ入口を絞る、という流れになります。
Ghostscriptが修正済みかを確認する
自分で管理しているサーバー（VPSや専用サーバー）なら、OSのパッケージを更新し、ディストリビューションのセキュリティ情報でCVE-2026-39919が修正済みになっているかを確かめます。Ghostscript本体を自分でビルドしているなら、10.08.0以降にします。
共用サーバーなら、ホスティング会社に「Ghostscriptに、CVE-2026-39919の修正は適用済みですか」と問い合わせるのが確実です。CVE番号を添えると、話が早く通ります。
Dockerで動かしているなら、イメージを作り直す
Wordfenceは、公式のWordPress Dockerイメージのスナップショットにも、脆弱なコードが含まれていたと報告しています。コンテナの中のGhostscriptは、ホスト側を更新しても変わりません。修正済みのベースイメージでビルドし直して、配備し直す必要があります。
すぐに更新できないときは、入口を絞る
ひとつは、信頼できない人からのPDFアップロードを止めることです。フォームでPDFを受け付けているなら、一時的に止めるか、受け取ったファイルをメディアライブラリに入れない設定にします。
もうひとつは、ImageMagickでのPDFの描画そのものを止めることです。policy.xmlに次の1行を入れると、ImageMagickはPDFを読まなくなり、Ghostscriptまで処理が届かなくなります。
| 1 | <policy domain="coder" rights="none" pattern="PDF" /> |
ただし、この方法を選ぶと、WordPress本体のPDFプレビューも、Rapls PDF Image Creatorのようなサムネイル系プラグインも、まとめて動かなくなります。安全と引き換えの、一時しのぎの手段です。ちなみにRapls PDF Image Creatorでは、この状態になると環境チェックが「policy.xmlでPDFが禁止されています」と表示するので、なぜ画像ができないのかが分からなくなることはありません。修正版が入ったら、この行を外して元に戻します。
最後に
10月16日の記事を読んだときに考えたのは、「自分のプラグインが原因で、使ってくれている人のサイトに穴が開いていないか」ということでした。
たどってみると、穴はプラグインではなくサーバーのGhostscriptにあって、WordPress本体も同じ経路を使っている、というのが答えでした。プラグインを止めても解決しませんし、プラグインを入れたから増える危険でもありません。やるべきことは、Ghostscriptが修正済みかどうかを確かめることです。
PDFを扱うWordPressサイトを運営している方は、この週末にでも、ホスティング会社のお知らせを確認するか、問い合わせを1本送ってみてください。Xserverでの確認結果は、分かり次第この記事に追記します。
参考（一次情報）
- CVE-2026-39919（OSV） ── CVEの説明文、CVSS v4.0、修正コミット
- CVE-2026-39919（Debian Security Tracker） ── Debian各リリースの修正状況
- Ghostscript 10.08.0 リリース（Artifex）
- Ghostscript Bug 709666
- NVD: CVE-2026-39919
- Ghostscript flaw lets hackers hijack servers via PDF uploads（Bleeping Computer）
- マイナビニュース TECH+
Rapls Works のその他の記事
- Rapls PDF Image Creator｜WordPress PDFサムネイル生成プラグイン ── PDF をアップロードすると、自動でサムネイル画像を生成するプラグイン。
- Rapls AI Chatbot ガイド｜WordPress AIチャットボットの導入から運用まで ── WordPress に AI チャットボットを設置できるプラグイン。
コメント