Pillowの脆弱性、olefile入りの環境で細工したFlashPix画像を開くとコード実行のおそれ（CVE-2026-112398、修正は13.0.0）

Pillowは、FPXファイルに含まれるJPEGのタイルを展開するとき、書き込み先のバッファを1画素あたり2バイト分で確保します。ところが、FPXが指すJPEGの色の形式をPillowが判別できないと、libjpegは1画素あたり4バイト（4成分）で書き出します。この結果、確保した2バイト分のバッファに4バイト分が書き込まれ、ヒープの範囲外への書き込みが起きます。書き込む長さ（画像の幅）と中身（画素のデータ）は、ファイルを作る側が決められます。[1]

深刻度は、CVEの採番機関であるGitHubの評価でCVSS 4.0の9.2（緊急）です。NVDも同じ値を二次評価として載せています。弱点の分類はCWE-122（ヒープベースのバッファオーバーフロー）とCWE-787（範囲外への書き込み）です。[1][3]

次の条件がすべてそろう環境が対象です。

• Pillowが12.3.0以前である（修正版は13.0.0）。[1]
• 任意依存のolefileが入っている。PillowはFPXを読むのにolefileを使い、olefileが無い環境ではFPXの読み込み機能自体が登録されません。[1][7]
• 外部から受け取ったファイルをImage.open()で開く（アップロード画像のサムネイル作成、アバターや文書の変換など）。形式はファイルの先頭の印（OLE2）で判定され、拡張子は見ません。[1]

対象の場合、受け取ったファイルを自動で開く処理で、利用者の操作なしに、画像処理を行うプロセスの権限でメモリを壊されます。条件がそろえば任意のコマンドの実行に至りますが、より起こりやすいのはクラッシュやサービス停止です。[1]

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

今後30日以内に悪用される確率の推定値（EPSS）は0.7%です（2026-11-01時点）。見込みは高くない部類ですが、推定値で、悪用されないことを保証するものではありません。

アドバイザリには、細工したFPXファイルを作るプログラム（PoC）と再現の手順が公開されています。ただし、報告者がコマンドの実行まで示したのは、ASLR（メモリ配置の乱数化）を無効にし、インタープリターが固定アドレスで動く検証用のDocker環境です。実環境で任意のコード実行まで持ち込むには、これらの前提をそろえる必要があり、CVSS 4.0で攻撃の難しさが「高」とされているのはこのためです。[1]

修正版は13.0.0です。Pillowは12.3.0以前が影響を受け、12系に修正版はありません。13.0.0（13系）へのメジャーバージョンの更新が必要です。配布元（PyPI）で公開済みの版で、確認日は2026年11月1日です。更新の前に、提供元のリリースノートで変更点を確かめてください。[6][7]

13.0.0はPython 3.10に対応しません。Python 3.10は2026年10月に提供が終わったためで、3.10で動かしている場合は、先にPython 3.11以上へ上げる必要があります。[6][7]

13.0.0は、今回のFPXの問題と同時に、JPEG・TIFF・PDFなどの読み書きで見つかった約40件（緊急2件・高13件を含む）をまとめて直した版です。すぐに上げられない事情があるときは、次の節のolefileを外す対処も検討します。[7]

1. 使っている版と、どのパッケージが連れてきているか（Required-byの行）を確認します。依存はrequirements.txt・poetry.lock・uv.lockにも記録されています。

   ターミナル

   python -m pip show pillow

2. 任意依存のolefileが入っているかを確認します。「見つからない（Package(s) not found）」なら、FPXの経路には届きません。

   ターミナル

   python -m pip show olefile

3. olefileが入っている場合、Pillowが実際にFPXを開ける状態かを確認します。Trueなら、受け取ったファイルをImage.open()に渡す箇所が対象になりえます。

   ターミナル

   python -c "from PIL import Image; Image.init(); print('FPX' in Image.OPEN)"

4. 13.0.0はPython 3.11以上が必要です。実行中のPythonの版を確認します。

   ターミナル

   python -V

5. 13.0.0以上へ更新します。間接依存で入っている場合は制約ファイルで下限を指定し、uvやPoetryでは各ツールの行でlockを更新します。

   ターミナル

   python -m pip install --upgrade "pillow>=13.0.0"
   # 間接依存のとき
   echo "pillow>=13.0.0" >> constraints.txt && python -m pip install -r requirements.txt -c constraints.txt
   uv lock --upgrade-package pillow
   poetry update pillow

6. 読み込まれる版を確かめます。本番の成果物（コンテナイメージなど）でも更新後の版か確認し、受け取ったファイルをそのまま開いている箇所も探します。

   ターミナル

   python -c "import PIL; print(PIL.__version__)"
   grep -rn "Image.open" --include="*.py" .

GitHub Advisoryに回避策の節はありません。次は、公表された成立条件から導ける緩和策です。[1]

• olefileを外せるか確認する。olefileが無ければFPXの読み込み機能は登録されず、この経路には届きません。FPXやMIC形式を扱っていなければ、依存から外すことを検討します。[1][7]
• Image.open()のformats引数で、受け付ける形式を実際に使うものだけに絞る（一般的な緩和策）。[1]

Pillowは、ファイルの拡張子ではなく先頭の数バイト（OLE2の印）でFPXと判定します。そのため、.jpgや.pngに見せかけたファイルでも、olefileが入っていればFPXとして展開されます。アップロードの受け口で拡張子やContent-Typeだけを確認していても、この経路は塞げません。[1]

すぐに13.0.0へ上げられない事情（Python 3.10を使っている、13系の互換性の確認が終わっていない、など）があるときは、olefileを外してFPXの読み込み自体を無効にする対処が、影響の範囲を狭めたうえで経路を断てます。FPXやMICを使っていないことを確かめてから外します。[1][7]

脆弱性の公表・更新一覧で、Pythonの関連情報を調べることもできます。