<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 09:53:11 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-59873 — node-tar: Decompression/parse DoS via unlimited input</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-59873</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; isaacs node-tar&lt;/p&gt;
&lt;p&gt;node-tar is a tar archive manipulation library for Node.js. Prior to 7.5.19, node-tar does not enforce hard upper bounds on total decompressed data, entry counts, or decompression ratio in extraction and parsing paths such as src/extract.ts, allowing a small crafted gzip bomb to exhaust disk space and CPU. This issue is fixed in version 7.5.19.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; isaacs node-tar&lt;/p&gt;
&lt;p&gt;node-tar is a tar archive manipulation library for Node.js. Prior to 7.5.19, node-tar does not enforce hard upper bounds on total decompressed data, entry counts, or decompression ratio in extraction and parsing paths such as src/extract.ts, allowing a small crafted gzip bomb to exhaust disk space and CPU. This issue is fixed in version 7.5.19.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-59873</guid>
    </item>
    <item>
      <title>GHSA-23hp-3jrh-7fpw — node-tar: Decompression/parse DoS via unlimited input</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-23hp-3jrh-7fpw</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: tar&lt;/p&gt;
&lt;p&gt;### Summary
A **Decompression/parse DoS via unlimited input** vulnerability in `node-tar` allows an attacker to exhaust server resources (disk space and CPU). Because the library does not enforce hard upper bounds on total decompressed data or entry counts, a small, maliciously crafted &amp;#34;Gzip Bomb&amp;#34; can be used to fill a server&amp;#39;s storage and crash services.&lt;/p&gt;
&lt;p&gt;### Details
The `node-tar` library does not enforce a hard upper bound on archive size or the volume of decompressed data processed during extraction. While the `maxReadSize` option exists, it only controls internal read chunk sizes (default 16MB) and does not limit the total cumulative bytes written to disk.&lt;/p&gt;
&lt;p&gt;Specifically, in `src/extract.ts`, the `Unpack` stream processes entries as they arrive. There is no total-bytes limit, entry-count limit, or decompression ratio guard. An attacker can provide a TAR header claiming a massive file size (e.g., 10GB) and follow it with highly compressible data (like zeros). `node-tar` will continue to extract and write this data until the physical disk is exhausted, as it lacks a mechanism to abort based on global resource consumption.&lt;/p&gt;
&lt;p&gt;### PoC
The following Proof of Concept demonstrates how a tiny compressed input can be expanded into gigabytes of data on the host machine almost instantly.&lt;/p&gt;
&lt;p&gt;1. Create the exploit script:
```javascript
const fs = require(&amp;#39;fs&amp;#39;), z = require(&amp;#39;zlib&amp;#39;), t = require(&amp;#39;tar&amp;#39;);&lt;/p&gt;
&lt;p&gt;const d = &amp;#39;dos_test&amp;#39;;
if (fs.existsSync(d)) fs.rmSync(d, {recursive:true});
fs.mkdirSy…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: tar&lt;/p&gt;
&lt;p&gt;### Summary
A **Decompression/parse DoS via unlimited input** vulnerability in `node-tar` allows an attacker to exhaust server resources (disk space and CPU). Because the library does not enforce hard upper bounds on total decompressed data or entry counts, a small, maliciously crafted &amp;#34;Gzip Bomb&amp;#34; can be used to fill a server&amp;#39;s storage and crash services.&lt;/p&gt;
&lt;p&gt;### Details
The `node-tar` library does not enforce a hard upper bound on archive size or the volume of decompressed data processed during extraction. While the `maxReadSize` option exists, it only controls internal read chunk sizes (default 16MB) and does not limit the total cumulative bytes written to disk.&lt;/p&gt;
&lt;p&gt;Specifically, in `src/extract.ts`, the `Unpack` stream processes entries as they arrive. There is no total-bytes limit, entry-count limit, or decompression ratio guard. An attacker can provide a TAR header claiming a massive file size (e.g., 10GB) and follow it with highly compressible data (like zeros). `node-tar` will continue to extract and write this data until the physical disk is exhausted, as it lacks a mechanism to abort based on global resource consumption.&lt;/p&gt;
&lt;p&gt;### PoC
The following Proof of Concept demonstrates how a tiny compressed input can be expanded into gigabytes of data on the host machine almost instantly.&lt;/p&gt;
&lt;p&gt;1. Create the exploit script:
```javascript
const fs = require(&amp;#39;fs&amp;#39;), z = require(&amp;#39;zlib&amp;#39;), t = require(&amp;#39;tar&amp;#39;);&lt;/p&gt;
&lt;p&gt;const d = &amp;#39;dos_test&amp;#39;;
if (fs.existsSync(d)) fs.rmSync(d, {recursive:true});
fs.mkdirSy…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-23hp-3jrh-7fpw</guid>
    </item>
  </channel>
</rss>
