GHSA-r5w7-f542-q2j4
Potential DoS when using ContextLines integration
- Severity
- 3.7 / 10
- Low · CVSS 3.1
- Exploit chance (EPSS)
- —
- No score published
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-774 Allocation of File Descriptors or Handles Without Limits or Throttling
- Fix
- Available
- 11 packages have a fixed version
Description
Impact
The ContextLines integration uses readable streams to more efficiently use memory when reading files. The ContextLines integration is used to attach source context to outgoing events.
The stream was not explicitly closed after use. This could lead to excessive amounts of file handles open on the system and potentially lead to a Denial of Service (DoS).
The ContextLines integration is enabled by default in the Node SDK (@sentry/node) and SDKs that run in Node.js environments (@sentry/astro, @sentry/aws-serverless, @sentry/bun, @sentry/google-cloud-serverless, @sentry/nestjs, @sentry/nextjs, @sentry/nuxt, @sentry/remix, @sentry/solidstart, @sentry/sveltekit).
Patches
Users should upgrade to version 8.49.0 or higher.
Workarounds
To remediate this issue in affected versions without upgrading to version 8.49.0 and above you can disable the ContextLines integration. See the docs for more details.
Sentry.init({
// ...
integrations: function (integrations) {
// integrations will be all default integrations
return integrations.filter(function (integration) {
return integration.name !== "ContextLines";
});
},
});
If you disable the ContextLines integration, you will lose source context on your error events.
References
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| @sentry/astro | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/aws-serverless | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/bun | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/google-cloud-serverless | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/nestjs | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/nextjs | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/node | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/nuxt | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/remix | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/solidstart | >= 8.10.0, < 8.49.0 |
8.49.0 |
| @sentry/sveltekit | >= 8.10.0, < 8.49.0 |
8.49.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
@sentry/astro npm → 8.49.0
- npm
npm install @sentry/astro@8.49.0- yarn
yarn add @sentry/astro@8.49.0- pnpm
pnpm add @sentry/astro@8.49.0
@sentry/aws-serverless npm → 8.49.0
- npm
npm install @sentry/aws-serverless@8.49.0- yarn
yarn add @sentry/aws-serverless@8.49.0- pnpm
pnpm add @sentry/aws-serverless@8.49.0
@sentry/bun npm → 8.49.0
- npm
npm install @sentry/bun@8.49.0- yarn
yarn add @sentry/bun@8.49.0- pnpm
pnpm add @sentry/bun@8.49.0
@sentry/google-cloud-serverless npm → 8.49.0
- npm
npm install @sentry/google-cloud-serverless@8.49.0- yarn
yarn add @sentry/google-cloud-serverless@8.49.0- pnpm
pnpm add @sentry/google-cloud-serverless@8.49.0
@sentry/nestjs npm → 8.49.0
- npm
npm install @sentry/nestjs@8.49.0- yarn
yarn add @sentry/nestjs@8.49.0- pnpm
pnpm add @sentry/nestjs@8.49.0
@sentry/nextjs npm → 8.49.0
- npm
npm install @sentry/nextjs@8.49.0- yarn
yarn add @sentry/nextjs@8.49.0- pnpm
pnpm add @sentry/nextjs@8.49.0
@sentry/node npm → 8.49.0
- npm
npm install @sentry/node@8.49.0- yarn
yarn add @sentry/node@8.49.0- pnpm
pnpm add @sentry/node@8.49.0
@sentry/nuxt npm → 8.49.0
- npm
npm install @sentry/nuxt@8.49.0- yarn
yarn add @sentry/nuxt@8.49.0- pnpm
pnpm add @sentry/nuxt@8.49.0
@sentry/remix npm → 8.49.0
- npm
npm install @sentry/remix@8.49.0- yarn
yarn add @sentry/remix@8.49.0- pnpm
pnpm add @sentry/remix@8.49.0
@sentry/solidstart npm → 8.49.0
- npm
npm install @sentry/solidstart@8.49.0- yarn
yarn add @sentry/solidstart@8.49.0- pnpm
pnpm add @sentry/solidstart@8.49.0
@sentry/sveltekit npm → 8.49.0
- npm
npm install @sentry/sveltekit@8.49.0- yarn
yarn add @sentry/sveltekit@8.49.0- pnpm
pnpm add @sentry/sveltekit@8.49.0
Severity breakdown
CVSS 3.1 3.7
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- Low
Weakness
CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling
The product allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.
How to prevent it
- Operation, Architecture and Design: Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
References
Packages
Other links
Timeline
- Published
- Last updated by the source
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-6465-jgvq-jhgp Sentry's sensitive headers are leaked when `sendDefaultPii` is set to `true` | Medium | Also affects @sentry/astro |
| GHSA-852m-cvvp-9p4w Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion | Medium | Same weakness, CWE-774 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor