はじめに：画像処理ライブラリの危険性

フロントエンド開発において、ユーザーからの画像アップロードや表示、最適化は一般的なタスクです。その際、Exif情報などのメタデータを読み取るために <a href="https://www.npmjs.com/package/exifreader" target="_blank"><code>exifreader</code></a> のようなライブラリを利用することも少なくないでしょう。しかし、外部からの入力を処理するライブラリには常に脆弱性のリスクが潜んでいます。今回は、<code>exifreader</code> バージョン <code>4.41.0</code> に発見された深刻度の高いサービス拒否 (DoS) 脆弱性 (GHSA-pj96-35fp-cfcc / CVE-2026-85715) について、その詳細とフロントエンド開発者への影響、そして対策を解説します。

脆弱性の概要：悪意あるHEIC/AVIFファイルによるメモリ枯渇

この脆弱性は、ExifReaderがHEIC (High Efficiency Image File Format) やAVIF (AV1 Image File Format) といったISO-BMFF (ISO Base Media File Format) コンテナ形式の画像をパースする際に発生します。具体的には、これらのファイルに含まれる <code>iloc</code> (Item Location) ボックスのヘッダーが特定の細工をされている場合、ExifReaderが無限に近いJavaScriptオブジェクトをメモリ上に確保し続け、最終的にNode.jsプロセスをメモリ不足でクラッシュさせます。

攻撃者はわずか数百バイトのファイルでアプリケーションを停止させることが可能であり、これは未認証のユーザーによって引き起こされる可能性のあるサービス拒否攻撃となります。

技術的詳細：なぜメモリが枯渇するのか？

脆弱性の根本原因は、<code>src/image-header-iso-bmff-iloc.js</code> ファイルの <code>getItems()</code> 関数内のロジックにあります。この関数は、画像ファイル内のアイテム（<code>item</code>）とそのエクステント（<code>extent</code>）を処理する二重ループを含んでいます。

<code>iloc</code> ボックスのヘッダーには、<code>offsetSize</code>, <code>lengthSize</code>, <code>baseOffsetSize</code>, <code>indexSize</code> という4つのサイズフィールドがあります。これらはそれぞれエクステントのオフセット、長さ、ベースオフセット、インデックスのバイト数を制御します。ISO-BMFFの仕様では、これらのフィールドがすべて <code>0</code> であることは「フィールドが存在しない」ことを意味し、有効な値とされています。

しかし、脆弱性のあるExifReaderのバージョンでは、これら4つのサイズフィールドがすべて <code>0</code> に設定されている場合、内側のループ内でバッファオフセットが一切進まなくなります。それにもかかわらず、ループの各イテレーションでは、<code>item.extents</code> 配列に新しい <code>extent</code> オブジェクトが無条件に追加され続けます。これにより、<code>itemCount × extentCount</code> (最大 65535 × 65535 = 約43億) という膨大な数のオブジェクトがメモリ上に生成され、結果としてJavaScriptのヒープメモリを使い果たし、アプリケーションがクラッシュします。

例として、わずか652バイトのファイルで約400MBのヒープメモリを消費し、1.5KB程度のファイルでシステムメモリを枯渇させ、Node.jsプロセスが <code>JavaScript heap out-of-memory error</code> で異常終了することが確認されています。

フロントエンド開発への影響範囲

この脆弱性はNode.js環境でのメモリ枯渇を引き起こすため、特に以下のようなフロントエンド関連のシナリオで影響を受ける可能性があります。

<ul><li><strong>サーバーサイドレンダリング (SSR) / 静的サイト生成 (SSG)</strong>: Next.jsやNuxt.jsなどのフレームワークで、ビルド時やサーバーサイドでのリクエスト処理時にユーザーがアップロードした画像をExifReaderで解析している場合。</li><li><strong>画像最適化サービス/ビルドツール</strong>: WebpackやRollupのローダー、あるいは画像最適化のCLIツールなどで、ExifReaderを利用してHEIC/AVIFファイルのメタデータを読み込んでいる場合。</li><li><strong>APIゲートウェイ/BFF (Backend for Frontend)</strong>: ユーザーからの画像アップロードを受け付け、Node.jsで動作するAPIがExifReaderを使って画像を前処理している場合。</li><li><strong>Lambda@Edge/Cloudflare Workersなどのエッジコンピューティング</strong>: CDNのエッジで画像処理を行っているサービスでExifReaderが使用されている場合。</li></ul>

