デイリー · 記事 01 · 4 分で読む
- セキュリティ
- オープンソース
imgproxyの画像読み込み脆弱性3件をCVE登録、稼働版を確認
11月8日(日本時間)のCVE登録・修正版は9月29日と10月1日に公開
要約・概要
アイコンのサイズ情報によって画像サーバーの作業用メモリが破損する恐れがあります。既存の修正、11月8日のCVE登録、本番への反映を分けて確認します。
主な事実
サイトで画像の大きさを変える imgproxy を使っている場合は、本番のリクエストを処理するバージョンと、外部から提供された画像がそのサーバーに届くかを確認してください。ICOアイコンの読み込み機能で公表済みだった不具合3件が、11月8日に公開脆弱性カタログのCVEへ登録されました。開発チームは日本時間の9月29日に v4.0.16、10月1日に v4.0.17 を公開し、10月7日(日本時間、UTCでは10月6日)に告知しました。今回の登録で、既存の修正を番号で追いやすくなりました。
3件のうち最も深刻な不具合は、サーバーの作業用メモリを壊し、告知にある条件では画像サーバー上でコードが実行される可能性もあります。告知が示すのは脆弱性と起こり得る影響です。個々のサービスで実際に悪用されたかは、別の証拠が必要です。CVE記録 · 開発チームの告知

1. サムネイルの依頼が画像サーバーに届くまで
通販サイトは、imgproxyで商品写真を取得し、小さな見本画像に変えられます。プログラムは画像の形式とファイル内の記載を読み、何を展開するか、作業用メモリをどれだけ確保するかを決めます。ICOはアイコンによく使われる形式です。外部の出品者が画像のURLを指定する架空の通販サイトでは、見本画像を作る際に、サーバーが出品者の選んだICOファイルを取得して開くことがあります。この経路が実際に使えるかは、画像の取得元の制限やリクエストの制御で変わります。
一つ目の不具合は、ファイルに極端に大きなサイズが記載されている場合に起きます。プログラムがヘッダーの分を足すと、数が桁の上限を超え、カウンターのように小さな値に戻ります。例えば2桁だけ表示する架空のカウンターでは、98に5を足すと合計は103ですが、表示は03になります。画像読み込み処理の上限はずっと大きいものの、同じ仕組みで小さな値に戻って作業領域が足りなくなり、コピーしたデータが別の作業用メモリにまで書き込まれる可能性があります。別の不具合では、領域を過剰に確保して、画像処理を担当するプログラムが停止することがあります。確保領域が小さくなる不具合 · メモリを使い切る不具合

猫と一緒に読み解く Q&A
- 猫の研究員
画像ファイル一つで、サーバー上のコードが実行されることがあるの?
ポケットノートサイズ情報が偽られると、サーバーの画像読み込み処理が確保領域の外に書き込むことがあります。開発チームは、この不具合で処理の停止やコード実行が起こり得るとしています。図はその経路を描いており、メモリを過剰に確保する不具合は別です。
2. 不具合ごとに修正済みの境界が異なる
各行は、開発チームが示す影響範囲と最初の修正版です。v4.0.16で稼働している場合、上の2件は修正済みの範囲に入ります。3件目の影響範囲にはまだ含まれます。
| 記録と起こり得る影響 | 影響を受ける版 | 最初の修正版 |
|---|---|---|
| CVE-2026-123614 · 確保領域が小さくなり、メモリの破損、停止、コード実行が起こり得る | v4.0.0–v4.0.15 | v4.0.16 |
| CVE-2026-123616 · 過剰な領域確保でメモリを使い切り、画像処理が停止する可能性 | v3.3.0–v4.0.15 | v4.0.16 |
| CVE-2026-123615 · 確保領域の外にアクセスし、告知では画像処理の停止を再現 | v3.3.0–v4.0.16 | v4.0.17 |
- 記録と起こり得る影響
CVE-2026-123614 · 確保領域が小さくなり、メモリの破損、停止、コード実行が起こり得る
- 影響を受ける版
- v4.0.0–v4.0.15
- 最初の修正版
- v4.0.16
- 記録と起こり得る影響
CVE-2026-123616 · 過剰な領域確保でメモリを使い切り、画像処理が停止する可能性
- 影響を受ける版
- v3.3.0–v4.0.15
- 最初の修正版
- v4.0.16
- 記録と起こり得る影響
CVE-2026-123615 · 確保領域の外にアクセスし、告知では画像処理の停止を再現
- 影響を受ける版
- v3.3.0–v4.0.16
- 最初の修正版
- v4.0.17
猫と一緒に読み解く Q&A
- 猫の研究員
上の2件は v4.0.16 で直ったんだね。3件とも大丈夫?
ポケットノート3件目はより新しい修正版が必要です。本番リクエストを処理する全てのプログラムがv4.0.17の修正を含むサポート対象の版かを確認します。リリース記録で開発チームの修正、稼働記録で自分のサービスのバージョンが分かります。
3. 公開、適用、過去の稼働を別々に確かめる
| 段階 | 状態と担当者 | 確認する記録 |
|---|---|---|
| 修正版の公開 | 確認済み · imgproxy開発チーム | v4.0.16のリリースとv4.0.17のリリース |
| 公開CVEへの登録 | 確認済み · VulnCheckが11月8日に登録 | 123614 · 123615 · 123616 |
| 修正版での本番処理 | サービスごとに確認 · サイトまたはホスティングの運用担当者 | 稼働バージョン、コンテナを使用する場合はイメージの識別子、反映時刻 |
| 以前の稼働状況 | サービスごとに調査 · セキュリティまたは運用担当者 | リクエストの取得元、処理の停止・再起動、影響を受ける版で入力を受け付けた期間 |
- 段階
修正版の公開
- 状態と担当者
- 確認済み · imgproxy開発チーム
- 確認する記録
- v4.0.16のリリースとv4.0.17のリリース
- 段階
公開CVEへの登録
- 状態と担当者
- 確認済み · VulnCheckが11月8日に登録
- 段階
修正版での本番処理
- 状態と担当者
- サービスごとに確認 · サイトまたはホスティングの運用担当者
- 確認する記録
- 稼働バージョン、コンテナを使用する場合はイメージの識別子、反映時刻
- 段階
以前の稼働状況
- 状態と担当者
- サービスごとに調査 · セキュリティまたは運用担当者
- 確認する記録
- リクエストの取得元、処理の停止・再起動、影響を受ける版で入力を受け付けた期間
猫と一緒に読み解く Q&A
- 猫の研究員
デプロイ画面が完了になったら、どの記録を頼めばいい?
ポケットノートどの版が実際にリクエストを処理しているか、最後の旧版がいつ入れ替わったか、それまで外部の画像URLが届く状態だったかを確認します。その期間のリクエストと処理プログラムの記録を照らし合わせましょう。停止は調査の手がかりで、原因の特定には証拠が必要です。
まとめ
画像が届く経路と稼働中のバージョンから確認
「出品者が指定した画像は、自社の画像処理サーバーに届きますか。更新の前後でどのバージョンが処理しましたか」と運用担当者に聞くと、告知を実際のサービスに結び付け、確認する期間を決められます。
出典
- 123614cve.org
- CVE-2026-123614github.com
- CVE-2026-123616github.com
- CVE-2026-123615github.com
- v4.0.16のリリースgithub.com
- v4.0.17のリリースgithub.com
- 123615cve.org
- 123616cve.org