yarn.lock resolves vulnerable fast-xml-parser 4.4.1 via stale @aws-sdk/client-lambda pin (not shipped to users)

[AtsutoNakayama]

Describe the bug

packages/@aws-cdk/custom-resource-handlers depends on @aws-sdk/client-lambda@3.632.0, which transitively pulls in @aws-sdk/client-sts / @aws-sdk/client-sso-oidc / @aws-sdk/core@3.629.0, which pins fast-xml-parser to the exact version 4.4.1. This version is vulnerable to GHSA-m7jm-9gc2-mpf2 (entity encoding bypass via regex injection in DOCTYPE entity names), fixed in 4.5.4.

@aws-sdk/client-lambda is imported directly by two custom resource handlers:

• packages/@aws-cdk/custom-resource-handlers/lib/triggers/lambda/index.ts (used by the Trigger construct)
• packages/@aws-cdk/custom-resource-handlers/lib/aws-synthetics/auto-delete-underlying-resources-handler/index.ts

Both handlers are bundled (esbuild) and airlifted into aws-cdk-lib via packages/aws-cdk-lib/scripts/airlift-custom-resource-handlers.sh, so the vulnerable fast-xml-parser code ends up inlined into the compiled Lambda asset that gets deployed into a user's AWS account whenever these custom resources are used.

Note: this is not visible via npm audit/yarn audit on a downstream CDK app, because @aws-sdk/client-lambda (and therefore fast-xml-parser) is not listed in the published aws-cdk-lib package.json dependencies — it's only visible when auditing the aws-cdk source monorepo itself, or by unpacking the built package and scanning the bundled handler code directly. This is likely why it hasn't been picked up by the automated yarn-upgrade workflow or Dependabot yet.

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

No response

Expected Behavior

Bundled custom resource handler code should not ship with library versions that have known CVEs.

Current Behavior

Running yarn audit against the aws-cdk repository (main branch) reports a critical severity finding:

fast-xml-parser  >=4.1.3 <4.5.4
Severity: critical
fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE entity names - https://github.com/advisories/GHSA-m7jm-9gc2-mpf2
fix available via `npm audit fix`
node_modules/fast-xml-parser
  @aws-sdk/core  >=3.0.0
  Depends on vulnerable versions of fast-xml-parser
  node_modules/@aws-sdk/core
    @aws-sdk/client-sso-oidc
    node_modules/@aws-sdk/client-sso-oidc
      @aws-sdk/client-lambda
      node_modules/@aws-sdk/client-lambda

Path (from yarn audit --json):

@aws-cdk/custom-resource-handlers>@aws-sdk/client-lambda>@aws-sdk/client-sso-oidc>@aws-sdk/core>fast-xml-parser

Reproduction Steps

git clone https://github.com/aws/aws-cdk.git
cd aws-cdk
yarn install
yarn audit --json | grep -A2 '"module_name":"fast-xml-parser"'

The audit reports fast-xml-parser@4.4.1 (vulnerable range >=4.1.3 <4.5.4) reachable through packages/@aws-cdk/custom-resource-handlers's pinned @aws-sdk/client-lambda@3.632.0 dependency chain, in addition to a separate (test-only, non-shipped) path through @aws-cdk/integration-test-deployment.

Possible Solution

Force fast-xml-parser to a patched version (>=4.5.4) for the dependency chain used by custom-resource-handlers, e.g. by adding a resolutions entry to the root package.json:

"resolutions": {
  "fast-xml-parser": "^4.5.4"
}

and running yarn install to update yarn.lock, then rebuilding custom-resource-handlers so the bundled/airlifted Lambda assets pick up the patched version. Alternatively, bump the pinned @aws-sdk/client-* dependencies in packages/@aws-cdk/custom-resource-handlers/package.json (currently 3.632.0, from August 2024) to a newer release that no longer depends on the vulnerable fast-xml-parser version.

Additional Information/Context

