← Home

@sentry/nestjs

51
Versions
License
No
Install Scripts
Missing
Provenance

Supply chain provenance

Status for the latest visible version.

No SLSA provenance npm registry signatures No source commit

Without SLSA provenance there is no cryptographic link between this tarball and the public source — the axios compromise (March 2026) relied on exactly this gap.

Maintainers

sentry-bot

Accepted risks

Findings the reviewer chose to accept rather than block on.

SourceRuleReasonAccepted byWhen
publish-pattern dormant-publish AI (publish-pattern): Major version jump from v8 to v10 explains the gap; sentry-bot is a well-established publisher. ai
publish-pattern new-deps-added AI (publish-pattern): New OTel deps match the package's NestJS instrumentation purpose and are all established CNCF packages. ai
source-diff source-size-tripled AI (source-diff): Size increase consistent with bundling multiple OTel instrumentation libraries in a major version upgrade. ai
phantom-deps phantom-dep:@opentelemetry/api AI (phantom-deps): Indirect dependency via instrumentation-nestjs-core; stable pattern for this package. ai
phantom-deps phantom-dep:@opentelemetry/core AI (phantom-deps): Indirect dependency via instrumentation-nestjs-core; stable pattern for this package. ai
phantom-deps phantom-dep:@opentelemetry/semantic-conventions AI (phantom-deps): Indirect dependency via instrumentation-nestjs-core; stable pattern for this package. ai

Versions (showing 51 of 63)

View all versions
Version Deps Published
10.56.0 5 / 4
10.55.0 6 / 4
10.54.0 6 / 4
10.53.1 7 / 4
10.53.0 7 / 4
10.52.0 7 / 4
10.51.0 7 / 4
10.50.0 7 / 4
10.49.0 7 / 4
10.48.0 7 / 4
10.47.0 7 / 4
10.46.0 7 / 4
10.45.0 7 / 4
10.44.0 7 / 4
10.43.0 7 / 4
10.42.0 7 / 4
10.41.0 7 / 4
10.40.0 7 / 4
10.39.0 7 / 4
10.38.0 7 / 4
10.37.0 7 / 4
10.36.0 7 / 4
10.35.0 7 / 4
10.34.0 7 / 4
10.33.0 7 / 4
10.32.1 7 / 4
10.32.0 7 / 4
10.31.0 7 / 4
10.30.0 7 / 4
10.29.0 7 / 4
10.28.0 7 / 4
10.27.0 7 / 4
10.26.0 7 / 4
10.25.0 7 / 4
10.24.0 7 / 4
10.23.0 7 / 4
10.22.0 7 / 4
10.21.0 7 / 4
10.20.0 7 / 4
10.19.0 7 / 4
10.18.0 7 / 4
10.17.0 7 / 4
10.16.0 7 / 4
10.15.0 7 / 4
10.14.0 7 / 4
10.13.0 7 / 4
10.12.0 7 / 4
10.11.0 7 / 4
10.10.0 7 / 4
10.9.0 7 / 4
10.8.0 7 / 4

v10.56.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.55.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.54.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.53.1

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.53.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.52.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.50.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.

v10.46.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.45.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.44.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.43.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.42.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.41.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.40.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.39.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.38.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.37.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.36.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.35.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.34.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.33.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.32.1

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.32.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.31.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.30.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.29.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.28.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.27.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.26.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.25.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.

v10.24.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.

v10.23.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.

v10.22.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.21.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.20.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.19.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.18.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.17.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.16.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.15.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.14.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.13.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.12.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.11.0

2 findings
MEDIUM GHSA-6465-jgvq-jhgp: Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` osv

### Impact In version 10.11.0, a change to how the SDK collects request data in Node.js applications caused certain incoming HTTP headers to be added as trace span attributes. When `sendDefaultPii: true` was set, a few headers that were previously redacted - including Authorization and Cookie - were unintentionally allowed through. Sentry’s server-side scrubbing (handled by Sentry's Relay edge proxy) normally serves as a second layer of protection. However, because it relied on the same matching logic as the SDK, it also failed to catch these headers in this case. Users may be impacted if: 1. Their Sentry SDK configuration has `sendDefaultPii` set to `true` 2. Their application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.request.header.authorization”, “http.request.header.cookie” or similar. Any potentially sensitive values will be specific to users' applications and configurations. ### Patches The issue has been patched in all Sentry JavaScript SDKs starting from the [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) version. ### Workarounds Sentry strongly encourage customers to upgrade the SDK to the latest available version, [10.27.0](https://github.com/getsentry/sentry-javascript/releases/tag/10.27.0) or later. If it is not possible, consider setting `sendDefaultPii: false` to avoid unintentionally sending sensitive headers. See [here](https://docs.sentry.io/platforms/javascript/guides/node/#step-2-configure) for documentation. ### Resources * https://develop.sentry.dev/sdk/expected-features/data-handling/#sensitive-data * https://github.com/getsentry/sentry-javascript/releases/tag/10.11.0 * https://github.com/getsentry/sentry-javascript/pull/17475 * https://docs.sentry.io/platforms/javascript/guides/node/data-management/data-collected/#cookies

LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.10.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.9.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

v10.8.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.