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

Co-authored-by: Joyee Cheung <[email protected]>
Signed-off-by: Matteo Collina <[email protected]>

Author: mcollina

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

@@ -298,7 +298,7 @@ While this issue has significant practical impact, we want to be clear about why
 
 ### Stack Space Exhaustion Is Not Specified Behavior
 
-The "Maximum call stack size exceeded" error is not part of the ECMAScript specification. The specification assumes infinite stack space; 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.
+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.