Similar in nature to the recently fixed bundled-dependency CVEs in this repo (#38257, #38409 for brace-expansion), except this one is a shipped Lambda asset dependency rather than a build-tool dependency, so the fix needs to ensure the airlifted/bundled handler code is rebuilt with the patched dependency, not just the root yarn.lock.

AWS CDK Library version (aws-cdk-lib)

2.262.1 (main branch, commit da35408)

AWS CDK CLI version

N/A (found via source repository audit, not a deployed app)

Node.js Version

v22.22.3

OS

Linux (WSL2)

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

Hi @AtsutoNakayama,

┌──────────────────────────────────────────────────────────┐
│ 🔴 Reported State                                        │
│ fast-xml-parser 4.4.1 (critical) reachable via the       │
│ pinned @aws-sdk/client-lambda in the monorepo lockfile   │
└─────────────────────────────┬────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────┐
│ 🔍 Root Cause                                            │
│ custom-resource-handlers pins @aws-sdk 3.632.0 (2024);   │
│ but esbuild marks @aws-sdk/* external, so nothing ships  │
└─────────────────────────────┬────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────┐
│ 🟢 Suggested Fix                                         │
│ Bump the stale SDK pin (or add a resolutions entry);      │
│ no asset rebuild needed                                  │
└──────────────────────────────────────────────────────────┘

Thank you for an unusually well-researched report — the dependency path, the advisory, and the note about why downstream npm audit can't see it are all accurate and useful.

One part doesn't hold, though, and it changes the severity: the vulnerable code is not inlined into the deployed Lambda assets. The handler bundles mark the SDK as external, in packages/@aws-cdk/custom-resource-handlers/scripts/generate.js:

external: ['@aws-sdk/*', 'aws-sdk'],

I verified this against the published aws-cdk-lib rather than the source tree. Both handlers you named contain no fast-xml-parser, and no XMLParser or DOCTYPE code markers either (I checked for those too, since esbuild minifies identifiers and a name-only grep could give a false negative):

custom-resource-handlers/dist/triggers/lambda/index.js                     20,508 bytes
  -> require("@aws-sdk/client-lambda"), 0 occurrences of fast-xml-parser
.../aws-synthetics/auto-delete-underlying-resources-handler/index.js        4,075 bytes
  -> require("@aws-sdk/client-lambda"), 0 occurrences of fast-xml-parser

The sizes make it clear on their own — a bundled client-lambda would be megabytes, not 4–20 KB. At execution time these handlers use the AWS SDK v3 that the Lambda runtime provides, so the fast-xml-parser actually in play is AWS's patched copy, not CDK's pinned one.

So this is a real issue, just a narrower one than it looked: the monorepo lockfile resolves a critically-vulnerable fast-xml-parser, which makes yarn audit noisy on a clean clone, and @aws-sdk/client-lambda is pinned to an August 2024 release. Worth fixing on hygiene grounds.

On the fix: your resolutions suggestion would work and matches existing practice — the root package.json already pins @smithy/types, markdown-it, and others that way. My mild preference is bumping the pinned @aws-sdk/client-* versions instead, since that addresses the two-year staleness rather than one symptom of it. Either way, and unlike #38257/#38409, no rebuild or re-airlift of the bundled assets is needed — the change is lockfile-only, because the SDK was never bundled.

A PR for either approach would be welcome.

[AtsutoNakayama]

Thanks @pahud, you're right and I appreciate the correction.

I verified it directly: packages/@aws-cdk/custom-resource-handlers/scripts/generate.js does mark @aws-sdk/* / aws-sdk as external in the esbuild config, and the built output confirms it -

dist/triggers/lambda/index.js                                              20,593 bytes
dist/aws-synthetics/auto-delete-underlying-resources-handler/index.js       4,164 bytes

grep -c "fast-xml-parser"                    -> 0 in both
grep -c "XMLParser|DOCTYPE|DocTypeReader"     -> 0 in both
grep -o 'require("@aws-sdk/[a-z-]*")'         -> require("@aws-sdk/client-lambda") / require("@aws-sdk/client-synthetics")

So the vulnerable fast-xml-parser is not inlined into the deployed Lambda asset - these handlers require() @aws-sdk/* as an external module, which resolves against whatever AWS SDK the Lambda Node.js runtime provides at execution time (maintained/patched by AWS independently of this repo's lockfile).

Updating the description below and the title to reflect the corrected, narrower scope: this is a stale/noisy lockfile resolution (@aws-sdk/client-lambda pinned to an August 2024 release), not a vulnerability that reaches deployed user resources. Still worth fixing so a clean yarn audit doesn't flag it and so the pin isn't two years stale, but not a fix-level security issue - I'll retitle the linked PR (#38416) to chore(deps): accordingly.

[AtsutoNakayama]

Hi @pahud, following up with what I found while looking into implementing the SDK version bump you suggested.

The 3.632.0 pin isn't specific to custom-resource-handlers - it's the exact same pin across 8 package.json files in the monorepo:

• packages/@aws-cdk/custom-resource-handlers
• packages/@aws-cdk/aws-custom-resource-sdk-adapter
• packages/@aws-cdk/aws-amplify-alpha
• packages/@aws-cdk/aws-redshift-alpha
• packages/@aws-cdk/integ-tests-alpha
• packages/aws-cdk-lib
• packages/@aws-cdk-testing/framework-integ
• tools/@aws-cdk/integration-test-deployment

This looks like a deliberate repo-wide lockstep policy rather than one package falling behind. Latest available is 3.1096.0 (~2 years / 464 releases ahead).custom-resource-handlers itself should be thers - scripts/generate.js marks@aws-sdk/* as external in the esbuild coversion bump there is compile-time-only (nobundled runtime behavior change). I haven't so I can't say the types still line up across every handler in the package, just that a bad bump would surface as a build failure rather than a runtime surprise. I also haven't verified whether the other 7 pae way, and bumping just one of the eightwould break whatever intentional version consistency is being kept across the group.

Given that, my preference is to leave PR #38416 as-is (the resolutions override, minimal and already validated) and open a separate follow-up issue to bump all at's a bigger, cross-cutting change thatdeserves its own scoped PR and review rather-line security fix.As a fallback, if you'd rather not wait on a instead update the pinned@aws-sdk/client-* versions in custom-resome issue/PR - that's the one where a bad bump would at least fail loudly at build time rather than break silently at runtime - though it would leave that package out of step with the other 7 until the rest One more thing worth flagging for whoever piaws-sdk/core@3.629.0 is the only thing inthe whole monorepo lockfile that depends on via yarn.lock), and the latest@aws-sdk/core has dropped it in favor of e all 8 packages are bumped,fast-xml-parser should disappear from the utions entry added in PR #38416 will become
dead configuration that should be removed at

Let me know which direction you'd prefer and I'll proceed accordingly.