Skip to content

chore(deps): update dependency aws-cdk-lib to v2.260.0 [security] - #134

Open
renovate[bot] wants to merge 1 commit into
sagafrom
renovate/npm-aws-cdk-lib-vulnerability
Open

chore(deps): update dependency aws-cdk-lib to v2.260.0 [security]#134
renovate[bot] wants to merge 1 commit into
sagafrom
renovate/npm-aws-cdk-lib-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
aws-cdk-lib (source) 2.232.12.260.0 age confidence

aws-cdk-lib: OS Command Injection in NodejsFunction Bundling

CVE-2026-11417 / GHSA-999r-qq7v-r334

More information

Details

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 in the NodejsFunction local bundling pipeline in aws-cdk-lib before 2.245.0 (2.246.0 on Windows) might allow a threat actor who controls the value of one or more bundling properties (externalModules, define, loader, inject, or esbuildArgs) to execute arbitrary commands on the host running the CDK toolchain via injected shell metacharacters. This issue requires the threat actor to control the value of one or more of the affected bundling properties in the CDK application.

Impact

During local Lambda bundling, NodejsFunction assembled an esbuild command string from the bundling properties externalModules, define, loader, inject, and esbuildArgs and executed it via a shell (bash -c on Linux/macOS, cmd /c on Windows) through spawnSync. The property values were interpolated without escaping or validation, so values containing shell metacharacters could execute arbitrary commands with the privileges of the user running cdk synth, cdk deploy, or cdk diff. Exploitation requires a threat actor to control one or more of the affected property values in the CDK application — for example via an untrusted npm dependency that vends a wrapper construct, or via a pull request that introduces untrusted values.

Impacted versions:

< 2.245.0 (on Windows, < 2.246.0)

Patches

This issue has been addressed in aws-cdk-lib version 2.245.0 (PR #​37292), with a Windows-specific regression fix in 2.246.0 (PR #​37412). The fix replaces shell-based command execution with array-based spawnSync invocation that does not invoke a shell. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

Ensure the values supplied to NodejsFunction bundling properties (externalModules, define, loader, inject, esbuildArgs) originate only from trusted sources, and audit third-party constructs and pull requests that set them. 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 aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

AWS would like to thank the external researcher Hesham Ashraf who reported this issue through the AWS Vulnerability Disclosure Program (HackerOne) for collaborating on it through the coordinated vulnerability disclosure process.

Severity

  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


aws-cdk-lib: OS Command Injection in NodejsFunction Docker Bundling

CVE-2026-13760 / GHSA-vcrf-j523-4mrf

More information

Details

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 aws-security@amazon.com. 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.

Severity

  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


AWS CDK CodeBuild S3 Log Encryption Boolean Inversion

GHSA-464c-974j-9xm6

More information

Details

Summary

The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation. We identified an issue in which explicitly setting encrypted: true on the S3LoggingOptions property of an AWS CodeBuild project construct produces the opposite of the intended behavior, disabling encryption on CodeBuild build logs stored in S3.

Impact

The S3LoggingOptions.encrypted property in the aws-codebuild module uses positive polarity (true = encryption ON), but is mapped directly to the CloudFormation S3LogsConfig.EncryptionDisabled field, which uses negative polarity (true = encryption OFF). Because the value is not negated before being passed to CloudFormation, any explicit assignment produces inverted behavior:

  • Setting encrypted: true (intending encryption ON) causes CloudFormation to receive EncryptionDisabled: true, disabling encryption.

  • Setting encrypted: false (intending encryption OFF) causes CloudFormation to receive EncryptionDisabled: false, enabling encryption.

Users who omit the property entirely are not affected, as undefined passes through to CloudFormation, which defaults to encryption enabled.

Users affected by this issue could have CodeBuild S3 build logs stored using SSE-S3 (Amazon S3-managed keys, AES-256) rather than the AWS managed keys that CodeBuild applies by default. Since January 5, 2023, Amazon S3 automatically encrypts all new object uploads with SSE-S3, so logs written after that date remain encrypted at rest. However, logs written prior to that date to buckets that did not have default encryption configured at the time are potentially not encrypted at rest.

Impacted versions: >= 1.75.0 and <= 2.252.0

Patches

This issue has been addressed in aws-cdk-lib version 2.253.0. Upgrade to the latest version and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

Users who are unable to immediately upgrade to version 2.253.0 should omit the encrypted property from their S3LoggingOptions configuration entirely. When the property is omitted, the value is not passed to CloudFormation, and CodeBuild applies its default behavior of encrypting build logs using AWS managed keys.

References

If you have any questions or comments about this advisory, contact AWS Security via our issue reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] https://aws.amazon.com/security/vulnerability-reporting/

