ImageSharpの脆弱性CVE-2026-106113、細工したTIFFでプロセスが終了するおそれ。3.2.0で要るライセンスキーと、2系・.NET Frameworkの扱い

提供元のアドバイザリによると、HistogramEqualization()は、画素の明るさ（輝度）からヒストグラムの位置を計算し、その値を確かめずにメモリ上の位置として使っていました。32ビット浮動小数点のTIFFに「正の無限大」の値を入れると、計算した位置が範囲を外れ、安全でないメモリへのアクセスが起きます。[1]

報告者の再現では、2.0.0・3.1.12・4.0.0・4.1.1でAccessViolationExceptionが起き、プロセスが終了しました。画像を処理するサービスが止まるおそれがあります。深刻度は提供元の評価でCVSS 3.1の7.5（可用性への影響が高）で、NVDも同じ値を載せています。[1][3]

次の3つがそろう場合が対象です。報告の対象はHistogramEqualizationだけで、適応型のヒストグラム平坦化とAutoLevelは含まれていません。[1]

• SixLabors.ImageSharpが2.0.0以上3.2.0未満、または4.0.0以上4.1.2未満（TIFFの読み込みは2.0.0から）
• 攻撃者が用意した32ビット浮動小数点のTIFFを、Image<HalfVector4>として読み込む
• 読み込んだ画像にHistogramEqualization()をかける

Webの画像の変換に使われるImageSharp.Webの標準の処理（リサイズ、形式、画質、背景色、向きの補正）には、ヒストグラム平坦化は含まれていません（当社がソースで確認）。自分のコードでHistogramEqualizationとHalfVector4を使っているかを探すと、見分けがつきます。[5]

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

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

提供元のアドバイザリには、無限大の画素を持つTIFFを作ってプロセスを終了させるまでの再現用のコード（PoC）とDockerfileが載っています。アドバイザリには「悪用の事例は知られていない」と書かれていて、CISAのコーディネーターがCVEの記録に付けた評価（SSVC）も10月7日時点で悪用「なし」です。当社はPoCを検証していません。[1][3]

系列ごとの対象と修正版は次のとおりです。必要な.NETの版は、NuGetに登録された対応の環境です。[1][2][4]

3系の修正版3.2.0は、4系の4.1.2から約4週間後の10月9日に公開され、アドバイザリも同じ日に更新されました。NVDの説明文は11月1日時点でも「4.1.2未満が対象、4.1.2で修正」のままで、これを写した脆弱性データベースでは3.2.0も対象と表示されることがあります。提供元のアドバイザリとNVDの対象の定義（CPE）は、どちらも3.2.0を修正版としています。[1][3]

1. プロジェクトが参照しているImageSharpの版を、間接的な依存も含めて確かめます。

   ターミナル

   dotnet list package --include-transitive | grep -i imagesharp

2. NuGetの脆弱性の情報で、対象の版が入っていないかも確かめます。

   ターミナル

   dotnet list package --vulnerable --include-transitive

3. コードの中で、該当の処理を使っているかを探します。

   ターミナル

   grep -rn -E 'HistogramEqualization|HalfVector4' --include='*.cs' .

4. 使っている系列の修正版へ上げます（4系か3系の、どちらかの行を実行します）。

   ターミナル

   dotnet add package SixLabors.ImageSharp --version 4.1.3
   dotnet add package SixLabors.ImageSharp --version 3.2.0

5. ライセンスキーを環境変数から渡す場合は、プロジェクトファイルに次を足し、SIXLABORS_LICENSE_KEYに発行されたライセンスの全文を入れます（Six Laborsの文書の例）。

   csproj

   <PropertyGroup>
     <SixLaborsLicenseKey>$(SIXLABORS_LICENSE_KEY)</SixLaborsLicenseKey>
   </PropertyGroup>

6. Releaseでビルドできることを確かめ、もう一度版を確かめます。コンテナのイメージなども作り直します。

   ターミナル

   dotnet build -c Release
   dotnet list package --include-transitive | grep -i imagesharp

提供元のアドバイザリに回避策の節はありません。次は、公表された成立条件から当社が整理した緩和策で、提供元の推奨ではありません。

• 外部から受け取った浮動小数点のTIFFに、HistogramEqualization()をかけない
• 処理の前に、画素に無限大などの有限でない値が含まれていないかを確かめる
• TIFFを受け付ける必要がなければ、読み込む前に形式を確かめて拒否する

Six Laborsの文書は、ImageSharpを直接参照するプロジェクトには、3系では3.2.0から、4系では4.0.0から、ビルドの際に有効なライセンスキーが必要だと説明しています。間接的な依存として入る場合は対象外で、提供元は「既存のライセンス条件の適用で、条件の変更ではない」としています。[6]

3.2.0のパッケージにはビルドのときにライセンスを確かめる処理が入っていて、キーが見つからないと、Debugのビルドは続けられますが、Releaseのビルドは失敗します。キーは、sixlabors.licをプロジェクトのフォルダに置くか、SixLaborsLicenseKey・SixLaborsLicenseFileのプロパティで渡します。[6][7]

3系以降のライセンスはSix Labors Split Licenseで、オープンソースのソフトウェアでの利用、非営利の団体、年間の総収入が100万米ドル未満の企業などはApache License 2.0で使え、それ以外は商用ライセンスが必要です。2系はApache License 2.0でした。前者に当たる場合も、キーの申し込みが要ります。[4][7][8]

2系向けの修正版は、アドバイザリに記載がありません。2系の最新は2025年11月の2.1.13で、NuGetはこの版にもこの件を表示しています。2系は.NET Framework 4.7.2や.NET Standard 2.0に対応していますが、3.2.0は.NET 6、4系は.NET 8向けで、.NET Frameworkのアプリには入れられません。[1][4]

その場合は、.NET 6以降へ移って3.2.0か4系を入れるか、移るまでの間、前の節の緩和策で該当の処理を止めます。2系から上げるときは、ライセンスの条件とキーの用意も確かめます。

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