How severe is GHSA-f5x3-32g6-xq36?

GHSA-f5x3-32g6-xq36 has a CVSS score of 6.5/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-f5x3-32g6-xq36?

GHSA-f5x3-32g6-xq36 affects the following packages: node-tar (npm), tar (npm). Ecosystems affected: npm.

How do I fix GHSA-f5x3-32g6-xq36?

Update node-tar to 6.2.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f5x3-32g6-xq36 is resolved across your whole dependency graph.

How do I detect GHSA-f5x3-32g6-xq36 in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for node-tar. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-f5x3-32g6-xq36 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-f5x3-32g6-xq36?

O3 pinpoints whether GHSA-f5x3-32g6-xq36 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-f5x3-32g6-xq36 actively exploited in the wild?

No public exploit code has been indexed for GHSA-f5x3-32g6-xq36 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-f5x3-32g6-xq36?

GHSA-f5x3-32g6-xq36 has an EPSS (Exploit Prediction Scoring System) score of 0.9%, placing it in the 56th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-f5x3-32g6-xq36?

GHSA-f5x3-32g6-xq36 is classified as Uncontrolled Resource Consumption (CWE-400), CWE-770 (CWE-770). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-f5x3-32g6-xq36 published, and has it been updated?

GHSA-f5x3-32g6-xq36 was published on March 22, 2024 and was last updated on February 4, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-f5x3-32g6-xq36

MEDIUM

Denial of service while parsing a tar file due to lack of folders count validation

Also known asCVE-2024-28863

Published

Mar 22, 2024

Updated

Feb 4, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

EPSS Exploitation Probability

via FIRST.org ↗

0.9%probability of exploitation in next 30 days

Lower Risk56th percentile+0.27%

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

2 pkgs affected

Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.

tarnpm

104.8Mdownloads / week

Description

Description:

During some analysis today on npm's node-tar package I came across the folder creation process, Basicly if you provide node-tar with a path like this ./a/b/c/foo.txt it would create every folder and sub-folder here a, b and c until it reaches the last folder to create foo.txt, In-this case I noticed that there's no validation at all on the amount of folders being created, that said we're actually able to CPU and memory consume the system running node-tar and even crash the nodejs client within few seconds of running it using a path with too many sub-folders inside

Steps To Reproduce:

You can reproduce this issue by downloading the tar file I provided in the resources and using node-tar to extract it, you should get the same behavior as the video

Proof Of Concept:

Here's a video show-casing the exploit:

Impact

Denial of service by crashing the nodejs client when attempting to parse a tar archive, make it run out of heap memory and consuming server CPU and memory resources

Report resources

payload.txt archeive.tar.gz

Note

This report was originally reported to GitHub bug bounty program, they asked me to report it to you a month ago

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`node-tar`	all versions	6.2.1
📦npm	`tar`	all versions	6.2.1

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for node-tar. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update node-tar to 6.2.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f5x3-32g6-xq36 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-f5x3-32g6-xq36 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-f5x3-32g6-xq36. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Description: During some analysis today on npm's `node-tar` package I came across the folder creation process, Basicly if you provide node-tar with a path like this `./a/b/c/foo.txt` it would create every folder and sub-folder here a, b and c until it reaches the last folder to create `foo.txt`, In-this case I noticed that there's no validation at all on the amount of folders being created, that said we're actually able to CPU and memory consume the system running node-tar and even crash the nodejs client within few seconds of running it using a path with too many sub-folders inside ## St

O3 Security · Impact-Aware SCA

Is GHSA-f5x3-32g6-xq36 in your dependencies?

O3 detects GHSA-f5x3-32g6-xq36 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works