imgproxyのICO処理にコード実行のおそれ｜4.0.16だけでは残る問題を確認

画像変換サービスimgproxyのICOローダーに関する3件の脆弱性が、2026年11月8日にCVEレコードとして公開されました。加工された画像の処理により、プロセス停止、メモリ枯渇、任意コード実行につながるおそれがあります。開発元の勧告は10月6日付であり、11月8日に初めて修正版が出たというニュースではありません。外部から取得した画像や利用者のアップロードをimgproxyへ渡す運用者は、実際に稼働する版と入力経路を確認してください。

3件をまとめて解消する最低ラインは4.0.17です。ただし、その後の4.0.21にもBMP・ICOローダーの複数の脆弱性修正があり、確認時点のリリース一覧では11月5日公開の4.0.22が最新です。古い修正番号だけを目標にせず、互換性を確認したうえで現在の修正版へ更新する判断が必要です。以下では開発元勧告とCVE原本を照合し、更新後に残す確認作業を整理します。

三つの問題は影響版と結果が異なる

主題となるCVE-2026-123614は、ICO内のサイズ値を使ってメモリを確保する際の整数オーバーフローです。4.0.0以上4.0.16未満が対象で、4.0.16で修正されています。開発元はヒープ破壊によるサービス拒否と、任意コード実行の可能性を示しています。CVE原本のCVSS 4.0は9.3、CVSS 3.1は9.8です。本記事で表示する単一スコアはこのCVEのCVSS 4.0の値を指し、残り2件を同じ深刻度とするものではありません。

CVE-2026-123615の開発元勧告では、ICO画像からBMPヘッダーを再構成する処理で、確保した領域の外を読み書きする問題を説明しています。3.3.0以上4.0.17未満が対象で、4.0.17が修正の境界です。開発元の実証ではワーカーの異常終了が示されています。4.0.16では最初の整数オーバーフローが修正済みでも、この問題は残ります。「4.0.16にしたのでICO関連はすべて修正済み」という判断を避けてください。

CVE-2026-123616の開発元勧告では、画像内のサイズ宣言を十分に検証せず、過大なメモリ確保を試みる問題を説明しています。3.3.0以上4.0.16未満が対象で、4.0.16で修正されています。小さい入力でも大きな割り当て要求を発生させられるため、アップロードサイズが小さいことだけでは安全と判断できません。メモリの少ない環境では停止、大きい環境でも一時的な資源消費につながると開発元は説明しています。

これらの勧告には検証用入力や停止結果が掲載されていますが、実証された挙動と、第三者による実環境での悪用確認は別です。今回読んだ一次資料から、攻撃キャンペーンや自社環境の侵害を断定することはできません。悪用の公表を待って更新するのではなく、外部入力がローダーへ届く条件と、サービスが持つ権限を基準に優先順位を付けます。

対象は公開URLだけでなく画像の供給元で判断する

攻撃が成立する入口は、信頼できない画像のバイト列が脆弱なICO処理へ届く経路です。一般公開の画像変換URL、会員が登録するプロフィール画像、商品画像の取り込み、外部URLのサムネイル化、ストレージへ直接アップロードした画像を後から処理するジョブなどを分けて調べます。imgproxyがプライベートネットワーク内にあっても、外側のアプリが利用者指定のファイルを中継していれば、入力は内部専用とは限りません。

拡張子や出力形式だけで除外しないことも重要です。開発元の説明では、入力のICO識別情報から専用ローダーへ処理が渡ります。最終出力をPNGやJPEGに固定していても、その前に入力の読み込みが必要です。フォーム上で許可した拡張子、ストレージのContent-Type、実際に変換器へ渡るデータが一致しているかを確認します。単に画面からICOの選択肢を消すことを、サーバー側の修正の代わりにしないでください。

URL署名を使う構成では、誰が署名を発行できるかまで追います。署名はURLの変更や任意の変換要求を抑える助けになりますが、アプリが利用者のアップロードに対して正規の署名を発行するなら、悪意ある画像にも処理が到達し得ます。署名鍵の有無だけで対象外とせず、署名を発行するアプリと画像の作成者を別々に整理すると、優先するサービスを見つけやすくなります。

更新は配備定義と実行中のプロセスを照合する

まず構成管理、コンテナの配備定義、起動ログなどからimgproxyの使用箇所を一覧にします。同じサイトでも公開用サービスとバックグラウンド処理、プレビュー環境、フェイルオーバー先で別のイメージを使う場合があります。イメージのタグだけで済ませず、実行中のイメージIDやダイジェストを、修正版を含むビルドと対応付けてください。自社ビルドや派生版は、上流の番号だけでは修正コードの有無を判定できません。

