GHSA-4xcv-9jjx-gfj3

What it actually does

The vulnerable versions of the npm package `mem` can be abused to cause denial of service through unsafe memoization behavior. Because `mem` caches function results based on attacker-controllable inputs, specially crafted or high-cardinality inputs can cause unbounded cache growth or excessive resource consumption in applications that expose memoized functions to untrusted data. The practical result is memory exhaustion, degraded performance, process crashes, or service restarts in Node.js applications that depend on affected versions.

Why it matters to the business

An application using an affected version of `mem` may become slow, unstable, or unavailable if an attacker can repeatedly trigger vulnerable memoized code paths. For internet-facing services, this can lead to outages, degraded customer experience, increased infrastructure costs from resource exhaustion, and operational burden from restarts or incident response. The CVSS score is moderate and there is no known KEV listing or mature public exploitation signal, but the package may be present indirectly through dependency chains, so exposure should be assessed across JavaScript projects.

How an attack unfolds

An attacker first identifies an application endpoint or workflow that passes user-controlled values into functionality memoized with a vulnerable version of `mem`. The attacker then sends many requests containing unique or specially crafted input values so the memoization cache stores a growing number of entries instead of reusing existing ones. Over time, the Node.js process consumes increasing memory and CPU managing the cache. If resource limits are reached, the application may slow significantly, throw out-of-memory errors, crash, or be restarted by a process manager, causing denial of service for legitimate users.

How to fix it

Upgrade `mem` to version 4.0.0 or later. For npm-based projects, update direct dependencies in `package.json` and regenerate the lockfile, or update transitive dependencies through the parent package that brings in `mem`. If immediate upgrade is not possible, reduce exposure by ensuring untrusted input is not used directly as memoization keys, bounding cache size or entry lifetime where supported, adding request rate limits, enforcing payload and parameter limits, and applying memory limits with safe restart behavior for Node.js services. Review any custom memoization wrappers to ensure they cannot grow without bounds from attacker-controlled input.

How to confirm the fix worked

Confirm the fix by checking dependency manifests and lockfiles with `npm ls mem`, `npm audit`, SCA tooling, or lockfile review to verify all resolved instances of `mem` are version 4.0.0 or later. Rebuild and redeploy the application after dependency updates. Where feasible, run a controlled test against relevant endpoints using repeated unique inputs while monitoring process memory to confirm cache growth is bounded and the service remains stable. Also verify rate limits, input size limits, and process memory limits are active for externally reachable services.

Typical attack path

1. Identify a web application, API, job processor, or service using a vulnerable version of the `mem` npm package directly or transitively.
2. Find an endpoint or task where user-controlled input reaches a memoized function.
3. Send repeated requests with many distinct parameter values or payloads to force cache misses and new cache entries.
4. Drive memory usage and processing overhead upward until performance degrades.
5. Cause the Node.js process to become unstable, crash, restart, or stop serving legitimate traffic.

How to detect it

Look for evidence of denial-of-service attempts or successful resource exhaustion in application, web server, reverse proxy, container, process manager, and host telemetry. Useful sources include Node.js application logs, uncaught exception logs, process manager logs such as PM2 or systemd, container orchestration events, APM metrics, memory utilization metrics, HTTP access logs, and load balancer logs. Investigate periods with rapid memory growth, high garbage collection activity, elevated request rates using many unique query strings or body parameters, HTTP 5xx spikes, process restarts, out-of-memory kills, or latency increases. Because this advisory does not define a unique exploit payload, detection should focus on behavioral indicators: repeated cache-miss-like requests, high-cardinality input patterns from one or a small set of clients, and Node.js process memory exhaustion temporally correlated with traffic bursts.

• npm ls mem
• mem@<4.0.0
• JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• ENOMEM
• OOMKilled
• Out of memory: Kill process
• Killed process
• PM2 log: App [
• exited with code [1] via signal [SIGABRT]
• systemd: Main process exited, code=killed, status=9/KILL
• docker: container killed due to memory usage

What your security team should do

• Inventory all JavaScript and Node.js applications for direct or transitive use of `mem`.
• Prioritize remediation for internet-facing services, APIs, or background processors that process untrusted input through memoized code paths.
• Upgrade `mem` to 4.0.0 or later and regenerate lockfiles to eliminate vulnerable resolved versions.
• Use SCA/CI dependency scanning to block reintroduction of vulnerable `mem` versions.
• Add or verify operational safeguards: request rate limiting, input validation, payload size limits, memory monitoring, and controlled process restarts.
• Review application telemetry for unexplained memory growth, repeated crashes, restart loops, or traffic patterns with large volumes of unique parameters.