Acknowledgement

AWS thanks AISafe for collaborating on this issue through the coordinated disclosure process.

Severity

  • CVSS Score: 3.3 / 10 (Low)
  • Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

aws/aws-cdk (aws-cdk-lib)

v2.260.0

Compare Source

Features
Bug Fixes

Alpha modules (2.260.0-alpha.0)

v2.259.0

Compare Source

⚠ BREAKING CHANGES
  • lambda: Runtime.NODEJS_LATEST now resolves to nodejs24.x in every region. Customers who pin to a concrete runtime (Runtime.NODEJS_22_X, useLatestRuntimeVersion: false in aws-lambda-nodejs.NodejsFunction) are unaffected. Existing AWS::Lambda::Function resources synthesized with NODEJS_LATEST will see Runtime: nodejs22.xRuntime: nodejs24.x on next deploy. Lambda accepts runtime updates in place.

    Customer-code compatibility — IMPORTANT: Node.js 24 removes support for callback-style asynchronous handlers ((event, context, callback) => {...}) per the launch blog. Customers whose Lambda code still uses callback-based handlers will see runtime errors after the bump. Customers should migrate to async (event, context) => {...} or pin to Runtime.NODEJS_22_X explicitly.

Features
Bug Fixes
Reverts

Alpha modules (2.259.0-alpha.0)

v2.258.1

Compare Source

Reverts

Alpha modules (2.258.1-alpha.0)

v2.258.0

Compare Source

⚠ BREAKING CHANGES
  • ** L1 resources are automatically generated from public CloudFormation Resource Schemas. They are built to closely reflect the real state of CloudFormation. Sometimes these updates can contain changes that are incompatible with previous types, but more accurately reflect reality. In this release we have changed:
  • aws-pcaconnectorad: AWS::PCAConnectorAD::ServicePrincipalName: ConnectorArn property is now required.
  • aws-pcaconnectorad: AWS::PCAConnectorAD::ServicePrincipalName: DirectoryRegistrationArn property is now required.
  • aws-pcaconnectorad: AWS::PCAConnectorAD::TemplateGroupAccessControlEntry: GroupSecurityIdentifier property is now required.
  • aws-pcaconnectorad: AWS::PCAConnectorAD::TemplateGroupAccessControlEntry: TemplateArn property is now required.
Features
Bug Fixes

Alpha modules (2.258.0-alpha.0)

