CVE-2026-11417

What it actually does

This vulnerability is an OS command injection flaw in the aws-cdk-lib NodejsFunction local bundling pipeline before version 2.245.0, or before 2.246.0 on Windows. If an attacker can influence specific bundling properties such as externalModules, define, loader, inject, or esbuildArgs in a CDK application, shell metacharacters may be interpreted by the host shell during local bundling. Successful exploitation allows arbitrary command execution on the machine running the CDK toolchain, with the privileges of the user or automation account executing CDK commands. The impact is local to the build/deployment host but can be severe because CDK tooling often runs with access to source code, credentials, CI/CD secrets, cloud deployment permissions, and generated infrastructure artifacts.

Why it matters to the business

A compromised CDK build or deployment workstation can allow attackers to steal cloud credentials, alter infrastructure deployments, tamper with application artifacts, or pivot into CI/CD systems. Organizations using AWS CDK for infrastructure deployment should treat this as a supply-chain and build-pipeline risk, especially where CDK inputs are generated from pull requests, templates, configuration files, plugins, or other semi-trusted sources. The vulnerability is not listed in CISA KEV, has low current EPSS probability, and requires attacker control over affected bundling properties, so broad opportunistic exploitation is less likely; however, targeted exploitation against developer workstations or CI/CD runners can have high operational impact.

How an attack unfolds

An attacker first obtains a way to influence a CDK application’s NodejsFunction bundling configuration, commonly through a malicious code contribution, compromised dependency, manipulated configuration file, poisoned template, or access to a repository branch used by automated builds. The attacker places shell metacharacters or command fragments into one of the affected bundling properties: externalModules, define, loader, inject, or esbuildArgs. When a developer or CI/CD job runs CDK synthesis, bundling, deployment, or another operation that invokes the local NodejsFunction bundling pipeline, aws-cdk-lib versions before the fixed release may construct a command in a way that allows injected shell syntax to execute. The injected command then runs on the host executing the CDK toolchain, potentially reading environment variables, stealing cloud credentials, modifying deployment output, installing persistence, or contacting attacker-controlled infrastructure. Exploitation requires local execution of the CDK workflow and attacker influence over the affected CDK configuration, so the most realistic scenarios are malicious pull requests, compromised internal repositories, or untrusted configuration inputs consumed by deployment automation.

How to fix it

Upgrade aws-cdk-lib to version 2.245.0 or later on Linux and macOS, and to version 2.246.0 or later on Windows. Ensure package-lock.json, yarn.lock, pnpm-lock.yaml, or equivalent lockfiles are updated so builds cannot continue resolving vulnerable versions. Rebuild and redeploy CI/CD runner images, development containers, and shared build environments that include aws-cdk-lib. Review CDK applications for any dynamic or user-controlled use of NodejsFunction bundling properties, especially externalModules, define, loader, inject, and esbuildArgs. Avoid passing untrusted input into bundling configuration; use allowlists for permitted module names and argument values. Where immediate upgrade is not possible, restrict who can modify CDK source/configuration, disable automated execution of unreviewed pull requests, and run CDK tooling in isolated, least-privileged build environments without long-lived credentials.

How to confirm the fix worked

Confirm the installed aws-cdk-lib version is 2.245.0 or later, or 2.246.0 or later on Windows, using package manager output such as npm ls aws-cdk-lib, yarn why aws-cdk-lib, pnpm why aws-cdk-lib, or direct inspection of package-lock.json, yarn.lock, pnpm-lock.yaml, and node_modules/aws-cdk-lib/package.json. Validate that CI/CD build images and developer bootstrap scripts install the fixed version rather than relying on broad semver ranges that may resolve inconsistently. Search CDK code for NodejsFunction bundling configuration that sets externalModules, define, loader, inject, or esbuildArgs, and verify these values are static, reviewed, and not derived from untrusted input. Run a clean CDK synth or deploy in a patched environment and confirm local bundling succeeds without unsafe shell behavior. For exposure validation, identify repositories and pipelines using aws-cdk-lib versions earlier than the fixed releases and prioritize those that run CDK automatically from pull requests or externally influenced configuration.

Typical attack path

1. Identify a project that uses aws-cdk-lib NodejsFunction local bundling with a vulnerable aws-cdk-lib version.
2. Gain influence over CDK application code or configuration, such as through a pull request, compromised dependency, template injection, or write access to repository files.
3. Insert shell metacharacters or command fragments into externalModules, define, loader, inject, or esbuildArgs.
4. Wait for a developer workstation or CI/CD runner to execute CDK synth, build, deploy, or another command that triggers local bundling.
5. Achieve command execution on the host running the CDK toolchain under that user or automation account’s privileges.
6. Collect credentials, source code, build artifacts, environment variables, or cloud deployment tokens, or modify generated infrastructure artifacts.
7. Use stolen credentials or altered infrastructure definitions to pivot into cloud resources or downstream deployment environments.

How to detect it

To determine whether exploitation already occurred, focus on hosts and CI/CD runners that executed CDK commands while using vulnerable aws-cdk-lib versions. Review CI/CD job logs, build output, shell command traces, process execution telemetry, EDR events, terminal history, and package manager logs around CDK synth, build, deploy, or asset bundling operations. Look for unexpected child processes spawned by node, npm, npx, yarn, pnpm, cdk, esbuild, docker, or shell interpreters during NodejsFunction bundling. Pay particular attention to commands that read environment variables, cloud credential files, SSH keys, source repositories, or CI/CD secrets, or that initiate outbound network connections to unfamiliar domains or IP addresses. Review recent commits and pull requests that modified NodejsFunction bundling properties externalModules, define, loader, inject, or esbuildArgs, especially values containing shell metacharacters such as ;, &&, ||, |, `, $(), >, <, or newline characters. On developer workstations, examine shell history, npm/yarn/pnpm logs, temporary bundling directories, and cloud credential access logs for activity aligned with CDK execution times. In cloud audit logs, check for unusual API calls made shortly after CDK jobs ran, particularly from CI/CD roles or developer identities that normally only perform deployment actions.

• externalModules
• esbuildArgs
• loader
• define
• inject
• NodejsFunction
• aws-cdk-lib
• node_modules/aws-cdk-lib/package.json
• cdk synth
• cdk deploy
• cdk diff
• ; curl
• ; wget
• && curl
• && wget
• | sh
• | bash
• `curl
• $(curl
• $(wget
• >/tmp/
• /tmp/cdk
• /tmp/aws-cdk
• ~/.aws/credentials
• /root/.aws/credentials
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN

What your security team should do

• Inventory repositories, CI/CD images, and developer toolchains that use aws-cdk-lib and identify versions earlier than 2.245.0, or earlier than 2.246.0 on Windows.
• Prioritize upgrades for pipelines that execute CDK commands automatically, run from pull requests, or have access to production cloud credentials.
• Update aws-cdk-lib and lockfiles, then rebuild CI/CD containers, dependency caches, and developer environment images.
• Review recent changes to CDK NodejsFunction bundling properties externalModules, define, loader, inject, and esbuildArgs for shell metacharacters or suspicious command fragments.
• Restrict untrusted pull requests from running privileged CDK synth/deploy jobs and require code review for infrastructure-as-code changes.
• Run CDK tooling in isolated, ephemeral, least-privileged runners with short-lived cloud credentials and limited outbound network access where feasible.
• Hunt build logs, shell history, endpoint telemetry, and CI/CD audit logs for suspicious commands executed during CDK bundling windows.
• Rotate cloud credentials, repository tokens, and CI/CD secrets if suspicious CDK bundling activity or command execution artifacts are found.