セキュリティ

Pillow 脆弱性:13.0.0で直った42件の影響確認とPython 3.10環境の更新手順

Pillow 脆弱性:13.0.0で直った42件の影響確認とPython 3.10環境の更新手順

Pythonの画像処理ライブラリPillowは、2026年10月16日に公開した13.0.0で42件の脆弱性をまとめて修正しました。CVSS v3.1で9.8のCVE-2026-96639をはじめ、細工した画像を開くだけでコードが実行されうる不具合が複数含まれます。この記事では、勧告の中身、自分の環境が影響を受けるかを調べるコマンド、Python 3.10環境に修正版が出ない問題、更新までのつなぎになる防御コードを順に整理しました。内容は2026年10月24日時点の公開情報にもとづきます。

まとめ:13.0.0未満は全て更新、Python 3.10環境はPythonから上げる

修正版は13.0.0だけで、12系への修正版は出ていません。12.3.0を含む13.0.0未満はすべて更新の対象です。ところがPillow 13はPython 3.11以上でしか動かないため、Python 3.10の環境はPillowより先にPython本体を上げる必要があります。

急ぐべきは、利用者がアップロードした画像をPillowで自動的に開く処理です。サムネイル生成やプロフィール画像の加工が典型で、1回のリクエストで攻撃が成立しうる構造になっています。どの処理が外部の画像を受け取っているか分からない場合は、脆弱性診断・セキュリティ診断でアップロード経路ごと洗い出すと漏れが減ります。

13.0.0の勧告42件:Critical 5件の中身と悪用状況の確認結果

まず、何が直ったのかを重い順に押さえます。

CVE-2026-96639は複数フレーム画像を読むときのCVSS 9.8の不具合

最も評価が高いのはGHSA-v9pv-5gc8-w2m6(CVE-2026-96639)です。PSD・MPO・DCX・MICのように1つのファイルに複数の画像(フレーム)を持つ形式で、1枚目のために確保したメモリを、色の形式が違う2枚目の読み込みに使い回してしまう不具合でした。1枚目をグレースケール、2枚目をRGBやCMYKにした細工ファイルで、確保した領域の外へ書き込みが起きます。

報告者は、MPO形式の細工ファイルを受け取るWebのアップロード処理を手元に用意し、1回のHTTPリクエストで決められたコマンドを10回中10回実行させたと書いています。評価ベクトルはCVE.orgのレコードどおり「AV:N/AC:L/PR:N/UI:N」で、認証も利用者の操作も要りません。数値の読み方はCVSSv3の計算式とスコアの目安で確認できます。影響範囲は11.0.0以上13.0.0未満です。

FPX・JPEG・TIFF保存・EPS4件:CVSS v4.0は9.2・Critical

GitHub Advisory Databaseで重大度がCriticalになっているのは、2026年10月24日時点で次の5件です。

勧告 CVE 評価 内容 影響範囲
GHSA-v9pv-5gc8-w2m6 CVE-2026-96639 v3.1 9.8 複数フレーム画像のメモリ再利用 11.0.0〜13.0.0未満
GHSA-5x8w-8jj5-q52h CVE-2026-112398 v4.0 9.2 FlashPix(FPX)のJPEGタイル復号 12.3.0以下
GHSA-8g5g-8vmr-9782 CVE-2026-112403 v4.0 9.2 JPEG復号の行幅の検証漏れ 12.3.0以下
GHSA-332p-7hrc-92wf CVE-2026-112393 v4.0 9.2 TIFFをファイルオブジェクトへ保存 2.0.0〜13.0.0未満
GHSA-w889-685w-c8fh CVE-2026-112900 v4.0 9.2 EPS処理でのGhostscript引数注入 2.6.0〜13.0.0未満

FPXの勧告は、拡張子ではなくファイル先頭のOLE2の識別子で形式を判定するため、「.jpg」で受け付けたファイルでも到達すると書いています。条件は、FPXの読み込みに使う任意パッケージolefileが入っていることです。EPSの勧告は、ハイフンで始まるファイル名がGhostscriptのオプションとして解釈される問題で、サーバーにGhostscriptが入っている環境が対象です。CVSS v4.0の値の読み方はnginxのCVSS v4.0 9.2の読み方で同じ形式を扱っています。

リリースノートとGitHubで重大度がずれる点と、KEV未掲載の現状

