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

@@ -327,7 +327,7 @@ The irony is notable: the tools you install to monitor and debug crashes can mak
 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.
+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.