GHSA-vcrf-j523-4mrf is a high-severity (CVSS 7.3) OS Command Injection vulnerability in aws-cdk-lib. O3 Security confirms whether GHSA-vcrf-j523-4mrf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
aws-cdk-lib: OS Command Injection in NodejsFunction Docker Bundling
Real-World Exposure
aws-cdk-libReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Summary
AWS CDK (aws-cdk-lib) is an open-source framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation. OS command injection issue in the NodejsFunction Docker bundling pipeline in aws-cdk-lib before 2.260.0 that might allow an actor who controls dependency version strings in a project's package.json file to execute arbitrary commands on the host running the CDK toolchain via injected shell metacharacters in the OsCommand helper. This issue requires the actor to control the content of a package.json dependency version string that is processed during Docker-based bundling with nodeModules specified.
Impact
During Docker-based Lambda bundling, when the nodeModules option is specified, NodejsFunction assembled a shell command string, including file-operation commands generated by an internal OsCommand helper, from the version strings of the modules listed in nodeModules, and executed it via a shell (bash -c) inside the bundling container. These version strings were interpolated without shell escaping, so values containing shell metacharacters could execute arbitrary commands inside the bundling container - which has read/write bind mounts to the host filesystem - with the privileges of the user running cdk synth, cdk deploy, or cdk diff. Leveraging this issue requires an actor to control a dependency version string for one of the listed modules - for example via an untrusted npm package referenced through nodeModules.
Impacted versions:
< 2.260.0
Patches
This issue has been addressed in aws-cdk-lib version 2.260.0 (PR #38133). We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Ensure that the modules listed in the nodeModules bundling option - and the version strings declared for them in your project's package.json, as well as the versions of the corresponding installed packages - come only from trusted sources, and audit third-party constructs and dependencies that introduce them. Using local bundling instead of Docker-based bundling avoids the affected code path. Upgrading to a fixed version is the recommended remediation.
References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to [email protected]. Please do not create a public GitHub issue.
Acknowledgement
We would like to thank the external researcher Mostafa Ashraf who reported this issue through the AWS Vulnerability Disclosure Program (HackerOne @kaporia) for collaborating on it through the coordinated vulnerability disclosure process.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | aws-cdk-lib | all versions | 2.260.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for aws-cdk-lib. 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 aws-cdk-lib to 2.260.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vcrf-j523-4mrf 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-vcrf-j523-4mrf 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-vcrf-j523-4mrf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vcrf-j523-4mrf in your dependencies?
O3 detects GHSA-vcrf-j523-4mrf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.