Overview
The decompress package has a critical path traversal / arbitrary file write vulnerability (GHSA-x7mh-q3r-mg2q) with no patch available. The package appears unmaintained (last release in 2019, open CVE with no fix). The only remediation is to replace it with a maintained alternative.
This affects 6 examples in this repository as a transitive dependency of the Serverless Framework CLI.
Vulnerability
| Advisory |
Severity |
Description |
| GHSA-x7mh-q3r-mg2q |
Critical |
Archive extraction can create files and symlinks outside the target directory (Zip Slip) |
Dependency chain:
serverless (v3) → @serverless/utils → decompress
Affected examples:
examples/serverless-appsync-node-typescript
examples/serverless-cognito-local
examples/serverless-localstack-with-s3-and-dynamodb
examples/serverless-neo4j-ec2
examples/serverless-s3-local
examples/serverless-start-stop-ec2-instance
Open Dependabot alerts: 6 (all critical)
Investigation Lines
This vulnerability is in a transitive dependency of the Serverless Framework v3. There are two main resolution paths:
Path 1: Upgrade Serverless Framework to v4
Serverless Framework v4 (>= 4.0.0) has dropped or replaced decompress. This is also tracked in a related issue: #[Serverless v4 migration issue number].
Verify:
npm install serverless@^4 --save-dev
npm ls decompress # should return empty
npm audit | grep decompress # should return 0
Path 2: Use npm overrides to force a safe archive extraction library
If staying on Serverless v3 is required, investigate using npm overrides in package.json to replace decompress with a patched fork or a different package that satisfies the same interface:
// package.json
"overrides": {
"decompress": "npm:@your-fork/decompress@^4.2.1"
}
Note: this approach may break Serverless internals if the replacement isn't API-compatible.
Path 3: Research if the vulnerability is actually exploitable in this context
decompress is used by Serverless to extract Lambda layers and packages during deployment. The threat model is:
- Does the extraction happen with user-supplied archives (attacker-controlled)?
- Or does Serverless only decompress its own managed packages (lower risk)?
If the latter, the practical risk may be lower, and a documented dismissal with rationale is acceptable until Serverless v4 migration completes.
Validation
cd examples/<affected-example>
npm ls decompress # confirm it's in the tree
npm audit | grep decompress # should be 0 after fix
References
Overview
The
decompresspackage has a critical path traversal / arbitrary file write vulnerability (GHSA-x7mh-q3r-mg2q) with no patch available. The package appears unmaintained (last release in 2019, open CVE with no fix). The only remediation is to replace it with a maintained alternative.This affects 6 examples in this repository as a transitive dependency of the Serverless Framework CLI.
Vulnerability
Dependency chain:
Affected examples:
examples/serverless-appsync-node-typescriptexamples/serverless-cognito-localexamples/serverless-localstack-with-s3-and-dynamodbexamples/serverless-neo4j-ec2examples/serverless-s3-localexamples/serverless-start-stop-ec2-instanceOpen Dependabot alerts: 6 (all critical)
Investigation Lines
This vulnerability is in a transitive dependency of the Serverless Framework v3. There are two main resolution paths:
Path 1: Upgrade Serverless Framework to v4
Serverless Framework v4 (>= 4.0.0) has dropped or replaced
decompress. This is also tracked in a related issue: #[Serverless v4 migration issue number].Verify:
Path 2: Use
npm overridesto force a safe archive extraction libraryIf staying on Serverless v3 is required, investigate using npm
overridesinpackage.jsonto replacedecompresswith a patched fork or a different package that satisfies the same interface:Note: this approach may break Serverless internals if the replacement isn't API-compatible.
Path 3: Research if the vulnerability is actually exploitable in this context
decompressis used by Serverless to extract Lambda layers and packages during deployment. The threat model is:If the latter, the practical risk may be lower, and a documented dismissal with rationale is acceptable until Serverless v4 migration completes.
Validation
References