Listen to this Post
The vulnerability exists in @fastify/accepts-serializer, a Node.js package used to select a serializer based on the HTTP `Accept` header. Internally, the package caches the results of its serializer-selection logic to improve performance. Each unique `Accept` header value encountered in a request becomes a new key in this cache.
The flaw arises because this cache is implemented without any size limit or eviction policy. The cache is stored in the Node.js process heap, which is the primary memory arena for a running Node instance. When the server processes an incoming request, the package computes a cache key derived from the `Accept` header string and stores the result.
An unauthenticated remote attacker can exploit this by sending a large number of HTTP requests, each with a slightly different but syntactically valid `Accept` header (e.g., text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8). Because the header strings vary, each request creates a new cache entry. As the cache grows without bound, it consumes an increasing amount of heap memory.
Under sustained attack, memory allocation continues until the Node.js process exceeds its heap limit and crashes with a fatal `JavaScript heap out of memory` error. This results in a denial-of-service (DoS) condition, causing the application to become unresponsive to legitimate traffic. The crash requires a full process restart to restore service, making this vulnerability a significant risk for production deployments. The fix in version 6.0.4 replaces the unbounded cache with a bounded Least Recently Used (LRU) cache, which discards the oldest entries when it reaches its configurable size limit (default 100).
Platform: @fastify/accepts-serializer (npm)
Version: <= 6.0.3
Vulnerability: Denial of Service via Unbounded Accept Header Cache Growth (CWE-770: Allocation of Resources Without Limits or Throttling)
Severity: High
date: 2026-05-04
Prediction: include expected Patch date. 2026-05-04
What Undercode Say:
Analytics of the vulnerability’s impact on production systems.
Check currently installed version of the vulnerable package
npm list @fastify/accepts-serializer
Find all package.json files containing the vulnerable dependency
find /path/to/your/project -name "package.json" -exec grep -H '@fastify/accepts-serializer' {} \;
Simulate unbounded cache growth for testing (use in isolated environment only)
for i in {1..10000}; do curl -H "Accept: application/vnd.test+json;version=$i" http://target-server/; done
Monitor Node.js heap usage in real-time to detect potential exploitation
node --inspect-brk -e "setInterval(() => console.log(process.memoryUsage().heapUsed / 1024 / 1024), 1000)" & curl -X POST http://localhost:3000/
Upgrade the package to the patched version across all projects
npm install @fastify/[email protected] --save
Verify the upgrade was successful and the new cacheSize configuration is applied
npm list @fastify/accepts-serializer && echo "Check configuration: new FastifyAcceptsSerializer({ cacheSize: 200 })"
Exploit:
A remote unauthenticated client sends a large volume of HTTP requests, each with a unique `Accept` header value. The server processes each request and the `@fastify/accepts-serializer` package caches the result for each unique `Accept` header. As the number of unique headers grows, the cache expands unbounded, consuming all available Node.js heap memory. This eventually causes the process to crash with a `JavaScript heap out of memory` error, leading to a denial of service. No privileges or prior access are required, making the attack trivial to execute from anywhere on the network.
Protection from this CVE
The only complete protection is to upgrade to `@fastify/accepts-serializer` version 6.0.4 or higher. This version introduces a bounded LRU (Least Recently Used) cache with a default limit of 100 entries, which prevents cache-based memory exhaustion. The cache size is also configurable via the `cacheSize` plugin option, allowing deployment-specific tuning. No effective workarounds exist, and downgrading or continuing to use unpatched versions leaves the application vulnerable.
Impact
Without the patch, a single attacker or a small botnet can reliably crash the Node.js process. Under sustained load, the process may repeatedly restart and crash, effectively taking the service offline. The attack does not require authentication, consumes minimal bandwidth, and does not depend on application-specific logic. For high-traffic services, legitimate user requests can also consume cache memory over time, turning a performance degradation into a potential outage even without malicious intent. The vulnerability is particularly dangerous in environments where Node.js heap size is limited or where multiple tenants share the same process.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
