Repository navigation
Conversation
dd-trace before 6.20.1 and 5.131.1 is affected by a ReDoS in the default query string obfuscation regex (GHSA-x94g-w73q-hpcw). Bump the v6 range in package.json and the hand-maintained v5 pin used for the Node 18 and 20 layers, and keep peerDependencies advertising both lines. Recapture the local integration snapshots. The newer tracers add the `_dd.sdk.otlp_export` span tag and a `monitored` frame from the dd-trace Lambda handler to error stacks.
![datadog-prod-us1-5[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
There was a problem hiding this comment.
Release layers force import-in-the-middle 3.4.0 despite upgraded dd-trace requiring 3.5.3. Local integration fixtures install a different loader combination, leaving compatibility of the shipped combination unverified; runtime breakage has not been established.
🤖 Bits Code Review · Commit 851dfbf
| integrity sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA== | ||
|
|
||
| import-in-the-middle@3.4.0, import-in-the-middle@^3.3.2: | ||
| import-in-the-middle@3.4.0, import-in-the-middle@3.5.3: |
There was a problem hiding this comment.
For Node 22+ release layers, dd-trace 6.23.0 requests exactly import-in-the-middle 3.5.3, but package.json's resolution forces Yarn to install 3.4.0. The local integration Dockerfiles use npm, which ignores that resolution, so passing snapshots do not validate the loader combination actually shipped. ESM instrumentation compatibility remains uncertain. Update or remove the package.json override and regenerate yarn.lock, or explicitly verify compatibility before retaining it.
React: 👍 useful · 👎 wrong · 😕 unclear · 👀 right, but not acting on it
What each reaction means
- 👍 Useful: correct, and you're fixing it or will.
- 👎 Wrong: the finding is incorrect, for example the bug can't happen or the code was misread.
- 😕 Unclear: you can't tell what it means or why it matters.
- 👀 Right, not acting: correct, but intended, out of scope for this PR, a known risk, or too minor.
🤖 Bits Code Review · Open Bits AI session
There was a problem hiding this comment.
Good catch. The 3.4.0 resolution came from #835, which mirrored dd-trace-js pinning import-in-the-middle to 3.4.0 after 3.5.0 broke esbuild. import-in-the-middle 3.5.1 fixed that, and dd-trace-js has pinned 3.5.1 since 6.16.0 and 3.5.3 since 6.23.0 and 5.134.0. With both dd-trace lines pinning an exact version, the resolution no longer guards against yarn upgrade drift; it only forces an older version than the one dd-trace is tested with.
I removed the resolution in 554e123. Layers built from the Dockerfile for Node 20 and 22 now ship import-in-the-middle 3.5.3 alongside dd-trace 5.134.0 and 6.23.0. The local integration runs install through npm and already used 3.5.3, so they now cover what the layer ships.
The resolution mirrored a pin in dd-trace-js after import-in-the-middle 3.5.0 broke esbuild. 3.5.1 fixed that, and dd-trace 6.23.0 and 5.134.0 both pin import-in-the-middle 3.5.3 exactly. Forcing 3.4.0 would ship the layers with an older version than the one dd-trace is tested against.
|
We're affected by this as well (Node 24 Lambdas, layer 143) and can't patch the bundled tracer ourselves. Would appreciate a release with updated layers after merge. Thanks. |
There was a problem hiding this comment.
Thanks for this, I upgraded to the latest versions, follow #860
What does this PR do?
Updates both dd-trace version lines used by the Node.js Lambda layers. It bumps the v6 development dependency and peer range to 6.23.0, the v5 peer range and layer pin to 5.134.0, regenerates
yarn.lock, and recaptures the local integration snapshots.It also drops the
import-in-the-middle3.4.0 resolution. Both dd-trace versions pin 3.5.3 exactly, and the resolution would otherwise force the layers onto 3.4.0.Motivation
CVE-2026-116693 affects dd-trace before 5.131.1 and 6.20.1. Layer v12.143.0 bundles 5.126.0 for Node 18/20 and 6.15.0 for Node 22+. Customers cannot update the tracer bundled in the layer themselves.
Testing Guidelines
Locally on macOS arm64 with Docker:
yarn build,yarn lint, andyarn testpass (54 suites, 732 tests).scripts/check_dd_trace_v5_pin.shandscripts/test_install_deps.shpass; Node 20 pins 5.134.0. Comparison-only runs of./integration_tests_local/run.shpass for Node 18, 20, 22, 24, and 26.The local Docker VM has 2 CPUs, so I lowered
run.sh's--cpus 4to 2 locally without committing it. This changes the observed proactive-initworkerCountto 2 on Node 22 and 24; the committed snapshots retain the value 4 from main.Additional Notes
This supersedes #858: that PR drops v5 from the peer range, causing Node 18/20
ERESOLVEfailures; leaves the v5 layer pin at vulnerable 5.126.0; and does not update the local integration snapshots. The snapshot changes here are the_dd.sdk.otlp_exporttag and amonitoredframe in error stacks. Other diff lines are RIE log reordering, which the comparison ignores.I could not run the AWS end-to-end suite or GitLab layer publishing jobs. A Datadog member needs to run those pipelines. Please release updated layers after merge.
Types of Changes
Check all that apply