はじめに：node-tarとは？

こんにちは、フロントエンドエンジニアの皆さん。今回は、皆さんの開発環境やCI/CDパイプラインにも影響を及ぼしかねない、重要なセキュリティ脆弱性について解説します。

`node-tar`は、Node.js環境でTARアーカイブ（通常は`gzip`で圧縮された`.tar.gz`形式）を作成したり、解凍したりするための非常に広く使われているライブラリです。皆さんが直接利用していなくても、npmやYarnといったパッケージマネージャー、webpackやRollup、esbuild、Viteといったビルドツール、あるいはCI/CDツールなど、多くの開発ツールの内部依存関係として密かに利用されている可能性があります。

脆弱性の概要：無限の展開によるDoS攻撃

今回報告された脆弱性 (GHSA-23hp-3jrh-7fpw / CVE-2026-59873) は、「Critical」という最高レベルの深刻度に分類されています。この脆弱性は、「Decompression/parse DoS via unlimited input」（無限入力による解凍/解析時のサービス拒否）と名付けられており、悪意のあるユーザーが作成したTAR/Gzipアーカイブによって、サーバーのディスクスペースとCPUを際限なく消費させ、結果としてシステム全体を停止させる「Gzip Bomb」のような攻撃を可能にします。

攻撃者は、非常に小さな圧縮ペイロードを送信するだけで、ターゲットシステムのディスク容量を急速に枯渇させることができます。これは、サービス停止（Denial of Service, DoS）に直結し、アプリケーションが利用不可能になる重大な問題です。

具体的な挙動と技術的詳細

この脆弱性の根本原因は、`node-tar`ライブラリが、アーカイブの合計サイズ、解凍後のデータ量、またはアーカイブ内のファイルエントリー数に対して厳密な上限を設けていないことにあります。

`node-tar`には`maxReadSize`というオプションが存在しますが、これは内部的な読み込みチャンクサイズ（デフォルトは16MB）を制御するものであり、ディスクに書き込まれる全体のバイト量を制限するものではありません。つまり、巨大なファイルを小さなチャンクに分けて処理することはできますが、そのファイル自体のサイズを制限するわけではないのです。

攻撃者は、TARヘッダー内で「このファイルは10GBのサイズだ」と詐称し、実際には高い圧縮率を持つデータ（例：全てゼロのバイト列）を続けます。`node-tar`はこれを信じてデータを解凍し続け、その膨大な情報をディスクに書き込みます。ライブラリには、グローバルなリソース消費（ディスク使用量など）に基づいて解凍処理を途中で中止するメカニズムがないため、物理的なディスクが完全に枯渇するまで処理が継続されてしまいます。

具体的には、`src/extract.ts`内の`Unpack`ストリームがエントリーを処理する際に、合計バイト数、エントリー数、または圧縮率のガードがないことが問題です。

PoC（概念実証）の解説

提供されたPoC（概念実証）コードは、この脆弱性がどれほど危険であるかを明確に示しています。PoCは、Node.jsの`fs`、`zlib`（Gzip圧縮）、そして`tar`（`node-tar`）モジュールを使って以下の動作を行います。

1. 攻撃用のディレクトリを作成します。

2. 偽のTARヘッダーを作成します。このヘッダーは、`payload`という名前のファイルが「10GB」のサイズを持つと宣言します。

3. `zlib.createGzip()`でGzipストリームを作成し、それを`t.x({cwd: d})`（`node-tar`の解凍機能）にパイプします。

4. 作成した偽のヘッダーをGzipストリームに書き込みます。

5. その後、ひたすら「全てゼロ」の32MBチャンクをGzipストリームに書き込み続けます。ゼロのデータは非常に高い圧縮率を持つため、実際に送信されるデータ量はごくわずかです。

この結果、小さな入力データにもかかわらず、`node-tar`は偽のヘッダーに従って「10GB」のファイルをディスクに展開しようとし、実際に数GBのデータが短時間で書き込まれ、ディスク容量を急速に消費していく様子が観測されます。これにより、システムが非常に早く機能不全に陥ることが実証されます。

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

「フロントエンド開発で`node-tar`を直接使うことはあまりないのでは？」と感じた方もいるかもしれません。しかし、この脆弱性は間接的に大きな影響を与える可能性があります。以下のようなケースが考えられます。

1. **CI/CDパイプライン:** ビルドサーバーやデプロイサーバーが、`npm install`や`yarn install`の過程で依存パッケージを解凍する際に`node-tar`を使用している場合があります。悪意のあるパッケージが混入した場合、ビルドサーバーのディスクが枯渇し、CI/CDプロセスが停止する可能性があります。

2. **カスタムパッケージレジストリ/モノレポツール:** 企業内で独自のnpmレジストリや、カスタムのアーティファクト管理システムを運用している場合、`node-tar`がパッケージのアーカイブを処理するコア部分で使われている可能性があります。信頼できないユーザーがアクセスできる環境であれば、直接的な攻撃対象になり得ます。

3. **開発環境:** 開発マシンでパッケージをインストールする際に、万が一悪意のあるアーカイブが展開された場合、開発マシンのディスク容量が圧迫され、開発作業に支障をきたす可能性もゼロではありません。

4. **クラウドサービス/PaaS:** Node.jsアプリケーションをホスティングしているクラウド環境やPaaSで、ユーザーからのファイルアップロードを処理する際に`node-tar`を使っている場合、外部からのDoS攻撃の対象となります。

対策と推奨事項

この脆弱性に対する最も重要な対策は、`node-tar`ライブラリを**修正済みの最新バージョンにアップグレードすること**です。本記事執筆時点では修正パッチがリリースされていませんが、情報が公開され次第、迅速な対応が求められます。`package.json`の依存関係を確認し、`node-tar`が直接的または間接的に使われていないかを確認しましょう。

間接的な依存関係の場合、npm auditやyarn auditなどのツールを実行し、脆弱性が報告されていないか定期的にチェックすることが推奨されます。また、RenovateやDependabotのような依存関係の自動更新ツールを導入し、セキュリティアップデートを早期に適用できる体制を整えることも有効です。

さらに、以下の対策も検討してください。

- **信頼できないソースからのアーカイブ処理の制限:** 可能な限り、信頼できるソースからのアーカイブのみを処理するようにしましょう。ユーザーからのアップロードを受け付ける場合は、アップロードされたファイルのタイプやサイズ、ファイル数などを厳格に検証するサーバーサイドのロジックを実装してください。

- **リソース監視:** サーバーやCI/CD環境のディスク使用量やCPU使用率を常に監視し、異常を検知した際にアラートが上がる仕組みを導入しましょう。

- **サンドボックス環境での実行:** アーカイブの解凍処理など、リスクが伴う操作は可能な限り分離された、リソース制限のあるサンドボックス環境で行うことを検討してください。

まとめ

今回の`node-tar`の脆弱性は、サプライチェーン攻撃の一種である「Gzip Bomb」を可能にするものであり、Node.jsエコシステム全体に潜在的なリスクをもたらします。フロントエンドエンジニアの皆さんも、直接的なコード変更だけでなく、依存関係のセキュリティに対する意識を高め、常に最新の情報をキャッチアップし、適切な対策を講じることが重要です。

セキュリティは、開発のあらゆる段階で考慮すべき要素です。この機会に、ご自身のプロジェクトの依存関係やCI/CDパイプラインのセキュリティ体制を見直してみてはいかがでしょうか。