Update apps/site/pages/en/blog/vulnerability/january-2026-dos-mitigation-async-hooks.md

Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-off-by: Matteo Collina <matteo.collina@gmail.com>

Author: mcollina

apps/site/pages/en/blog/vulnerability/january-2026-dos-mitigation-async-hooks.md

@@ -1,5 +1,5 @@
 ---
-date: 2026-01-08T17:00:00.000Z
+date: 2026-01-13T17:00:00.000Z
 category: vulnerability
 title: Mitigating Denial-of-Service Vulnerability from Unrecoverable Stack Space Exhaustion for React, Next.js, and APM Users
 slug: january-2026-dos-mitigation-async-hooks
@@ -20,7 +20,7 @@ Node.js/V8 makes a best-effort attempt to recover from stack space exhaustion wi
 
 Due to the prevalence of this usage pattern in frameworks, including but not limited to React/Next.js, a significant part of the ecosystem is expected to be affected.
 
-The bug fix is included in a security release because of its widespread impact on the ecosystem. However, this is only a mitigation for the general risk that lies in the ecosystem’s dependence on recoverable stack space exhaustion for service availability.
+The bug fix is included in a security release because of its widespread impact on the ecosystem. However, this is only a mitigation for the general risk that lies in the ecosystem's dependence on recoverable stack space exhaustion for service availability.
 
 **For users of these frameworks/tools and server hosting providers**: Update as soon as possible.
 
@@ -174,31 +174,44 @@ A user sending deeply nested JSON can crash your entire server:
 **Without `async_hooks`**: `try-catch` catches the `RangeError`, returns 500, server continues
 **With `async_hooks` (React/Next.js)**: Server crashes immediately with exit code 7
 
-## A Brief History: From async_hooks to AsyncContextFrame
+## Why This Affects Every APM User
 
-Understanding this bug requires knowing how Node.js evolved its async context tracking.
+Application Performance Monitoring (APM) tools are essential infrastructure for production applications. They track request latency, identify bottlenecks, trace errors to their source, and alert teams when something goes wrong. Companies use APM tools like Datadog, New Relic, Dynatrace, Elastic APM, and OpenTelemetry to maintain visibility into their distributed systems.
 
-### The async_hooks Era
+To provide this functionality, APM tools need to follow a request as it flows through your application, even across async boundaries. When an HTTP request comes in, is processed by middleware, queries a database, calls an external API, and finally returns a response, the APM needs to correlate all of these operations into a single trace. This requires async context tracking.
 