4.0.16と4.0.17は今回の各CVEの修正境界を示す番号です。現在の運用先を選ぶ際は、後続の変更も確認します。公式リリース一覧には、4.0.21でBMPとICOの複数の脆弱性を修正したこと、4.0.22で依存関係の更新とBMPローダーの不具合修正を行ったことが記載されています。今回の3件だけを理由に4.0.17へ固定するのではなく、利用する機能と最新リリースの変更を照らして更新先を決めます。

ローリング更新では、旧ワーカーがリクエストを受け続けていないかを確認します。新しいコンテナを作成しただけでなく、ロードバランサーの接続先、ジョブの実行先、予備ノードを含めて旧版が残っていないことを記録します。切り戻し用の配備定義にも脆弱なイメージを残したままにすると、障害対応で再び旧版を起動し得ます。互換性の問題が出たときの代替表示や一時停止を、旧版への無条件な切り戻しとは分けて準備します。

更新までの間に狭める入力と資源の範囲

以下は公式設定の機能を踏まえた本サイトの運用提案です。更新までの時間が必要なら、信頼できない新規画像を処理する経路を止めるか、管理者が確認した素材だけに限定できるかを検討します。既に変換済みの画像配信と、新しい入力のデコードを切り離せるなら、業務への影響を抑えながら危険な処理を閉じられます。ただし、設定だけで整数オーバーフローを修正したことにはなりません。

公式設定のIMGPROXY_ALLOWED_SOURCESは、取得可能な画像URLの接頭辞を制限します。既定の空欄ではすべての取得元URLを許可します。ホストを制限する場合は末尾のスラッシュを含める必要があります。ただし、許可したストレージに利用者が書き込めるなら、その取得元に絞るだけで不正画像を除外できるわけではありません。取得先の制限と、そこへ画像を置ける主体の確認を組み合わせます。

IMGPROXY_MAX_SRC_FILE_SIZEは入力ファイルのバイト数、IMGPROXY_MAX_SRC_RESOLUTIONは解像度の上限を扱います。これらは通常の資源管理に役立ちますが、ファイル内部のサイズ宣言を使う脆弱性に対して、値を設定しただけで防御できるとは断定できません。コンテナのメモリ上限も、障害の波及を抑えるための境界であり、ワーカーの停止やコード実行の可能性をなくす修正ではありません。

安全な確認と異常時の切り分け

更新後の正常系は、普段利用するJPEG、PNG、WebPなどの素材で確認します。ICOを業務で使うなら、管理下の正常な素材が期待どおり変換できるかも検証環境で確認します。キャッシュされた応答だけを見ると旧版と新版の差を見落とすため、新しい安全な素材を使い、実際に処理したワーカーの記録と対応付けます。本記事では脆弱性の実証試験を行っておらず、動作保証や修正の実測結果は示していません。

異常な再起動があった場合は、画像要求の時刻、入力元、応答コード、ワーカーの標準エラー、コンテナ終了理由を突き合わせます。メモリ不足による終了と、ヒープ破壊に伴う異常終了は調査の手掛かりが異なります。一方、HTTP 500や再起動があっただけで今回のCVEの悪用とは言えません。通常の大きな画像、処理負荷、別の不具合も考慮し、原因を決めつけずに記録を保全します。

公開された攻撃用ファイルを本番へ投入して修正を確かめる必要はありません。実行する場合でも、管理者が許可した隔離環境と使い捨ての入力・資格情報に限定し、サービス停止が本番へ波及しない条件を先に作ります。運用の完了条件は、最新版の起動確認、入力経路の棚卸し、通常素材の処理確認、旧ワーカーの除去です。過去に侵害の兆候が見つかった場合は、更新作業とは別に調査を継続してください。

委託先が画像配信を運用している場合は、サービス名だけで影響なしと回答してもらうのではなく、imgproxyの利用有無、稼働版、外部入力の到達条件、修正済みの配備日時を確認します。自社がコンテナを管理していない構成では、利用者側が設定を変更しても内部のローダーは更新されません。回答が得られるまで新規素材の取り込みをどう扱うか、担当者と期限を決めておくと、確認待ちのまま処理が継続する状態を避けられます。

監視では、単一ノードの再起動数だけでなく、同じ画像に対して複数のワーカーが連続して失敗していないかを確認します。ジョブの自動再試行が有効な環境では、不正な入力がキューへ残ると交換後のワーカーにも再配布され得ます。原因不明のファイルは無害と判断して再投入せず、参照可能な担当者を絞って保全し、処理対象から外す運用を検討します。これは脆弱性の修正とは別に、障害の繰り返しを抑えるための提案です。

確認した版、配備先、入力の制限、残る調査項目を運用記録へ残し、次回の更新時にも同じ範囲を再確認できる状態にしてください。