GHSA-64g7-mvw6-v9qj

What it actually does

shelljs versions before 0.8.5 contain an improper privilege management flaw in the way the library handles command execution-related operations. The vulnerable package can allow a lower-privileged local attacker to influence or abuse operations performed by software that invokes shelljs with higher operating-system privileges, potentially resulting in privileged file manipulation or command execution in the context of the calling process. The issue is most relevant where shelljs is embedded in build scripts, deployment tooling, installation hooks, administrative automation, or CI/CD jobs that run with elevated permissions.

Why it matters to the business

Successful exploitation could let an attacker move from limited local access to control over higher-privileged automation, build, or deployment processes. In practical terms, this can lead to tampered build artifacts, theft of deployment credentials or secrets, unauthorized changes to files, service disruption, or compromise of systems that trust scripts using shelljs. This advisory is not listed in CISA KEV and has no known public exploit maturity in the provided data, but the package is commonly used in JavaScript tooling, so exposure can exist indirectly through development and build dependencies.

How an attack unfolds

An attacker first needs access to a system or workflow where a vulnerable version of shelljs is used by a process running with greater privileges than the attacker has. Typical targets include developer workstations, build servers, package installation scripts, deployment automation, or administrative Node.js utilities. The attacker identifies where shelljs is invoked, then manipulates controllable inputs, execution context, environment, filesystem state, or temporary execution artifacts so that shelljs performs an operation under the privileges of the calling process. If successful, the attacker can cause privileged file writes, alter automation behavior, or execute commands as the higher-privileged user. After gaining that execution context, the attacker may collect secrets, modify source or build outputs, add persistence, or pivot to systems that trust the compromised automation.

How to fix it

Upgrade shelljs to version 0.8.5 or later. For npm-based projects, update direct dependencies in package.json and regenerate lockfiles so package-lock.json, npm-shrinkwrap.json, yarn.lock, or pnpm-lock.yaml no longer resolve shelljs below 0.8.5. Where shelljs is introduced transitively, upgrade the parent package that pulls it in, use package-manager override/resolution features if appropriate, and verify that the resolved dependency tree uses a fixed version. Avoid running shelljs-based scripts with unnecessary elevated privileges, especially as root or administrator. Treat build, install, and deployment scripts as privileged code paths; sanitize all externally influenced inputs passed to shell command helpers and restrict writable temporary or working directories used by privileged automation.

How to confirm the fix worked

Confirm remediation by inspecting dependency manifests and lockfiles and by running package-audit tooling. Useful checks include `npm ls shelljs`, `npm audit`, `yarn why shelljs`, `pnpm why shelljs`, and software composition analysis scans. The environment should report shelljs 0.8.5 or later everywhere the package is resolved. Also review CI/CD jobs, install scripts, deployment scripts, and administrative Node.js utilities to ensure they do not execute vulnerable dependency trees from cached node_modules directories or old container images. Validate that privileged automation does not run from attacker-writable directories and that no workflow unnecessarily executes shelljs-based scripts as root, administrator, or a high-privilege service account.

Typical attack path

1. Gain local access to a developer, build, CI/CD, or automation environment where Node.js tooling is executed.
2. Identify a script, dependency, or workflow that uses shelljs before version 0.8.5.
3. Determine whether the shelljs-using process runs with elevated permissions or access to sensitive files, credentials, or deployment capabilities.
4. Influence the process through controllable arguments, environment variables, filesystem state, working directories, or command-execution context.
5. Trigger the vulnerable shelljs operation so attacker-controlled behavior occurs under the privileges of the calling process.
6. Use the elevated context to read secrets, modify files, tamper with build or deployment artifacts, or execute follow-on commands.

How to detect it

To determine whether exploitation has already occurred, focus on systems where vulnerable shelljs versions were executed by privileged accounts. Review dependency inventories and historical build logs to identify when shelljs below 0.8.5 was present. Examine CI/CD logs, package installation logs, npm lifecycle script output, deployment logs, shell history, process execution telemetry, and endpoint detection data for unexpected commands launched by Node.js, npm, yarn, pnpm, or build-runner processes. Look for privileged Node.js processes spawning shells or system utilities in unusual directories, especially writable workspaces or temporary directories. Review file integrity events for unexpected changes to build scripts, deployment artifacts, generated packages, service files, startup scripts, SSH keys, cloud credentials, npm tokens, or other secrets around the time vulnerable jobs ran. Because no specific public exploit string or KEV exploitation pattern is provided, detection should be behavior-based rather than signature-only.

What your security team should do

• Inventory repositories, container images, CI/CD runners, developer tooling, and packaged applications for shelljs versions below 0.8.5.
• Prioritize upgrades where shelljs is used in build pipelines, deployment automation, package installation hooks, or scripts that run with elevated privileges.
• Update shelljs to 0.8.5 or later and refresh lockfiles; use dependency overrides or resolutions for transitive exposure when a parent package has not yet been updated.
• Purge or rebuild cached node_modules directories, build-agent workspaces, and container layers that may retain vulnerable versions.
• Reduce privilege of automation jobs that execute Node.js scripts; avoid running package scripts as root or administrator unless strictly required.
• Review shelljs usage for unsafe command construction, untrusted input handling, writable working directories, and risky environment-variable dependence.
• Add SCA policy gates to block shelljs versions below 0.8.5 in new builds and pull requests.
• Investigate high-value build or deployment systems for prior suspicious shelljs-related execution if vulnerable versions were used with elevated privileges.