{“lastseen”:”2026-04-09T16:05:09″,”description”:”## **Executive** **Summary**\\n\\nIn this article, we disclose a new high severity unauthenticated remote denial\u2011of\u2011service vulnerability we identified and reported in React Server Components that we\u2019ve dubbed \u201cReact2DoS\u201d. In this blog, we\u2019ll analyze its impact and place it in the broader context of recently found Flight protocol vulnerabilities, especially CVE\u20112026\u201123864.\\n\\n## **Introduction**\\n\\nWe are in a phase of the web where performance and developer experience are no longer trade-offs, they\u2019re expectations. Modern frameworks compete to ship less JavaScript, reduce client-side complexity, and move logic back to the server.\\n\\nReact, as one of the dominant forces in frontend development, has been at the forefront of this evolution. With the introduction of React Server Components (RSC), the ecosystem embraced a new model: components that execute exclusively on the server, access databases and secrets directly, and stream a serialized UI representation to the client.\\n\\nThis architecture promises smaller bundles, cleaner separation of concerns, and more efficient rendering. Instead of hydrating everything on the client, Server Components emit a structured stream that the browser reconstructs locally.\\n\\nAt the heart of this mechanism lies a custom streaming protocol known as _Flight_. Through Flight, React can serialize complex structures, like arrays, maps, object references, even promises and async boundaries, allowing the server to describe rich UI trees in a compact format.\\n\\nThis is powerful.\\n\\nBut history has shown that when we introduce custom serialization formats and complex parsers, we also introduce risk. The server must deserialize and reconstruct object graphs from client-controlled input. And complex parsing logic has long been fertile ground for vulnerabilities.\\n\\nIn our research we discovered a denial-of-service vulnerability that allows an attacker to impose disproportionate computation to the remote server.\\n\\n## **React2Shell and subsequent DoS vulnerabilities**\\n\\nEarlier this year, the disclosure of React2Shell caught much of the community off guard, triggering emergency patches and intense scrutiny of the React Server Components architecture, amplified by waves of low-quality AI-generated analysis that blurred the line between verified facts and speculation. This episode also prompted deeper investigations into and led to new discoveries related to the security of the Flight protocol and related parsing mechanisms.\\n\\nCVE\u20112026\u201123864 (CVSS 3.1 of 7.5), stood out as a notable example and serves as a useful reference for understanding the mechanics behind the issue we explore in this research.\\n\\nAmong other vectors, this vulnerability concerned the BigInt deserialization path in Flight:\\n\\n * $n markers denote BigInt values\\n * No limit was enforced on digit length\\n\\n\\n\\nTherefore, sending a million\u2011digit BigInt could cause a significant computation cost, and CPU exhaustion. An example payload could look like this:\\n \\n \\n 0:\\”$n9999999999…[repeated 1 million times]\\”\\n\\nIn our setup, a single query like this could delay the server\u2019s execution by several seconds if the inbound payload reaches the maximum allowed size (1MB with Node.js runtime, 10MB with Edge runtime).\\n\\nThis was the starting point of our research, and we tried to find payload that would trigger a similar, or superior cost to the server. This is exactly what we found, actually more computationally-intensive by several orders of magnitude.\\n\\n## **React2DoS**\\n\\nReact relies on a mechanism known as the React Flight Protocol to serialize values that are sent to Server Functions.\\n\\nOn the client side, data is transmitted to the server as small pieces (or \u201cchunks\u201d), for example through form submissions:\\n \\n \\n payload = {\\n \u00a0 \\”0\\”: (None, ‘[\\”$1\\”]’),\\n \u00a0 \\”1\\”: (None, ‘{\\”category\\”:\\”vehicle\\”,\\”model\\”:\\”$2:modelName\\”}’),\\n \u00a0 \\”2\\”: (None, ‘{\\”modelName\\”:\\”tesla\\”}’),\\n }\\n\\nAs illustrated above, these chunks can reference one another.\\n\\nAfter deserialization on the server, the reconstructed object looks like this:\\n \\n \\n { \\”category\\”: \\”vehicle\\”, \\”model\\”: \\”tesla\\” }\\n\\nAt first, we tried to measure the cost of execution of every type of reference supported by the Flight protocol. Among them, we looked at two promising ones: $Q and $W, respectively instantiating new Maps and Sets from the client request payload.\\n\\nThe first observation we made was that it was possible to reference the root element in the root element itself (!), which paved the way to recursive expressions:\\n \\n \\n \u201c0\u201d : [\u201c$Q0\u201d]\\n\\nThis, would cause the execution of the following JavaScript expression:\\n \\n \\n New Map([null])\\n\\nWhich makes perfect sense, because at the time of resolution of $Q0, $0 is not known yet.\\n\\nHowever, what surprised us, was the fact that the following expression:\\n \\n \\n \u201c0\u201d : [\u201c$Q0\u201d, \u201c$Q0\u201d …, \u201c$Q0\u201d] (x n)\\n\\ndid trigger the execution of the Map constructor n times!\\n\\nIndeed, the ReactFlightReplyServer uses a `consumed` attribute to prevent multiple computations of the same reference and prevent abuse. But this mechanism only enters in action when the reference is successfully resolved (see Fig 1).\\n\\n_Fig. 1: Exception doesn\u2019t prevent recomputation of the same faulty Map_\\n\\nBecause the `new Map` expression failed (new Map([null]) is not a valid JavaScript expression), this outcome was not stored anywhere. But surprisingly, the deserialization is not interrupted by this exception!\\n\\nThe execution of the expression `new Map ([null])` is pretty cheap, it takes our server around 0.03ms. Virtually instant. But this is neglecting the fact that a threat actor can insert more than 100,000 instances in a 1MB payload, leading to the cost of several seconds, comparable to the CPU exhaustion issue behind CVE\u20112026\u201123864 and described above.\\n\\nConsidering this, we submitted a first report to Meta, sharing this POC and demonstrating the impact.\\n\\nBut soon after, we realized there was a way more impactful payload we could generate by exploiting our original idea. \\n\\nInstead of sending a series of \u201c$Q0\u201d that would immediately trigger the exception, we decided to introduce a series of valid map entries at the start of the root entry, to force the Map constructor to iterate over them before triggering the expected exception (see Fig. 2).\\n\\n_Fig. 2: Internal recursive resolution of \u201c$0\u201d_\\n\\nBy doing so, we achieved a quadratic complexity, and a much more expensive payload ! The optimal number setting is n\/2 valid maps and n\/2 map references to the 0 object (\u201c$Q0\u201d).\\n\\n## **CVE\u20112026\u201123864 (CPU exhaustion) vs React2DoS (CVE-2026-23869)**\\n\\nWith our new attack vector, the computation could easily last several minutes. Therefore, with only small payloads of tens of kilobytes, it was possible to initiate impactful DoS attacks.\\n\\nTo give ourselves an idea of the impact of this attack vector, we computed a chart showing the comparison between CVE\u20112026\u201123864 (CPU exhaustion) and React2DoS. The result showed that after only a few kilobytes, React2DoS starts to stand out, and when the payload size reaches hundreds of kilobytes, it is already more powerful by several orders of magnitude (see Fig. 3).\\n\\n_Fig. 3: Comparison React2DoS \u2013 CVE\u20112026\u201123864_\\n\\nTherefore, with a single request, a threat actor can trigger a computation that will take minutes to handle. By repeating this, complete denial of service can be achieved.\\n\\n## **Mitigation**\\n\\nThe React team fixed this issue via verifying if the consumed flag was set before any map\/set constructor was called.\\n\\nThe issue affects React Server Components version 19.2.4 and below. We recommend that you update to the latest available version that patches this vulnerability as soon as possible. \\n\\nIf your application already sits behind an Imperva proxy, it is automatically protected against this attack.\\n\\n## **Conclusion**\\n\\nThis case highlights an important reality: the path to innovation inevitably introduces complexity, and therefore risk. As ecosystems evolve rapidly, staying up to date and remaining aware of newly discovered security issues is essential.\\n\\nIn a more personal way, it was a pleasure for me to delve into one of the most used framework in the world and discover a finding with meaningful impact. This wouldn\u2019t have been possible if researchers before didn\u2019t pave the way with their investigations and their recent findings (React2Shell, CVE\u20112026\u201123864\u2026). \\n\\n## **Disclosure Timeline**\\n\\nFeb 3 2026 \u2013 Report including first payload\\n\\nFeb 5 2026 \u2013 Second payload reported\\n\\nApril 8 2029 \u2013 Vulnerability fixed in 19.2.5\\n\\nThe post React2DoS (CVE-2026-23869): When the Flight Protocol Crashes at Takeoff appeared first on Blog.”,”published”:”2026-04-09T14:54:18″,”modified”:”2026-04-09T14:54:18″,”type”:”impervablog”,”title”:”React2DoS (CVE-2026-23869): When the Flight Protocol Crashes at Takeoff”,”source”:””,”references”:””,”id”:”IMPERVABLOG:65488FEC341E6508F2F86CE009BF580C”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[“CVE-2026-23864″,”CVE-2026-23869″],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:7.5,”severity”:”HIGH”,”vector”:”CVSS:3.1\/AV:N\/AC:L\/PR:N\/UI:N\/S:U\/C:N\/I:N\/A:H”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.imperva.com\/blog\/react2dos-cve-2026-23869-when-the-flight-protocol-crashes-at-takeoff\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-04-09T16:05:09″,”description”:”## **Executive** **Summary**\\n\\nIn this article, we disclose a new high severity unauthenticated remote denial\u2011of\u2011service vulnerability we identified and reported in React Server Components that we\u2019ve…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,16,12,15,59,13,7,11,5],"class_list":["post-42748","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-cvss-75","tag-exploit","tag-high","tag-impervablog","tag-news","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n