惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

The Cloudflare Blog
小众软件
小众软件
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
T
Tailwind CSS Blog
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
博客园 - 司徒正美
V
Visual Studio Blog
G
Google Developers Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
月光博客
月光博客
aimingoo的专栏
aimingoo的专栏
博客园_首页
Blog — PlanetScale
Blog — PlanetScale
博客园 - 聂微东
S
SegmentFault 最新的问题
T
The Blog of Author Tim Ferriss
D
Docker
Vercel News
Vercel News
Recent Announcements
Recent Announcements
Last Week in AI
Last Week in AI
爱范儿
爱范儿
J
Java Code Geeks
大猫的无限游戏
大猫的无限游戏

Node.js Blog

Node.js — Security Bug Bounty Program Paused Due to Loss of Funding Node.js — Node.js 25.9.0 (Current) Node.js — Developing a minimally HashDoS resistant, yet quickly reversible integer hash for V8 Node.js — Node.js 25.8.2 (Current) Node.js — Node.js 24.14.1 (LTS) Node.js — Node.js 22.22.2 (LTS) Node.js — Node.js 20.20.2 (LTS) Node.js — Tuesday, March 24, 2026 Security Releases Node.js — Node.js 25.8.1 (Current) Node.js — Evolving the Node.js Release Schedule Node.js — Node.js 22.22.1 (LTS) Node.js — Node.js 20.20.1 (LTS) Node.js — Node.js 25.8.0 (Current) Node.js — Node.js 25.7.0 (Current) Node.js — Node.js 24.14.0 (LTS) Node.js — New HackerOne Signal Requirement for Vulnerability Reports Node.js — Node.js 25.6.1 (Current) Node.js — Node.js 24.13.1 (LTS) Node.js — Node.js 25.6.0 (Current) Node.js — OpenSSL Security Advisory Assessment, January 2026 Node.js — Node.js 25.5.0 (Current) Node.js — Chalk to Node.js util styleText Node.js — Node.js 25.4.0 (Current) Node.js — Mitigating Denial-of-Service Vulnerability from Unrecoverable Stack Space Exhaustion for React, Next.js, and APM Users Node.js — Node.js 22.22.0 (LTS) Node.js — Node.js 25.3.0 (Current) Node.js — Node.js 24.13.0 (LTS) Node.js — Node.js 20.20.0 (LTS) Node.js — Tuesday, January 13, 2026 Security Releases Node.js — Node.js 24.12.0 (LTS)
Node.js — V8 Memory Corruption and Stack Overflow (fixed ...
2014-07-31 · via Node.js Blog

The Node.js Project

A memory corruption vulnerability, which results in a denial-of-service, was identified in the versions of V8 that ship with Node.js 0.8 and 0.10. In certain circumstances, a particularly deep recursive workload that may trigger a GC and receive an interrupt may overflow the stack and result in a segmentation fault. For instance, if your work load involves successive JSON.parse calls and the parsed objects are significantly deep, you may experience the process aborting while parsing.

This issue was identified by Tom Steele of ^Lift Security and Fedor Indunty, Node.js Core Team member worked closely with the V8 team to find our resolution.

The V8 issue is described here https://codereview.chromium.org/339883002

It has landed in the Node repository here: https://github.com/joyent/node/commit/530af9cb8e700e7596b3ec812bad123c9fa06356

And has been released in the following versions:

The Fix

The backport of the fix for Node.js is

diff --git a/deps/v8/src/isolate.h b/deps/v8/src/isolate.h
index b90191d..2769ca7 100644
--- a/deps/v8/src/isolate.h
+++ b/deps/v8/src/isolate.h
@@ -1392,14 +1392,9 @@ class StackLimitCheck BASE_EMBEDDED {
  public:
   explicit StackLimitCheck(Isolate* isolate) : isolate_(isolate) { }

-  bool HasOverflowed() const {
+  inline bool HasOverflowed() const {
     StackGuard* stack_guard = isolate_->stack_guard();
-    // Stack has overflowed in C++ code only if stack pointer exceeds the C++
-    // stack guard and the limits are not set to interrupt values.
-    // TODO(214): Stack overflows are ignored if a interrupt is pending. This
-    // code should probably always use the initial C++ limit.
-    return (reinterpret_cast<uintptr_t>(this) < stack_guard->climit()) &&
-           stack_guard->IsStackOverflow();
+    return reinterpret_cast<uintptr_t>(this) < stack_guard->real_climit();
   }
  private:
   Isolate* isolate_;

Remediation

The best course of action is to patch or upgrade Node.js.

Mitigation

To mitigate against deep JSON parsing you can limit the size of the string you parse against, or ban clients who trigger a RangeError for parsing JSON.

There is no specific maximum size of a JSON string, though keeping the max to the size of your known message bodies is suggested. If your message bodies cannot be over 20K, there's no reason to accept 1MB bodies.

For web frameworks that do automatic JSON parsing, you may need to configure the routes that accept JSON payloads to have a maximum body size.