- A researcher reports that one crafted request can freeze a server running an unpatched React 19.0 to 19.2 release when a server action is reachable. Public pages need no login.
- The slow code runs before any security check, so login and token defenses do not see the request. React fixed it in 19.0.6, 19.1.7 and 19.2.6.
- Check which React version each server runs, which apps expose server actions, and whether health checks could pull a stalled server out of service.
Most security thinking asks who is allowed in. This flaw asks a different question: what does the server do before it asks? A researcher writing at simonkoeck.com reports that React spends heavy effort rebuilding a request before any login, token or origin check runs. The lesson here is that a guard at the door cannot protect you from work done in the lobby.
What the researcher found
React lets a form call a function on the server. These are called server actions. Before the function runs, React must rebuild the form data from the raw web request. The researcher published a writeup on October 8, 2026, showing that this rebuilding step can be made to do a huge amount of work.
Patched builds exist for each affected line: 19.0.6, 19.1.7 and 19.2.6. Any earlier release in the 19.0, 19.1 or 19.2 lines is exposed, and the affected code ships in three published packages. Meta shipped the upstream patch as CVE-2026-23870. The React advisory is GHSA-rv78-f8rc-xrxh.
How one request becomes millions of checks
React's form format lets one field point at another. One pointer type, written $K, means a nested form lives here. To resolve each $K, React walks the whole list of fields in the request. One pointer costs one full pass.
Nothing caps how many pointers or fields a request holds. The sender chooses both. Now take a request with 10,000 of each: pointers and padding fields. Every pointer triggers a fresh scan of all the fields. The researcher counts the total at 100 million string checks, run back to back.
Node.js handles incoming requests on a single thread. While that thread grinds through the checks, it serves no one else. Every other visitor waits.
React has two size limits nearby. The researcher says neither applies. One limits how deeply arrays nest. The other limits how many arguments an action takes. Burying the pointers one level deeper than the check looks gets past both.
Why login and tokens do not help
The rebuilding happens before any security check. Login, CSRF token and origin checks do not see the request until the work is done. To aim the attack, a stranger needs only the identifier of one server function. The researcher says apps expose it in page HTML and in the JavaScript files browsers download.
On a public page, no account is needed. Behind a login, any ordinary account works. The request is about 900 KB.
In the researcher's tests, one request froze a plain production build on a laptop for about 4 seconds. Five in a row gave about 20 seconds of downtime. A production-shaped setup was worse, at around 10 seconds per request.
The researcher reports that the load balancer in front of that server marked it unhealthy after three of these requests in a row. It pulled the server from service and began returning 503 errors to visitors who had nothing to do with the test. In that setup, unrelated visitors saw outages. Your own health checks may behave differently, and that is worth finding out before someone else does.
Who is exposed
The researcher says the code sits in a part of React shared across setups, so it is not tied to one framework. His practical summary: nearly any Next.js 14+ app, or other React Server Components setup, is affected if it runs an unpatched 19.0 to 19.2 release and a server action can be reached. One action that merely logs a form field is enough.
WebPulse cannot see React versions from outside, so it cannot say how many sites are unpatched. It can show how common the framework is. Next.js was detected on 791 of the 2,491 sites where a platform was identified in a September 2026 scan of the Tranco top 10,000 domains.
A disclosure still in dispute
The researcher gives his own account of the process. He says the patch landed upstream on May 6, 2026, and he learned of it by watching the code change. His bug bounty report still reads "New", and he is not credited in the advisory. He says he checked in twice and held off publishing.
He also says he received no reply beyond an automated acknowledgement. WebPulse has not independently confirmed this.
What to ask your team
First, which React version does each production server run? The answer must be an exact version, not "recent". Check it against the three fixed releases named above.
Second, do you know which apps expose server actions, including on public pages? Third, what do your health checks do when a server stalls? If a few slow requests can pull a node from rotation, the outage can reach users who never sent them.
Finally, a question with no settled answer. The researcher's request is only about 900 KB, so ask whether any size limits you run would even catch it. The only fix he describes is patching. A check that runs after the expensive work cannot help against an attack that works by being expensive.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: simonkoeck.com.