13.0.0のリリースノートのSecurity欄には42件のGHSA番号が並び、CVE番号は「割り当てられ次第追記する」と注記されています。ノート側の区分ではEPSの件がMedium、TIFF保存の件がHighで、GitHub Advisory Databaseの判定とは一致しません。どちらを基準にしても修正版は13.0.0なので、対応の結論は変わりません。

悪用の状況は落ち着いています。2026年10月24日に取得したCISAのKEVカタログにPillowは1件も無く、GitHub Advisory Databaseに出ているCVE-2026-96639のEPSS(30日以内に悪用される確率の推定)は0.565%でした。ただし勧告の多くは再現手順まで公開されています。13.0.0の公開は10月16日、勧告の公表は10月20〜23日で、修正の差分も手口もすでに誰でも読める状態です。

影響の確認:版・Python・同梱OpenJPEGを1コマンドで調べる手順

判定に要るのは、Pillowの版、Pythonの版、同梱ライブラリの版の3つです。

影響範囲は勧告ごとに違っても、修正版は全件で13.0.0のみ

勧告ごとの影響範囲は、2.0.0以上(TIFF保存)、5.1.0以上(PDF関連)、11.0.0以上(CVE-2026-96639)のようにばらばらです。古い版なら安全という勧告はほぼ無く、どれも修正版は13.0.0に揃っています。判定は「13.0.0以上かどうか」の一点で足ります。

注意したいのは、12.3.0が7月1日に出た修正版だったことです。7月20日に公表された勧告群(CVE-2026-59205など)は12.3.0で直っているため、7月に12.3.0へ上げてそのままの環境は多いはずです。その12.3.0が、今回はほぼ全件の影響範囲に入っています。

pip-auditとPIL.features:版と同梱OpenJPEG 2.5.4の確認

稼働中の環境で、次の2つを実行します。1つ目は版の確認、2つ目はpip-auditによるPyPIの脆弱性データベースとの照合です。

# 版と同梱ライブラリの確認(本番と同じ Python で実行する)
python -c "import sys, PIL; from PIL import features; print(sys.version.split()[0], PIL.__version__, features.version_codec('jpg_2000'))"

# 例: 3.14.7 12.3.0 2.5.4  → Pillow が 13.0.0 未満なので要更新

# 入っている全パッケージを既知の脆弱性と照合する
python -m pip install pip-audit
python -m pip_audit

1つ目の3番目の値は、PIL.featuresのversion_codecが返すJPEG 2000用ライブラリOpenJPEGの版です。Pillow 12.3.0とPython 3.14.7の環境で、2026年10月24日に実行して「2.5.4」が返ることを確かめました。この値の意味は次で説明します。

OSのパッケージ更新では直らないwheel同梱ライブラリの落とし穴

GHSA-78g4-xqwv-q3g8は、pipで入れるPillowのwheelに同梱されたOpenJPEGの不具合です。11.1.0〜11.3.0のwheelは2.5.3、12.0.0〜12.3.0は2.5.4を同梱しており、どちらにもOSV-2025-219のヒープ領域外書き込みが残っていました。勧告によれば2.5.2以前は影響を受けず、依存を新しく保ったことで穴を抱えた珍しい例です。

wheelは自前の複製を持つため、OSのlibopenjp2をaptやdnfで更新しても、Pillowが読み込むライブラリは変わりません。コンテナイメージをTrivyでスキャンする運用やOSV-Scannerでの依存の点検をしている場合も、OSパッケージの結果だけで「直った」と判断せず、Pythonパッケージとしてのpillowの版を見てください。

更新手順:Python 3.10環境に修正版が出ない問題と13.0.0の互換性

多くの環境は「pip install -U pillow」で済みますが、2つの場合に作業が増えます。

Pillow 13はPython 3.11以上が必須で、12系の修正版は出ていない

PillowのPython対応表では、Pillow 13の対応はPython 3.11〜3.15です。12系は3.10〜3.14に対応していましたが、PyPIに12.3.1のような修正版は無く、2026年10月24日時点で12系の最終版は12.3.0のままです。

Python 3.10そのものも、Pythonの開発者ガイドのとおり2026年10月1日にサポートが終わりました。つまりPython 3.10の上で動くPillowには、今回の修正を入れる手段がありません。pipに「-U」を付けても、Python 3.10では12.3.0までしか入らず、エラーも出ないまま古い版が残ります。Python 3.10環境は、Pythonの更新を先に計画するのが唯一の道です。