Features
  • integ-tests-alpha: add option to set the provider log level (#​38005) (c634a79)
Bug Fixes

v2.257.0

Compare Source

⚠ BREAKING CHANGES
  • ** L1 resources are automatically generated from public CloudFormation Resource Schemas. They are built to closely reflect the real state of CloudFormation. Sometimes these updates can contain changes that are incompatible with previous types, but more accurately reflect reality. In this release we have changed:

    • aws-neptunegraph: AWS::NeptuneGraph::GraphSnapshot: GraphIdentifier property is now required.
Features

Alpha modules (2.257.0-alpha.0)

v2.256.1

Compare Source

Bug Fixes

Alpha modules (2.256.1-alpha.0)

v2.256.0

Compare Source

Features
Bug Fixes

Alpha modules (2.256.0-alpha.0)

v2.255.0

Compare Source

Features
Bug Fixes

Alpha modules (2.255.0-alpha.0)

Features
  • bedrock-agentcore-alpha: Graduation of the library to stable. The Policy submodule is the only submodule that remains in alpha. All other constructs have graduated to stable in aws-cdk-lib/aws-bedrockagentcore and we recommend migrating to the stable versions (#​37876) (00cf601)

v2.254.0

Compare Source

⚠ BREAKING CHANGES
  • ** L1 resources are automatically generated from public CloudFormation Resource Schemas. They are built to closely reflect the real state of CloudFormation. Sometimes these updates can contain changes that are incompatible with previous types, but more accurately reflect reality. In this release we have changed:

aws-elasticache: AWS::ElastiCache::CacheCluster: Id attribute removed.
aws-sagemaker: AWS::SageMaker::Model: Id attribute removed.
aws-vpclattice: AWS::VpcLattice::AuthPolicy: State attribute enum values changed from ACTIVE|INACTIVE to Active|Inactive.

Features
Bug Fixes

Alpha modules (2.254.0-alpha.0)

Features
  • bedrock-agentcore-alpha: add tags support to Evaluator and OnlineEvaluationConfig (#​37804) (adbf88f)
  • bedrock-agentcore-alpha: add identity L2 constructs (#​37610) (67c3af2)
  • mediapackagev2-alpha: add OAC integration between CloudFront and MediaPackageV2 (#​37701) (654f59c)
Bug Fixes

v2.253.1

Compare Source

Bug Fixes

Alpha modules (2.253.1-alpha.0)

v2.253.0

Compare Source

Features
Bug Fixes

Alpha modules (2.253.0-alpha.0)

Features
Bug Fixes
  • bedrock-agentcore-alpha: self-managed memory strategy validation throws on unresolved tokens (#​37691) (7956537), closes #​37197

v2.252.0

Compare Source

Features
Bug Fixes

Alpha modules (2.252.0-alpha.0)

v2.251.0

Compare Source

⚠ BREAKING CHANGES
  • ** L1 resources are automatically generated from public CloudFormation Resource Schemas. They are built to closely reflect the real state of CloudFormation. Sometimes these updates can contain changes that are incompatible with previous types, but more accurately reflect reality. In this release we have changed:

aws-elasticloadbalancing: AWS::ElasticLoadBalancing::LoadBalancer: SourceSecurityGroup attribute removed.
aws-elasticloadbalancing: AWS::ElasticLoadBalancing::LoadBalancer: PolicyItem type removed.
aws-elasticloadbalancing: AWS::ElasticLoadBalancing::LoadBalancer: SourceSecurityGroup type removed.

Features
Bug Fixes

Alpha modules (2.251.0-alpha.0)

Features

v2.250.0

Compare Source

⚠ BREAKING CHANGES
  • ** L1 resources are automatically generated from public CloudFormation Resource Schemas. They are built to closely reflect the real state of CloudFormation. Sometimes these updates can contain changes that are incompatible with previous types, but more accurately reflect reality. In this release we have changed:

aws-emr: AWS::EMR::Cluster: MonitoringConfiguration property removed.
aws-emr: AWS::EMR::Cluster: CloudWatchLogConfiguration type removed.
aws-emr: AWS::EMR::Cluster: EMRConfiguration type removed.
aws-emr: AWS::EMR::Cluster: MonitoringConfiguration type removed.

Features
  • s3files: s3Files Lambda L1 integration (#​37547) (af41262)
  • update L1 CloudFormation resource definitions (#​37582) (c99ce64)
  • mediapackagev2: add region attribute on mediapackagev2 resources and extra naming validation (#​37526) (112ed67)
Bug Fixes
  • eks-v2: respect securityGroup(s) in KubectlProviderOptions (#​37247) (4c530fa), closes #​36653
  • lambda-nodejs: if entry path is not under project root, bundling in Docker fails in an unclear way (#​37572) (73662df)

Alpha modules (2.250.0-alpha.0)

v2.249.0

Compare Source

⚠ BREAKING CHANGES
  • L1 resources are automatically generated from
    public CloudFormation Resource Schemas. They are built to closely
    reflect the real stat

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot force-pushed the renovate/npm-aws-cdk-lib-vulnerability branch from fb9f86e to 1c00455 Compare July 12, 2026 10:04
@renovate

renovate Bot commented Jul 12, 2026

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: package-lock.json
npm warn Unknown env config "store". This will error in a future major version of npm. See `npm help npmrc` for supported config options.
npm error code EALLOWREMOTE
npm error Fetching packages of type "remote" have been disabled
npm error Refusing to fetch "https://registry.npmjs.org/aws-cdk-lib/-/aws-cdk-lib-2.260.0.tgz"
npm error A complete log of this run can be found in: /runner/cache/others/npm/_logs/2026-07-30T16_11_23_140Z-debug-0.log

@renovate
renovate Bot force-pushed the renovate/npm-aws-cdk-lib-vulnerability branch from 1c00455 to 2ec66f6 Compare July 24, 2026 02:06
@renovate renovate Bot changed the title chore(deps): update dependency aws-cdk-lib to v2.246.0 [security] chore(deps): update dependency aws-cdk-lib to v2.260.0 [security] Jul 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants