ImageMagickの脆弱性 見えない依存をどう棚卸すか

脆弱性・脅威情報

【更新 2026-07-10】本記事を見直し、修正しました。主な修正点：CVSSの版表記を「CVSS 3.0」から一次情報（NVD／GitHub Security Advisory）の記載どおり「CVSS 3.1」に訂正（基本値5.1・ベクトルは変更なし）。

画像処理の定番ライブラリ ImageMagick に、新たな脆弱性 CVE-2026-42326 が公表されました（JVNDB-2026-019599、公表2026年6月10日）。IPTC出力の処理で1バイトの境界外読み取りが起きるもので、CVSS基本値は5.1（警告）と深刻度そのものは高くありません。ただ、情シスにとって本当の論点は「この1件がどれだけ危ないか」ではなく、ImageMagickが自社のどこで動いているかを把握できているかです。多くのWebアプリやCMSに組み込まれた“見えない依存”をどう棚卸し・管理するか、実務目線で整理します。

この記事でわかること

  • CVE-2026-42326で実際に何が起きるのか（そして何が起きないのか）
  • 深刻度をどう読むべきか（CVSSベクトルの意味）
  • ImageMagickが“見えない依存”になりやすい理由と、情シスの棚卸しの勘所
  • 今すぐ・恒常的にやるべき対策（パッチとpolicy.xmlによる堅牢化）

何が起きたのか

結論から言えば、細工された画像を処理させたときに、メモリを1バイトだけ余分に読み取ってしまう不具合です。IPTC（写真のメタデータ規格）の出力ファイルを生成する処理（IPTCエンコーダ）にヒープバッファのオーバーリード（境界外読み取り）があり、悪意のある入力によって割り当て範囲を1バイト超えて読んでしまう可能性があります。

項目 内容
識別子 CVE-2026-42326 / JVNDB-2026-019599 / GHSA-7wff-wpr6-vmhm
脆弱性の種類 境界外読み取り（CWE-125）、整数アンダーフロー（CWE-191）
影響を受けるバージョン 6.9.13-47 より前／7.0.0-0 〜 7.1.2-22
修正バージョン 6.9.13-47 以降／7.1.2-22 以降
CVSS 3.1 基本値 5.1（警告）
公表日 2026年6月10日

どのくらい深刻なのか？

単体では深刻度は低めで、境界外読み取り1バイトにとどまります。CVSSベクトルは AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L です。読み解くと次のようになります。

  • AV:L（ローカル）：ネットワーク越しに単独で悪用されるものではなく、攻撃者が用意した入力ファイルを処理させることが前提です。
  • C:L / A:L、I:N：情報漏えいと可用性への影響は「低」、完全性（改ざん）への直接影響は「なし」。1バイトの読み過ぎなので、任意コード実行（RCE）のような派手な結果には直結しません。

つまり、この1件だけを見て慌てて緊急対応するほどの緊急度ではありません。とはいえ、攻撃者が用意した画像を処理する場面（ユーザーからの画像アップロード、外部から取得した画像の変換など）は情シスにとって身近であり、こうした境界外読み取りは他の不具合と組み合わさって情報漏えいの足がかりになり得ます。過小評価も過大評価もせず、「通常のパッチ運用でしっかり潰す」対象として扱うのが妥当です。

なぜ情シスにとって厄介なのか — “見えない依存”という問題

ImageMagickの本当の難しさは、脆弱性の深刻度ではなく「どこで動いているか把握しづらい」点にあります。ImageMagickはコマンド（convert／magick）として使われるだけでなく、次のような形で他ソフトの内側に組み込まれていることが多々あります。

  • CMSやWebアプリのサムネイル生成・画像リサイズ機能（プラグイン経由を含む）
  • PHPのimagick拡張など、各言語からライブラリとして呼び出される画像処理
  • アップロードされた画像のメタデータ処理やフォーマット変換のバックエンド

担当者が「自社ではImageMagickは使っていない」と思っていても、実際にはアプリの依存関係の奥で動いていた、というのはよくある話です。これが“見えない依存”です。脆弱性が公表されるたびに、まず「そもそも自社のどこにあるのか」を調べるところから始まる——この探索コストこそが現場の負担になります。