13.0.0で消えたAPIとI;16変換など、更新前に確かめる変更点

13.0.0はメジャー版で、リリースノートに互換性のない変更が並んでいます。実務で引っかかりやすいのは次の4つです。

  • 32ビットのIモード画像をPNGに保存するとき、16ビットへ黙って切り詰める動作が無くなった。事前に「im.convert(“I;16”)」で変換する
  • Image.Image.get_child_images()がImageFile.ImageFile.get_child_images()へ移った
  • Image._showとExifTags.IFD.Makernoteが削除された(後者はMakerNoteを使う)
  • TIFFに同じタグが複数あると、最後ではなく最初の値を採るようになった

深度画像や医療画像など16ビット超の画素値を扱う処理は、1つ目で出力が変わりうるので、更新前にテストで確かめてください。基本的な読み込みと保存の書き方はPillowの使い方と13.0.0対応のコード例にまとめています。

requirementsとDockerfileで13.0.0を下限に固定する書き方

更新後に古い版へ戻らないよう、依存の定義に下限を書きます。

# requirements.txt
pillow>=13.0.0

# pyproject.toml(Poetry 2系 / uv など PEP 621 形式)
[project]
requires-python = ">=3.11"
dependencies = ["pillow>=13.0.0"]

# Dockerfile:ベースイメージの Python も 3.11 以上にする
FROM python:3.13-slim
RUN pip install --no-cache-dir "pillow>=13.0.0"

requires-pythonを3.11以上にしておくと、Python 3.10で依存解決したときに13.0.0が選べないことがエラーとして表に出ます。ロックファイルの扱いはPoetryの依存管理の仕組み、自動で更新PRを受け取る設定はdependabot.ymlの書き方を参考にしてください。

更新までのつなぎ:アップロード画像の形式を絞る防御コードの実装

Pythonの更新待ちなどで13.0.0をすぐ入れられない場合、受け付ける画像の形式を絞ると攻撃面を大きく減らせます。

Image.openのformats引数だけではMPOを止められない理由

Image.openには、試す形式を限定するformats引数があります。FPX・PSD・DCX・MIC・EPS・TIFFはここで外せます。

ところがMPOは止まりません。PillowはMPOをJPEGの一種として開き、JPEG用の処理の中で複数画像の目印を見つけるとMPOに切り替えます。12.3.0のJpegImagePlugin.pyでも、jpeg_factoryがMpoImageFileへ変換する実装を確かめました。formats=[“JPEG”]と書いても、CVE-2026-96639の入口になるMPOはそのまま通ります。開いた後にim.formatとフレーム数を確かめる処理が別に要ります。

形式とフレーム数で弾くPython関数と、olefile・Ghostscriptの扱い

アップロードされたバイト列を開く前に通す関数の例です。

import io
from PIL import Image

ALLOWED = ("JPEG", "PNG", "WEBP")

def open_upload(data: bytes) -> Image.Image:
    im = Image.open(io.BytesIO(data), formats=ALLOWED)
    if im.format not in ALLOWED:  # JPEG を許可しても MPO はここで "MPO" になる
        raise ValueError(f"受け付けない形式: {im.format}")
    if getattr(im, "n_frames", 1) > 1:
        raise ValueError("複数フレームの画像は受け付けない")
    im.load()
    return im

Pillow 12.3.0とPython 3.14.7で2026年10月24日に実行し、JPEGとPNGは通過、Pillow自身で作った2枚組のMPOは「受け付けない形式: MPO」で拒否、GIFとTIFFはUnidentifiedImageErrorで拒否されることを確かめました。ファイルの拡張子や、ブラウザが送るContent-Typeでの判定は改ざんできるので使いません。

あわせて、使っていなければolefileをアンインストールし(FPXとMICの読み込みが無効になる)、Ghostscriptもサーバーから外します。保存するファイル名はサーバー側でUUIDなどから作り、利用者が送った名前を使わないことも、EPSの引数注入を防ぐための対策です。形式ごとの読み込み条件を見ると、どの形式が外部ツールに依存するかが分かります。ただしJPEGの復号にあるCVE-2026-112403やOpenJPEGの件は、この関数では防げません。つなぎは数日から数週間の手当てと割り切ってください。

対応の優先順位:外部の画像を受け取る処理から先に更新する判断基準

Pillowを使うサービスが複数ある場合の順番を、条件ごとに言い切ります。

