Pillowの脆弱性まとめ｜2026年7月の13件はすべて12.3.0で解決 CVE-2026-54058ほか

Pythonで画像を扱うライブラリPillowに、2026年7月、13件の脆弱性がまとめて公表されました。うち10件が深刻度「高（High）」です。そして幸いなことに、対処は「12.3.0へ上げる」の一手だけで、13件すべてが塞がります。

Pillowは、Pythonで画像のリサイズ・変換・サムネイル生成などを行うときにほぼ必ず使われるライブラリです。自分で入れた覚えがなくても、WebフレームワークやCMS、機械学習まわりのパッケージが裏で依存していることが珍しくありません。「利用者がアップロードした画像を受け取って処理している」システムは、まず対象だと考えてください。

この記事では、13件が何をされうるものなのか、自分の環境は影響を受けるのか、どう確認して何をすればいいのかを順に整理します。本記事はPillowの脆弱性を継続して追うページとして、今後新しい公表があれば公表時期ごとに追記していきます。

2026年7月に公表された13件

2026年7月6日と7月14日の2回に分けて、合計13件のPillowの脆弱性が脆弱性データベース（NVD）に公開されました。13件すべてが Pillow 12.3.0 で修正済みです。深刻度の内訳は次の通りです。

注目してほしいのは、13件のなかに「危険度9.0以上（Critical）」が1件もない点です。そのため、Criticalだけを追いかけるニュースやまとめでは、この13件はまとめて見落とされがちです。しかし後述するように、中身は「細工した画像ファイルを1枚読み込ませるだけ」で成立するものが並んでいます。スコアの数字だけで判断すると、実態を取り逃がす典型例です。

13件はどう分類できるか（2026年7月分）

1件ずつ読むと大変なので、起きることで3つに分けます。どれも入口は同じで、「攻撃者が用意した画像やフォントのファイルを、システムが読み込んでしまう」ことで成立します。

① メモリを壊す書き込み・領域外の読み出し（5件）

もっとも重い分類です。Pillowは処理の重い部分をC言語で書いており、そこで確保した領域の外にデータを書いてしまう不具合が3件、外を読み出してしまう不具合が2件見つかりました。前者は専門用語で「ヒープ領域の境界外書き込み（heap out-of-bounds write）」と呼びます。プログラムが確保したメモリの箱からはみ出して書き込む状態で、うまく作り込まれると、そのまま任意のプログラムを実行される足がかりになりえます。後者は箱の外を読んでしまうもので、他の処理が使っているメモリの中身が漏れます。

このうちCVE-2026-54058（8.3）が今回の最高スコアで、書き込みではなく「領域外の読み出し」です。細工したヘッダで行の幅を実際より小さく偽ると、画像を読んだあとにtobytes()やgetpixel、convert、saveを呼んだ時点で、本来関係のないプロセスのメモリの中身が画像データとして読み出されてしまいます。読み出された内容は、変換後の画像や保存したファイルに混ざって外に出ていく可能性があります。

似た性質のものがもう1件あります。CVE-2026-59198（6.5）は、モード1の画像をTGA形式のRLE圧縮で保存するときに、バッファの外を読んで隣接するメモリの中身が生成されたTGAファイルに混入するというものです。読み込みではなく保存で起きる点が特徴で、「変換した画像をユーザーに返す」処理があると、そのまま外部に流出しうる形になります。

② メモリを食い尽くさせる（6件）

2つ目は、小さなファイルで巨大なメモリを確保させ、サービスを止めるタイプです。いわゆる「展開爆弾（decompression bomb）」で、数KBのファイルが展開時に数GBに膨らむ、といった挙動をします。

PillowにはもともとImage._decompression_bomb_check()という安全確認の仕組みがあり、極端に大きな画像を弾くようになっています。ところが今回の4件（CVE-2026-54059・54060・55379・55380）は、フォントファイルやGD形式の読み込み経路で、この確認を呼ばずに寸法をそのまま信じていたという共通の欠陥です。用意されている防御を素通りしていた、というのが問題の本質です。

残る2件も同じ「メモリを食わせる」系です。CVE-2026-59200はPDFの圧縮ストリームを展開するとき、展開後のサイズに上限を設けていなかったもの。CVE-2026-59204は、タイルに分かれたJPEG 2000画像で、本来タイルごとに計算し直すべき幅をタイルの数だけ足し込んでしまい、必要以上のメモリを確保するというものです。どちらも小さなファイルでメモリ不足を起こせます。

③ その他（2件）

CVE-2026-59203（5.3）はEPS形式の解析で、マイナスのバイト数を受け入れてしまうため、ファイルの読み取り位置が戻り続けてImage.open()が無限ループに陥ります。処理が返ってこなくなるので、実質的にはサービス停止です。

CVE-2026-55798（4.5）は毛色が違い、Windowsで画像を表示するときにコマンドが注入できるものです。WindowsViewer.get_command()がファイルパスをそのままシェルコマンドに埋め込んでいたため、パスにシェルの特殊文字を含められると任意のコマンドを実行できます。ただし成立するのはWindows上でImage.show()系の表示機能を使っている場合に限られ、サーバー用途ではまず該当しません。

自分の環境は影響を受けるのか

判断の軸は2つだけです。「Pillowを使っているか（間接的にでも）」と「外から来た画像を処理しているか」です。

自分が直接pip install pillowしていなくても、対象になりうる点に注意してください。PillowはDjangoの画像フィールド、Wagtailなどのコンテンツ管理システム、各種の機械学習ライブラリなどが依存として引き込みます。手元のバージョンは次のコマンドで確認できます。