過去の教訓：ImageTragick

ImageMagickは歴史的に脆弱性の多いソフトとしても知られます。2016年のImageTragick（CVE-2016-3714）では、細工した画像ファイルを処理させるだけでサーバー上で任意コマンドが実行され得るという、今回とは比べ物にならない重大な問題が話題になりました。以来、境界外読み取りやメモリ破壊系のCVEが継続的に報告されています。「ImageMagickを使っている＝定期的にCVEが出る前提で運用する」という心構えが、結局いちばん現実的です。

情シスはどうすべきか

特別なことは必要ありません。地道な「棚卸し・パッチ・堅牢化」の3点を、ImageMagickにも当てはめるだけです。

1. どこで使っているかを棚卸しする

まずは資産の把握です。サーバー上のパッケージ（magick -version でのバージョン確認）に加え、Webアプリの依存関係リスト（SBOM／ソフトウェア部品表）を確認し、直接・間接にImageMagickを含むものを洗い出します。「使っていないつもり」を疑うのが出発点です。

2. パッチを適用する

今回のCVE-2026-42326は6.9.13-47 または 7.1.2-22 以降で修正済みです。多くの環境ではOSやディストリビューションのパッケージ更新で配布されるため、通常の脆弱性対応・パッチ適用のサイクルに乗せて更新してください。バージョン番号だけでなく、ディストリビューションがバックポート修正を出していないかも確認します。

3. policy.xml で不要な機能を止める（恒久対策）

ImageMagickには policy.xml という設定で、使う画像フォーマット（コーダ）や外部連携（デリゲート）を制限する仕組みがあります。公開Webサーバーなど信頼できない画像を扱う環境では、危険なコーダやデリゲートを既定で無効化し、扱う形式を安全なものだけに絞り込むのが定石です。ImageMagick公式のSecurity Policyでは、BMP／GIF／JPEG／PNG／TIFF／WEBPなど“安全な”形式だけを許可し、その他は既定で拒否する厳格なプロファイル例が示されています。攻撃対象領域そのものを減らせるため、個別CVEに追われにくくなります。設定変更は「課題を解く最小のルールだけ変える」のが原則です。

あわせて、アップロード画像は拡張子だけで信用せず内容を検証する、画像処理は権限を絞ったプロセスやコンテナで動かす、といった一般的な入力バリデーション・分離の考え方も有効です。個々の手順を自前で積み上げるより、まずは公的機関の指針で全体像を押さえるのが近道です。中小規模であれば IPA「中小企業の情報セキュリティ対策ガイドライン」 が、脆弱性管理・資産管理の基本を体系的に整理しています。

現場目線の所感

正直なところ、CVSS5.1・1バイトの読み過ぎという単体のニュースは、忙しい現場ではスルーされがちです。しかしImageMagickのようなライブラリの怖さは、「一件一件は小粒でも、恒常的に湧いてくる」ことにあります。その都度「うちで使っているんだっけ？」を調べ直していると、いつまでも探索コストを払い続けることになります。だからこそ、脆弱性が出てから慌てるのではなく、依存関係を可視化しておく（SBOMを持っておく）ことと、policy.xmlで攻撃面を先に狭めておくことが効いてきます。派手さはありませんが、こうした地味な準備が、次に大物のImageMagick CVEが来たときの対応時間を確実に縮めてくれます。ユーザーや開発部門への「画像処理コンポーネントも管理対象ですよ」という地道な啓発も、意外と侮れません。

まとめ

  • CVE-2026-42326は深刻度中（CVSS5.1）。IPTC出力時の1バイト境界外読み取りで、6.9.13-47／7.1.2-22で修正済み。単体では緊急度は高くなく、通常のパッチ運用で対応すればよい。
  • 本質的な課題は深刻度ではなく「ImageMagickがどこで動いているか把握できているか」。CMSやWebアプリの奥に潜む“見えない依存”を棚卸しすることが先。
  • 恒久対策は棚卸し（SBOM）＋パッチ＋policy.xmlによる攻撃面の縮小。個別CVEを追い続けるより、扱う形式を安全なものに絞る堅牢化が効く。

出典

タイトルとURLをコピーしました