利用者のアップロードを自動でサムネイル化する処理の即日更新の判断基準

最優先は、ログインなしでも画像を送れるフォームと、送られた画像を自動で縮小・変換する処理です。会員登録時のアイコン、問い合わせフォームの添付、ECの商品画像の取り込みが当てはまります。CVE-2026-96639の報告者が示した攻撃の形がそのまま当てはまり、当日中に13.0.0へ上げるか、上の関数で形式を絞ります。

次が、取引先から受け取るファイルを処理するバッチです。送り手は限られますが、取引先のメールが乗っ取られれば細工ファイルは届きます。週内に上げます。逆に、自社で生成した画像だけを扱う処理は後回しでかまいません。ただしTIFF保存の件は書き出し側の不具合なので、受け取った画像をTIFFへ変換して保存する処理は、読み込みの形式に関係なく対象に含めます。

社内バッチだけで使う場合と、Django・PDF生成ライブラリ経由の間接依存

見落としやすいのは、自分ではPillowをimportしていないのに入っているケースです。DjangoのImageFieldはアップロード時の検証にPillowを使い、PDFや帳票の生成ライブラリも画像の埋め込みにPillowを呼びます。「pip show pillow」の結果にある「Required-by」の行で、どのパッケージが引き込んでいるかを確認してください。

依存の棚卸しを1回で終わらせず、勧告が出るたびに同じ確認を回せる体制を作るなら、まず脆弱性診断の進め方と外注時の判断基準から全体像をつかむのが近道です。Pillowは2026年だけでも4月の12.2.0、7月の12.3.0、10月の13.0.0と、ほぼ四半期ごとに修正がまとまって出ています。

Pillowの脆弱性と13.0.0への更新でよくある質問と回答

Pillow 13.0.0への更新で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

Pillow 12.3.0を使っていますが、影響を受けますか?

受けます。今回の勧告の多くは影響範囲を「12.3.0以下」または「13.0.0未満」としており、12.3.0はCritical 5件すべての範囲に入ります。12.3.0は7月に出た修正版ですが、それは7月公表分の修正で、10月公表分は直っていません。Python 3.11以上なら、そのまま13.0.0へ上げてください。

Python 3.10のまま使い続ける方法はありますか?

修正を入れる方法はありません。Pillow 13はPython 3.11以上にしか対応しておらず、12系への修正版も2026年10月24日時点で出ていません。Python 3.10自体も10月1日にサポートが終わっています。更新までの間は、本文の関数で受け付ける形式を絞り、olefileとGhostscriptを外したうえで、Pythonの更新を急いでください。

Ubuntuなどのpython3-pilパッケージを使っている場合は?

OSのパッケージとして入れたPillowは、ディストリビューションが修正を移植して配布します。Ubuntuなら同社のセキュリティ通知(USN)、Red Hat系ならエラータで対象のCVEが直ったかを確認します。一方、同じサーバーでpipやvenvから入れたPillowは別物で、OSの更新では直りません。両方が混在していないか、実行時のPIL.__file__の場所で確かめてください。

実際の攻撃や悪用は確認されていますか?

2026年10月24日時点で、CISAのKEVカタログにPillowの登録は無く、勧告にも悪用の記載はありません。ただしCVE-2026-96639とFPXの件は、報告者がコマンド実行までの再現手順を示しています。手口の詳細が公開されている以上、悪用の報告を待たずに更新を済ませるのが筋です。

画像をクラウドのサービスで処理していれば関係ありませんか?

関係するかは、そのサービスの中でPillowが動いているかで決まります。AWS LambdaやCloud Runに自分でPillowを含めてデプロイした関数は、自分で更新する必要があります。Lambdaのレイヤーや、社内で共有しているコンテナのベースイメージに古いPillowが入っていないかも見てください。マネージドの画像変換サービスを使っている場合は、提供元の告知を確認します。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.07.21 テックブログ Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順
  2. 2026.10.22 テックブログ Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断
  3. 2026.10.21 テックブログ NEC委託先の不正アクセスとは|顧客システム暗号化・情報漏えいの経緯と委託元が点検する正規アカウント
  4. 2026.10.21 テックブログ ふるさとチョイス不正アクセスで445万件流出:対象確認・パスワード変更と再開時期
  5. 2026.05.15 テックブログ scrcpyの最新版は5.0|ハードウェアデコード対応とインストール・使い方【2026年10月】

RELATED POSTS 関連記事

目次