---
title: "Pillow 脆弱性：13.0.0で直った42件の影響確認とPython 3.10環境の更新手順"
url: "https://www.issoh.co.jp/tech/details/18837/"
published: 2026-10-24
updated: 2026-10-24
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# 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回のリクエストで攻撃が成立しうる構造になっています。どの処理が外部の画像を受け取っているか分からない場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)でアップロード経路ごと洗い出すと漏れが減ります。

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

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

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

最も評価が高いのは[GHSA-v9pv-5gc8-w2m6](https://github.com/python-pillow/Pillow/security/advisories/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のレコード](https://www.cve.org/CVERecord?id=CVE-2026-96639)どおり「AV:N/AC:L/PR:N/UI:N」で、認証も利用者の操作も要りません。数値の読み方は[CVSSv3の計算式とスコアの目安](https://www.issoh.co.jp/tech/details/5094/)で確認できます。影響範囲は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の勧告](https://github.com/python-pillow/Pillow/security/advisories/GHSA-5x8w-8jj5-q52h)は、拡張子ではなくファイル先頭のOLE2の識別子で形式を判定するため、「.jpg」で受け付けたファイルでも到達すると書いています。条件は、FPXの読み込みに使う任意パッケージolefileが入っていることです。[EPSの勧告](https://github.com/python-pillow/Pillow/security/advisories/GHSA-w889-685w-c8fh)は、ハイフンで始まるファイル名がGhostscriptのオプションとして解釈される問題で、サーバーにGhostscriptが入っている環境が対象です。CVSS v4.0の値の読み方は[nginxのCVSS v4.0 9.2の読み方](https://www.issoh.co.jp/tech/details/12647/)で同じ形式を扱っています。

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

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

悪用の状況は落ち着いています。2026年10月24日に取得した[CISAのKEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)に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](https://github.com/pypa/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](https://pillow.readthedocs.io/en/stable/reference/features.html)が返すJPEG 2000用ライブラリOpenJPEGの版です。Pillow 12.3.0とPython 3.14.7の環境で、2026年10月24日に実行して「2.5.4」が返ることを確かめました。この値の意味は次で説明します。

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

[GHSA-78g4-xqwv-q3g8](https://github.com/python-pillow/Pillow/security/advisories/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](https://osv.dev/vulnerability/OSV-2025-219)のヒープ領域外書き込みが残っていました。勧告によれば2.5.2以前は影響を受けず、依存を新しく保ったことで穴を抱えた珍しい例です。

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

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

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

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

[PillowのPython対応表](https://pillow.readthedocs.io/en/stable/installation/python-support.html)では、Pillow 13の対応はPython 3.11〜3.15です。12系は3.10〜3.14に対応していましたが、[PyPI](https://pypi.org/project/pillow/13.0.0/)に12.3.1のような修正版は無く、2026年10月24日時点で12系の最終版は12.3.0のままです。

Python 3.10そのものも、[Pythonの開発者ガイド](https://devguide.python.org/versions/)のとおり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対応のコード例](https://www.issoh.co.jp/tech/details/1343/)にまとめています。

### 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の依存管理の仕組み](https://www.issoh.co.jp/tech/details/12303/)、自動で更新PRを受け取る設定は[dependabot.ymlの書き方](https://www.issoh.co.jp/tech/details/6796/)を参考にしてください。

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

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

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

[Image.open](https://pillow.readthedocs.io/en/stable/reference/Image.html)には、試す形式を限定する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の引数注入を防ぐための対策です。[形式ごとの読み込み条件](https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html)を見ると、どの形式が外部ツールに依存するかが分かります。ただし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回で終わらせず、勧告が出るたびに同じ確認を回せる体制を作るなら、まず[脆弱性診断の進め方と外注時の判断基準](https://www.issoh.co.jp/column/details/13101/)から全体像をつかむのが近道です。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が入っていないかも見てください。マネージドの画像変換サービスを使っている場合は、提供元の告知を確認します。

## 関連記事

- [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：勧告の公表から修正までの流れの基礎です。
- [CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化](https://www.issoh.co.jp/tech/details/5092/)：GHSA番号とCVE番号の関係を整理しています。
- [OpenCVとは？Pythonでの使い方入門｜pip installから画像処理・顔検出まで【5.0対応】](https://www.issoh.co.jp/tech/details/1344/)：Pillowと並んで使われる画像処理ライブラリの入門です。

---

出典: [Pillow 脆弱性：13.0.0で直った42件の影響確認とPython 3.10環境の更新手順](<https://www.issoh.co.jp/tech/details/18837/>)（株式会社一創）