ブラウザ側のJavaScript環境でExifReaderが直接HEIC/AVIFファイルを処理するケースは限定的かもしれませんが、もしWebAssembly (Wasm) などでNode.jsのメモリモデルに近い形で動作する場合、同様のリスクが生じる可能性も考慮すべきです。

影響を受けるバージョンと確認方法

<ul><li><strong>影響を受けるパッケージ:</strong> <code>exifreader</code></li><li><strong>影響を受けるバージョン:</strong> <code>4.41.0</code></li><li><strong>影響を受けるファイル形式:</strong> HEIC, AVIF (ISO-BMFFコンテナ形式)</li></ul>

プロジェクトでこのライブラリを使用しているかどうかは、<code>package.json</code> や <code>yarn.lock</code> (または <code>pnpm-lock.yaml</code>) ファイルを確認することでわかります。もし <code>exifreader@4.41.0</code> を直接、あるいは依存関係として使用している場合は、脆弱性の影響を受ける可能性があります。

対策：アップデートと防御策

現時点での最も確実な対策は、この脆弱性が修正されたバージョンに <code>exifreader</code> をアップデートすることです。公式のアナウンスやGitHubリポジトリで修正版がリリースされているかを確認し、速やかに対応してください。

もし直ちにアップデートが難しい場合、あるいは将来的な同様のリスクに備えるための防御策として、以下の修正案が示されています。

ExifReaderのソースコード (<code>src/image-header-iso-bmff-iloc.js</code>) 内の <code>getItems()</code> 関数に、以下のいずれか、または両方のロジックを追加することが推奨されています。

<h4>1. 各アイテムのエクステント数に上限を設定する</h4>

内側のループで生成されるエクステントオブジェクトの数に明示的な上限を設けることで、無限のメモリ確保を防ぎます。

<code><pre>const MAX_EXTENTS_PER_ITEM = 10000; // 例: 適切な上限値<br><br>for (let j = 0; j &lt; item.extentCount; j++) {<br> if (item.extents.length >= MAX_EXTENTS_PER_ITEM) {<br> break; // 上限に達したらループを終了<br> }<br> // ... 既存のエクステント処理コード ...<br>}</pre></code>

<h4>2. すべてのサイズフィールドがゼロの場合にループをスキップする</h4>

エクステントのオフセットや長さを示すサイズフィールドがすべてゼロの場合（つまり、読み取るべきデータがない場合）、内側のループをスキップします。

<code><pre>if (sizes.item.extent.extentOffset === 0 && sizes.item.extent.extentLength === 0) {<br> // フィールドが仕様上存在しないため、読み取る意味のあるデータはない<br> // ただし、extentCount &gt; 0 の場合は、オフセットの整合性を保つため<br> // 適切なオフセット調整が必要な場合がある<br> continue;<br>}</pre></code>

上記の修正は、ライブラリ開発者によって正式に適用されるべきですが、緊急時には独自のパッチ適用も検討されるかもしれません。ただし、推奨されるのは公式アップデートの適用です。

まとめ

今回のExifReaderのDoS脆弱性は、外部から提供されるファイルを処理するライブラリが持つ潜在的なリスクを改めて示しています。特に、ユーザーが自由にコンテンツをアップロードできるシステムでは、入力の検証と、使用するライブラリのセキュリティ対策が非常に重要になります。

フロントエンドエンジニアの皆さんも、ご自身のプロジェクトで使用しているライブラリについて、常に最新の脆弱性情報をキャッチアップし、適切にバージョン管理を行う習慣を身につけましょう。もしExifReaderを使用している場合は、早急に依存関係を確認し、必要な対策を講じてください。