pip show pillow | grep -i version
# または、依存関係のどこから入っているかまで見る
pip list | grep -i pillow

12.3.0より前であれば対象です。なお、Prior to 12.3.0と書かれているものが大半ですが、一部は影響範囲が限定されています。CVE-2026-59200は5.1.0以降、CVE-2026-59198は5.2.0以降、CVE-2026-59204は8.2.0以降、CVE-2026-59203は12.0.0以降です。いずれにせよ12.3.0へ上げれば全部まとめて解決するため、細かい切り分けをする必要はありません。

では何をすればいいのか

やることは1つです。Pillowを12.3.0以降に上げる。それだけで13件すべてが解消します。

pip install --upgrade "pillow>=12.3.0"

バージョンを固定して運用している場合は、依存を固定しているファイル（requirements.txt、pyproject.toml、ロックファイルなど）の側を更新してください。Pillowが間接的な依存（自分では書いていない依存）として入っている場合、上位のパッケージの制約に引っかかることがあります。その場合はロックファイルだけを更新する方法が使えます。

# uv を使っている場合、間接依存だけを上げる
uv lock --upgrade-package pillow

# poetry の場合
poetry update pillow

あわせて、HEIC形式を扱っている場合はpillow-heifも確認してください。こちらも別途CVE-2026-28231が公表されており、1.3.0以降で修正されています。

更新がすぐにできない事情がある場合の緩和策としては、受け付ける画像形式を絞るのが有効です。今回の13件のうち、フォント（PCF・BDF）、GD、PDF、JPEG 2000、EPS、McIdas AREA、TGAといった、業務ではまず使わない形式が起点になっているものが大半を占めます。JPEG・PNG・WebPだけを受け付ける作りにしておけば、攻撃面はかなり狭まります。ただしこれはあくまで時間稼ぎで、本筋は更新です。

よくある質問

Q. Critical（9.0以上）が1件もないなら、急がなくていいのでは。

A. スコアと実際の危なさは必ずしも一致しません。今回の最高は8.3ですが、内容は「細工した画像を1枚読ませるだけでプロセスのメモリが読み出される」というものです。Pillowを使うシステムの多くは、外部から来た画像を読み込むこと自体が仕事なので、攻撃の前提条件がほぼ常に満たされていると考えたほうが実態に近いです。定例更新で構いませんが、次のタイミングでは確実に上げてください。

Q. 実際に攻撃された事例はありますか。

A. 本記事の執筆時点で、米政府CISAが公開する実際に攻撃されている脆弱性のリスト（KEV）には、今回の13件はいずれも登録されていません。ただし、KEVは「悪用が確認された」ものが載る後追いの仕組みです。登録されていないことは、安全の証明にはなりません。

Q. 13件も一度に出るのは異常なのでは。Pillowは危ないライブラリですか。

A. そうとは限りません。Pillowは対応している画像形式が非常に多く、そのぶん解析コードの量も多いため、まとめて監査すると件数がまとまって出やすい性質があります。むしろ、報告を受けて短期間に13件を修正して1つのバージョンで出したことは、開発が生きている証拠と読むべきところです。放置されているライブラリのほうが、はるかに危険です。

Q. 自社のどこでPillowが使われているか把握できていません。

A. まずは依存関係を機械的に洗い出すところからです。GitHubを使っているならDependabotの脆弱性アラート（依存グラフ・アラート・セキュリティ更新の3つ）を有効にすると、リポジトリ単位で対象と修正版が一覧できます。OSSサプライチェーンの点検の考え方もあわせて参考にしてください。

まとめ

2026年7月に公表されたPillowの13件は、すべて12.3.0で修正済みです。内訳は、メモリの壊れる書き込みや領域外の読み出しが5件、小さなファイルでメモリを食い尽くさせるものが6件、無限ループとWindows限定のコマンド注入が各1件。入口はいずれも「攻撃者が用意した画像・フォントのファイルを読み込ませる」という共通の形です。

Critical（9.0以上）が1件もないため、深刻度の数字だけを追う運用では丸ごと見落とされます。しかしPillowは、利用者からの画像アップロードを受ける多くのシステムの土台にあり、しかも自分では入れた覚えがなくても入っていることが多いライブラリです。「うちは画像を扱っているか」ではなく「うちのどこかにPillowが入っていないか」から確認するのが、今回の正しい入り方だと思います。

対処はpillow>=12.3.0への更新一手です。間接依存で入っている場合はロックファイル側だけを上げれば済みます。HEICを扱っているならpillow-heifも1.3.0以降へ。まずは手元の環境でバージョンを確認するところから始めてください。

本記事は、今回の13件について実際の悪用や実証コード（PoC）の公開が確認された場合、およびPillowに新しい脆弱性が公表された場合に追記・更新します。Pillowの脆弱性を追う際は、このページを起点にしてください。

参照元

• ▸Pillow - Security Advisories（GitHub 公式）
• ▸NVD - CVE-2026-54058（CVSS 8.3・今回の最高スコア）
• ▸NVD - CVE-2026-59197（CVSS 8.2・RankFilter）
• ▸NVD - CVE-2026-59199（paste / crop / alpha_composite）
• ▸NVD - CVE-2026-59205（ImageCms）
• ▸NVD - CVE-2026-59200（PDF 展開爆弾）
• ▸NVD - CVE-2026-59204（JPEG 2000）
• ▸NVD - CVE-2026-59198（TGA 保存時の情報混入）
• ▸NVD - CVE-2026-59203（EPS 無限ループ）
• ▸NVD - CVE-2026-55798（Windows コマンド注入）
• ▸NVD - CVE-2026-28231（pillow-heif）
• ▸Pillow 12.3.0 リリースノート