-[`async_hooks`](https://nodejs.org/api/async_hooks.html) was introduced in [Node.js 8 (2017)](https://nodejs.org/en/blog/release/v8.0.0) as a low-level API to track asynchronous resources. It provides callbacks (`init`, `before`, `after`, `destroy`) that fire at key points in an async resource's lifecycle. APM tools immediately adopted it to trace requests across async boundaries.
+Most modern APM tools use `AsyncLocalStorage` (which is built on `async_hooks` in versions of Node.js before Node 24) to propagate trace context across async operations. The moment you `require('dd-trace')`, `require('newrelic')`, or initialize OpenTelemetry, your application has `async_hooks` enabled.
 
-However, `async_hooks` has significant performance overhead. Every Promise creation, every timer, and every I/O operation triggers these callbacks. This cost is unavoidable when the hooks are enabled.
+The irony is notable: the tools you install to monitor and debug crashes can make a category of crashes behave differently. This is not the fault of the APM tools; they are using Node.js APIs exactly as intended.
 
-### AsyncLocalStorage
+## Why This Is Only a Mitigation, and The Vulnerability Lies Elsewhere
 
-[Node.js 12.17.0 (2020)](https://nodejs.org/en/blog/release/v12.17.0) introduced [`AsyncLocalStorage`](https://nodejs.org/api/async_context.html#class-asynclocalstorage), a higher-level API built on top of `async_hooks`. It provides a cleaner interface for the most common use case: storing context that flows through async operations (like request IDs, user sessions, or tracing spans).
+While this issue has significant practical impact, we want to be clear about why Node.js is treating this fix as a mere mitigation of security vulnerability risks at large:
 
-React Server Components and Next.js adopted `AsyncLocalStorage` for request context tracking, unknowingly inheriting all of `async_hooks` behaviors, including this bug.
+### Stack Space Exhaustion Is Not Specified Behavior
 
-### The AsyncContextFrame Revolution (Node.js 24+)
+The "Maximum call stack size exceeded" error is not part of the ECMAScript specification. [The specification does not impose any limit, assuming infinite stack space](https://tc39.es/ecma262/#execution-context-stack); imposing a limit and throwing an error is simply behavior that JavaScript engines implement on a best-effort basis. Building a security model on top of an undocumented, unspecified feature that isn't guaranteed to work consistently would be unreliable.
 
-In [Node.js 24](https://nodejs.org/en/blog/release/v24.0.0), `AsyncLocalStorage` was reimplemented using a new V8 feature called [`AsyncContextFrame`](https://github.com/tc39/proposal-async-context). This approach integrates context tracking directly into V8's Promise implementation, eliminating the need for JavaScript callbacks on every async operation.
+It's worth noting that even when ECMAScript specifies that [proper tail calls](https://tc39.es/ecma262/#sec-tail-position-calls) [should reuse stack frames](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model#tail_calls), this is not implemented by most JavaScript engines today, including V8. And in the few JavaScript engines that do implement it, proper tail calls can block an application with infinite recursion instead of hitting the stack size limit at some point and stopping with an error, which is also a Denial-of-Service factor. This reinforces that stack overflow behavior cannot be relied upon for defending against Denial-of-Service attacks.
 
-The result is dramatically better performance. Importantly for this bug, `AsyncLocalStorage` no longer uses `async_hooks.createHook()` internally. This is why React and Next.js are not affected by this bug on Node.js 24+.
+### V8 Doesn't Treat This as a Security Issue
 
-Note: `AsyncLocalStorage` is still exported from the `async_hooks` module for backwards compatibility, even though it no longer uses the `async_hooks` machinery internally on Node.js 24+. It's also available from `node:async_hooks` and the newer `node:async_context` module.
+The stack space handling in Node.js is primarily implemented by V8. JavaScript engines developed for browsers have a different security model, and they do not treat crashes like this as security vulnerabilities ([example](https://issues.chromium.org/issues/432385241)). This means similar bugs reported in the upstream will not go through vulnerability disclosure procedures, making any security classification by Node.js alone ineffective.
 
-For more details on this evolution and its performance implications, see [The Hidden Cost of Context](https://blog.platformatic.dev/the-hidden-cost-of-context).
+### uncaughtException Limitations
+
+The `uncaughtException` handler is not designed to recover the process after it fires. The Node.js documentation explicitly warns against this pattern. Specifically, the documentation states that ["Exceptions thrown from within the event handler will not be caught. Instead, the process will exit with a non-zero exit code, and the stack trace will be printed. This is to avoid infinite recursion."](https://nodejs.org/api/process.html#warning-using-uncaughtexception-correctly)
+
+Trying to invoke the handler after the call stack size is exceeded would itself throw. The fact that it works without promise hooks is largely coincidental rather than guaranteed behavior.
+
+### Why We Put It In a Security Release
+
+Although it is a bug fix for an unspecified behavior, we chose to include it in the security release because of its widespread impact on the ecosystem.
+React Server Components, Next.js, and virtually every APM tool are affected. The fix improves developer experience and makes error handling more predictable.
+
+However, it's important to note that we were fortunate to be able to fix this particular case. There's no guarantee that similar edge cases involving stack overflow and `async_hooks` can always be addressed. **For mission-critical paths that must defend against infinite recursion or stack overflow from recursion whose depth can be controlled by an attacker, always sanitize the input or impose a limit on the depth of recursion by other means**.
+
+It's worth noting that large array allocations can suffer from similar issues, like the recent [`qs`](https://github.com/ljharb/qs) vulnerability [CVE-2025-15284](https://github.com/ljharb/qs/security/advisories/GHSA-6rw7-vpxm-498p) showed. It's paramount that developers validate and constrain resource usage that could be controlled by an attacker. The runtime cannot always recover reliably from resource exhaustion after-the-fact.
 
 ## Technical Deep Dive
 
@@ -292,45 +305,6 @@ The complete sequence when stack overflow occurs:
 
 The error originated in **user code** (the recursive pattern), but because it manifests while the hook callback is the active frame, it's treated as a fatal hook error.
 
-## Why This Is Only a Mitigation, and The Vulnerability Lies Elsewhere
-
-While this issue has significant practical impact, we want to be clear about why Node.js is treating this fix as a mere mitigation of security vulnerability risks at large:
-
-### Stack Space Exhaustion Is Not Specified Behavior
-
-The "Maximum call stack size exceeded" error is not part of the ECMAScript specification. [The specification does not impose any limit, assuming infinite stack space](https://tc39.es/ecma262/#execution-context-stack); imposing a limit and throwing an error is simply behavior that JavaScript engines implement on a best-effort basis. Building a security model on top of an undocumented, unspecified feature that isn't guaranteed to work consistently would be unreliable.
-
-It's worth noting that even when ECMAScript specifies that [proper tail calls](https://tc39.es/ecma262/#sec-tail-position-calls) [should reuse stack frames](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model#tail_calls), this is not implemented by most JavaScript engines today, including V8. And in the few JavaScript engines that do implement it, proper tail calls can block an application with infinite recursion instead of hitting the stack size limit at some point and stopping with an error, which is also a Denial-of-Service factor. This reinforces that stack overflow behavior cannot be relied upon for defending against Denial-of-Service attacks.
-
-### V8 Doesn't Treat This as a Security Issue
-
-The stack space handling in Node.js is primarily implemented by V8. JavaScript engines developed for browsers have a different security model, and they do not treat crashes like this as security vulnerabilities ([example](https://issues.chromium.org/issues/432385241)). This means similar bugs reported in the upstream will not go through vulnerability disclosure procedures, making any security classification by Node.js alone ineffective.
-
-### uncaughtException Limitations
-
-The `uncaughtException` handler is not designed to recover the process after it fires. The Node.js documentation explicitly warns against this pattern. Specifically, the documentation states that ["Exceptions thrown from within the event handler will not be caught. Instead, the process will exit with a non-zero exit code, and the stack trace will be printed. This is to avoid infinite recursion."](https://nodejs.org/api/process.html#warning-using-uncaughtexception-correctly)
-
-Trying to invoke the handler after the call stack size is exceeded would itself throw. The fact that it works without promise hooks is largely coincidental rather than guaranteed behavior.
-
-## Why This Affects Every APM User
-
-Application Performance Monitoring (APM) tools are essential infrastructure for production applications. They track request latency, identify bottlenecks, trace errors to their source, and alert teams when something goes wrong. Companies use APM tools like Datadog, New Relic, Dynatrace, Elastic APM, and OpenTelemetry to maintain visibility into their distributed systems.
-
-To provide this functionality, APM tools need to follow a request as it flows through your application, even across async boundaries. When an HTTP request comes in, is processed by middleware, queries a database, calls an external API, and finally returns a response, the APM needs to correlate all of these operations into a single trace. This requires async context tracking.
-
-Most modern APM tools use `AsyncLocalStorage` (which is built on `async_hooks` in versions of Node.js before Node 24) to propagate trace context across async operations. The moment you `require(‘dd-trace’)`, `require(‘newrelic’)`, or initialize OpenTelemetry, your application has `async_hooks` enabled.
-
-The irony is notable: the tools you install to monitor and debug crashes can make a category of crashes behave differently. This is not the fault of the APM tools; they are using Node.js APIs exactly as intended.
-
-### Why We Put It In a Security Release
-
-Although it is a bug fix for an unspecified behavior, we chose to include it in the security release because of its widespread impact on the ecosystem.
-React Server Components, Next.js, and virtually every APM tool are affected. The fix improves developer experience and makes error handling more predictable.
-
-However, it's important to note that we were fortunate to be able to fix this particular case. There's no guarantee that similar edge cases involving stack overflow and `async_hooks` can always be addressed. **For mission-critical paths that must defend against infinite recursion or stack overflow from recursion whose depth can be controlled by an attacker, always sanitize the input or impose a limit on the depth of recursion by other means**. The runtime cannot guarantee reliable recovery from stack space exhaustion with a catchable error.
-
-It's worth noting that large array allocations can suffer from similar issues, like the recent [`qs`](https://github.com/ljharb/qs) vulnerability [CVE-2025-15284](https://github.com/ljharb/qs/security/advisories/GHSA-6rw7-vpxm-498p) showed. It's paramount that developers validate and constrain resource usage that could be controlled by an attacker. The runtime cannot always recover reliably from resource exhaustion after-the-fact.
-
 ## The Fix
 
 The fix detects stack overflow errors and re-throws them to user code instead of treating them as fatal:
@@ -361,6 +335,32 @@ After this fix:
 - Applications can handle the error gracefully
 - Behavior is more consistent with and without `async_hooks` enabled
 
+## A Brief History: From async_hooks to AsyncContextFrame
+
+Understanding this bug requires knowing how Node.js evolved its async context tracking.
+
+### The async_hooks Era
+
+[`async_hooks`](https://nodejs.org/api/async_hooks.html) was introduced in [Node.js 8 (2017)](https://nodejs.org/en/blog/release/v8.0.0) as a low-level API to track asynchronous resources. It provides callbacks (`init`, `before`, `after`, `destroy`) that fire at key points in an async resource's lifecycle. APM tools immediately adopted it to trace requests across async boundaries.
+
+However, `async_hooks` has significant performance overhead. Every Promise creation, every timer, and every I/O operation triggers these callbacks. This cost is unavoidable when the hooks are enabled.
+
+### AsyncLocalStorage
+
+[Node.js 12.17.0 (2020)](https://nodejs.org/en/blog/release/v12.17.0) introduced [`AsyncLocalStorage`](https://nodejs.org/api/async_context.html#class-asynclocalstorage), a higher-level API built on top of `async_hooks`. It provides a cleaner interface for the most common use case: storing context that flows through async operations (like request IDs, user sessions, or tracing spans).
+
+React Server Components and Next.js adopted `AsyncLocalStorage` for request context tracking, unknowingly inheriting all of `async_hooks` behaviors, including this bug.
+
+### The AsyncContextFrame Revolution (Node.js 24+)
+
+In [Node.js 24](https://nodejs.org/en/blog/release/v24.0.0), `AsyncLocalStorage` was reimplemented using a new V8 feature called [`AsyncContextFrame`](https://github.com/tc39/proposal-async-context). This approach integrates context tracking directly into V8's Promise implementation, eliminating the need for JavaScript callbacks on every async operation.
+
+The result is dramatically better performance. Importantly for this bug, `AsyncLocalStorage` no longer uses `async_hooks.createHook()` internally. This is why React and Next.js are not affected by this bug on Node.js 24+.
+
+Note: `AsyncLocalStorage` is still exported from the `async_hooks` module for backwards compatibility, even though it no longer uses the `async_hooks` machinery internally on Node.js 24+. It's also available from `node:async_hooks` and the newer `node:async_context` module.
+
+For more details on this evolution and its performance implications, see [The Hidden Cost of Context](https://blog.platformatic.dev/the-hidden-cost-of-context).
+
 ## Affected Versions
 
 **Patched releases available for:**
@@ -394,7 +394,7 @@ The impact on React Server Components and Next.js varies by Node.js version:
 
 ## Mitigation
 
-**Recommended**: Upgrade to the patched versions released on January 8th, 2026.
+**Recommended**: Upgrade to the patched versions released on January 13th, 2026.
 
 If you cannot upgrade immediately, consider altering your application to avoid deep recursion, particularly when allocating promises within recursive functions.
 
@@ -409,15 +409,15 @@ If you cannot upgrade immediately, consider altering your application to avoid d
 - **December 12, 2025**: Anna Henningsen identifies a blocker for this strategy. The Node.js team starts brainstorming on alternative solutions.
 - **December 16, 2025**: Joyee Cheung communicates that Node.js cannot treat this as a vulnerability for the reasons listed in this blog post.
 - **December 17, 2025**: Anna Henningsen fixes the blocking issue for the patch.
-- **January 8, 2026**: Patched versions released and disclosure published
+- **January 13, 2026**: Patched versions released and disclosure published
 
 ## Conclusion
 
 This bug highlights how deeply `async_hooks` has become embedded in the Node.js ecosystem. What started as a low-level debugging API is now a critical dependency for React Server Components, Next.js, every major APM tool, and any code using `AsyncLocalStorage`.
 
 The fix improves the consistency of stack size limit errors caused by deep recursions. While we were able to address this particular case, developers should be aware that stack overflow behavior is not specified by ECMAScript and should not be relied upon for service availability. If the depth of recursion can be controlled by an attacker, always sanitize the input or impose a limit by other means to restrict the depth, instead of counting on the JS runtime to impose a limit or recover from it with a catchable error.
 
-**Users running React RSC, Next.js, or any other framework using `AsyncLocalStorage`, as well as any APM tool in production, should upgrade to the patched versions released on January 8th, 2026.**
+**Users running React RSC, Next.js, or any other framework using `AsyncLocalStorage`, as well as any APM tool in production, should upgrade to the patched versions released on January 13th, 2026.**
 
 ## Acknowledgments