@sentry/solidstart
Official Sentry SDK for Solid Start
Supply chain provenance
Status for the latest visible version.
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
Versions (showing 51 of 60)
| Version | Deps | Published |
|---|---|---|
| 10.56.0 | 4 / 9 | |
| 10.55.0 | 4 / 9 | |
| 10.54.0 | 4 / 9 | |
| 10.53.1 | 4 / 9 | |
| 10.53.0 | 4 / 9 | |
| 10.52.0 | 4 / 9 | |
| 10.51.0 | 4 / 9 | |
| 10.50.0 | 4 / 9 | |
| 10.49.0 | 4 / 9 | |
| 10.48.0 | 4 / 9 | |
| 10.47.0 | 4 / 9 | |
| 10.46.0 | 4 / 9 | |
| 10.45.0 | 4 / 9 | |
| 10.44.0 | 4 / 9 | |
| 10.43.0 | 4 / 9 | |
| 10.42.0 | 4 / 9 | |
| 10.41.0 | 4 / 9 | |
| 10.40.0 | 4 / 9 | |
| 10.39.0 | 4 / 9 | |
| 10.38.0 | 4 / 9 | |
| 10.37.0 | 4 / 9 | |
| 10.36.0 | 4 / 9 | |
| 10.35.0 | 4 / 9 | |
| 10.34.0 | 4 / 9 | |
| 10.33.0 | 4 / 9 | |
| 10.32.1 | 4 / 9 | |
| 10.32.0 | 4 / 9 | |
| 10.31.0 | 4 / 9 | |
| 10.30.0 | 4 / 9 | |
| 10.29.0 | 4 / 9 | |
| 10.28.0 | 4 / 9 | |
| 10.27.0 | 4 / 9 | |
| 10.23.0 | 4 / 9 | |
| 10.22.0 | 4 / 9 | |
| 10.21.0 | 4 / 9 | |
| 10.20.0 | 4 / 9 | |
| 10.19.0 | 4 / 9 | |
| 10.18.0 | 4 / 9 | |
| 10.17.0 | 4 / 9 | |
| 10.16.0 | 4 / 9 | |
| 10.15.0 | 4 / 9 | |
| 10.14.0 | 4 / 9 | |
| 10.13.0 | 4 / 9 | |
| 10.12.0 | 4 / 9 | |
| 10.11.0 | 4 / 9 | |
| 10.10.0 | 4 / 9 | |
| 10.9.0 | 4 / 9 | |
| 10.8.0 | 4 / 9 | |
| 10.7.0 | 4 / 9 | |
| 10.6.0 | 4 / 9 | |
| 10.5.0 | 4 / 9 |
v10.56.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.55.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.54.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.53.1
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.53.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.52.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.50.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.49.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.48.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.47.0
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.
v10.46.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.45.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.44.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.43.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.42.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.41.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.40.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.39.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.38.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.37.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.36.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.35.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.34.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.33.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.32.1
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.32.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.31.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.30.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.29.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.28.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.27.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.23.0
2 findings### 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
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### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.21.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.20.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.19.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.18.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.17.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.16.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.15.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.14.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.13.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.12.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.11.0
2 findings### 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
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.10.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.9.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.8.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.7.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.6.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v10.5.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.