The npm dd-trace package is Datadog's official Application Performance Monitoring tracer for Node.js, and because it instruments your application by monkey-patching core modules at startup, its security posture is worth understanding even though the library itself has a good track record. dd-trace is actively maintained by Datadog and does not carry a headline code-execution CVE, but it runs with the same privileges as your app and pulls in a dependency tree of its own. This review covers what to watch and how to configure it safely.
APM tracers are unusual dependencies. Most libraries you call; dd-trace calls into everything. To capture spans automatically, it wraps HTTP clients, database drivers, and the runtime's async machinery. That deep integration is the whole value proposition, and it is also why "is this tracer trustworthy?" is a fair question.
How dd-trace instruments your app
You initialize dd-trace before anything else in your process:
// Must be the first import in your entry file
import tracer from "dd-trace";
tracer.init();
At init(), the tracer patches the modules it knows how to instrument, replacing functions with wrapped versions that open and close spans around the original call. It hooks into Node's AsyncLocalStorage / async_hooks to propagate trace context across asynchronous boundaries so a single request's spans stay correlated.
The security implication is straightforward: dd-trace sees the arguments to instrumented calls, including database queries, HTTP headers, and URLs. That is by design (it is how you get useful traces), but it means the tracer is inside your most sensitive data paths. You control what leaves the process through its configuration, which we will get to.
The dependency and CVE picture
The dd-trace npm package has not had a critical code-execution vulnerability in its own code, but two items are worth knowing because they illustrate how tracer risk actually shows up.
CVE-2022-25883 was a regular-expression denial-of-service in semver, a transitive dependency. dd-trace at the affected time pulled in a vulnerable semver range, and the resolution was to update to a patched semver (7.5.3 or later). Nothing in dd-trace's own logic was flawed; the exposure came through the tree beneath it. This is the ordinary transitive-CVE pattern and the reason you scan the whole tree, not just direct dependencies.
Separately, in January 2026 Node.js disclosed CVE-2025-59466, a denial-of-service affecting applications that use async_hooks / AsyncLocalStorage under certain stack-overflow conditions. Because dd-trace relies on AsyncLocalStorage for context propagation, Datadog published guidance and validated the tracer against patched Node.js versions. The fix here is at the Node.js runtime level, not in dd-trace, which underlines that a tracer's risk is entangled with the runtime it hooks.
Verify both against primary sources: CVE-2022-25883 on the GitHub advisory database and Datadog's own advisory for the Node.js issue.
Configuring dd-trace safely
Because the tracer sits in your data paths, the important controls are about what it captures and where it sends it:
- Scrub sensitive data. Enable query obfuscation and configure tag/HTTP-header filtering so tokens, passwords, and PII are not written into span metadata that ships to Datadog. Review the tags your services emit.
- Lock down the agent connection. Traces go to a local Datadog Agent, not straight to the internet. Make sure that agent endpoint is not exposed beyond where it needs to be, and use the environment variables (
DD_TRACE_AGENT_URLand friends) rather than hardcoding. - Disable what you do not use. If you do not need certain integrations or profiling features, turn them off to shrink the runtime surface.
- Keep secrets out of source. The Datadog API key belongs in your secrets manager or environment, never in a committed config file.
# Configure via environment, not committed files
export DD_ENV=production
export DD_SERVICE=checkout-api
export DD_TRACE_AGENT_URL=http://localhost:8126
Keeping it current
dd-trace releases frequently, which is a good sign for a dependency this deep in your stack. The maintenance risk is not neglect; it is falling behind. Because so much of the real exposure is transitive, the discipline that matters is scanning the resolved tree on every build.
Commit your lockfile and run npm audit in CI so a newly disclosed advisory against dd-trace or anything beneath it (the semver case being the textbook example) shows up on the next build rather than in an incident review. An SCA tool that resolves and monitors the full transitive graph is especially valuable for an APM tracer, since its dependency tree is broad. A scanner such as Safeguard can point at exactly which transitive package introduced a finding and the minimum bump that clears it.
One operational note: because dd-trace patches core modules, test upgrades in staging before rolling to production. A tracer upgrade interacting with a Node.js version change is exactly the scenario CVE-2025-59466 highlighted, so validate the pairing rather than assuming independence. For more on triaging transitive findings, the Safeguard Academy has relevant walkthroughs.
FAQ
Is npm dd-trace safe to use in production?
Yes. It is Datadog's officially maintained tracer with a solid track record and frequent releases. The caveats are operational: it instruments deep into your app, so scrub sensitive data from spans, secure the agent connection, and keep it and its transitive dependencies patched.
Has dd-trace had security vulnerabilities?
Its own code has not had a critical code-execution CVE, but it has been exposed through transitive dependencies, such as CVE-2022-25883 in semver. It is also affected operationally by runtime issues like the Node.js async_hooks DoS (CVE-2025-59466) because it relies on AsyncLocalStorage.
Why does dd-trace need to be imported first?
It instruments other modules by patching them at load time. If those modules are imported and used before tracer.init() runs, the tracer cannot wrap them, so spans go missing. Importing and initializing it first ensures full coverage.
How do I keep sensitive data out of my traces?
Enable query obfuscation and configure header and tag filtering so credentials and PII are not written into span metadata. Review what tags your services emit, and keep the Datadog API key in a secrets manager rather than in committed configuration.