The attack landscape has been dynamic following the disclosure of the React Server Components RCE vulnerability. New information has emerged regarding the initial Proof-of-Concept exploit, as well as improved detection methods, exploitation mechanics observed in the wild, and rapidly growing attack activity. This update summarizes the changes and observations we have made across Wallarm customers.

The First PoC Exploit Was Not Real

Soon after the vulnerability was disclosed, an early PoC began circulating on GitHub. It was later confirmed that this PoC was not a real exploit for CVE-2025-55182. Instead, it represented an inaccurate research attempt that unintentionally simulated a vulnerable server by manually registering dangerous modules such as fs, child_process, and vm, something real-world RSC applications would never do.

Even after it was publicly clarified that the PoC was invalid, exploitation attempts using this PoC format continued to grow, and Wallarm observed widespread automated attacks based on this template through both December 3 and December 4.

Because many attackers simply reuse or automate anything labeled “PoC,” incorrect or oversimplified repositories can still fuel large waves of malicious traffic.

Utilities for Scanning Vulnerable Deployments Emerge

On December 4, Assetnote Security researchers published a detailed technical breakdown of the vulnerability and introduced a Python utility to detect vulnerable RSC and Next.js deployments

This release of the utility significantly improved the ability to identify vulnerable packages and server configurations, for both the practitioner community and attackers.

As with the earlier PoC publication, the release of these scanning utilities triggered a surge in attack activity. Within the first hours, Wallarm recorded more than 5,500 new exploitation attempts, many of which directly mirrored the structure of the scanning tool.

The scanning method was rapidly adapted into:

• standalone community scanners
• Nuclei templates
• custom scripts forked from the Assetnote code

These variations quickly became widespread and were heavily used on December 4 and December 5, in many cases surpassing the volume of real exploitation attempts, as shown in the chart later in this blog post.

First Real RCE Exploits for CVE-2025-55182

While the initial PoC was invalid, the actual RCE exploit chain for CVE-2025-55182 later became available. It is based on abusing unsafe export resolution inside the RSC action deserialization process.

The payload exploits how React Server Components deserialize and resolve metadata fields, allowing an attacker to traverse the JavaScript prototype chain and ultimately execute arbitrary code on the server. Each field in the payload contributes to shaping the object so it is both accepted by the RSC runtime and capable of triggering the evaluator. The core components are:

• then: "$1:__proto__:then" — Establishes a self-referential thenable structure that forces the deserializer to walk the __proto__ chain, exposing inherited properties rather than restricting resolution to safe action references.
• status: "resolved_model" — Marks the object as a valid React Server Component model chunk so that it is processed without being rejected by structural validation.
• reason: -1 — Manipulates internal reference handling by causing the root reference to resolve in a way that avoids conflicts during deserialization.
• value: "{\"then\":\"$B1337\"}" — Embeds a nested payload crafted to invoke the $Bhandler, which influences how model data is interpreted and allows further control over the deserialization flow.
• _response._prefix — Contains the actual remote-code-execution snippet. In this example, the injected code uses process.mainModule.require('https') to issue an outbound request to an attacker-controlled domain, serving as an out-of-band confirmation of successful code execution.
• _response._chunks: "$Q2" — Provides an empty chunk map, preventing deserialization errors and ensuring the payload is treated as structurally valid.
• _response._formData.get: "$1:constructor:constructor" — Redirects the get accessor to the Function constructor by traversing the prototype chain (constructor → constructor). This is the critical step that converts the attacker-supplied string in _prefix into executable JavaScript.

Together, these elements exploit gaps in the RSC model-resolution pipeline, enabling an attacker to transform harmless metadata into a fully executed JavaScript payload within the Node.js runtime. The result is a reliable, in-memory RCE primitive that does not require writing files to disk and persists only until the process is restarted.

Data Exfiltration Techniques

As exploitation techniques matured, payloads evolved to return command results through multiple channels. Below are the three primary methods, along with the technical mechanisms behind them.

Response Body Output

The payload embeds the command output directly into the serialized RSC digest field, for example:

{ digest: \${res}` }`

When deserialized, the server sends the command result back in the HTTP response body. This provides direct, interactive output with minimal payload complexity.

Some variants inject the command output into an error object used by Next.js internal redirects:

Object.assign(new Error("NEXT_REDIRECT"), { digest: \NEXT_REDIRECT;push;/login?a=${res}` })`

Because the framework reflects the digest value into specific HTTP headers, this allows exfiltration even when the body is overwritten or sanitized.

OAST / DNSLog Callback

For fully out-of-band exfiltration, the payload uses Node internals to read and transmit data:

• process.mainModule.require('fs') → reads files or command output
• process.mainModule.require('https') → sends the data to an attacker-controlled OAST/DNSLog endpoint

Runtime Memory Shell

Another interesting technique was published, demonstrating how attackers can exploit RSC deserialization flaws to create an in-memory webshell by abusing JavaScript prototype behavior. The method enables arbitrary code execution without writing anything to disk, making it both stealthy and effective.

How the technique works:

• Uses crafted RSC metadata to reach prototype-chain properties such as __proto__ and constructor.constructor.
• This escalates access to powerful JavaScript constructors capable of executing arbitrary code.
• Injected script imports core Node.js modules (http, url, child_process) to gain deeper control.
• Overrides http.Server.prototype.emit to intercept all incoming HTTP requests.
• Adds a hidden endpoint like /exec?cmd=<command>that executes commands using child_process.execSync.
• Results in an in-memory webshell that persists until the server process restarts and leaves no on-disk traces.

Wallarm Observations & Exploitation Statistics

Wallarm continues to monitor exploitation activity across customer environments. Key observations include:

• Invalid PoC traffic: Despite being debunked, usage of the incorrect PoC format doubled on December 4 compared to December 3 and continued into December 5.
• Scanner-derived attacks: After Assetnote released their scanning utility, the community quickly adapted it, resulting in ~5,500 attacks within the first few hours, with scanning traffic on December 4–5 exceeding real exploitation attempts.
• Real RCE payloads: Once accurate technical details became public, genuine RCE exploits began appearing, including hybrids that combined scanner logic with exploitation patterns (all of which Wallarm successfully detects and blocks using existing and updated RSC-specific protections).

Exploitation Attempts Using WAF/WAAP Bypass Techniques

While most exploitation attempts simply mirrored the original PoC format, Wallarm also observed a number of more advanced attempts aimed at bypassing security controls. Examples include:

• Padding payloads with large irrelevant data to evade WAF/WAAP products that inspect only the first portion of a request or struggle with oversized payloads.
• Small structural mutations, such as changing ["$1:a:a"]to ["$1:aa:aa"], which can bypass WAFs relying on static signatures.
• Adding binary data to the multipart request. In the following exploitation request, the attacker inserted high-entropy binary data into the first segment of the multipart body. This technique takes advantage of the fact that many WAF/WAAP solutions reduce or skip inspection of binary payloads to avoid false positives, thereby allowing malicious content that follows to bypass deeper analysis.

These variations highlight that attackers are already experimenting with evasion strategies, reinforcing the need for behavior-based detection rather than simple signature matching.

Wallarm Resistance to Obfuscation Techniques

Wallarm’s WAAP is resistant to all of these evasion methods. Its stamp-based attack detection surpasses static signature matching and avoids the performance issues of regex-based approaches, allowing rapid inspection of large or obfuscated payloads with low latency.

Wallarm’s proprietary stamp-based detection is more flexible than simple static string matching, enabling the system to recognize exploit patterns even when attackers modify or rearrange payloads. Stamps also operate significantly faster than traditional regular expressions, especially when many rules must be evaluated concurrently. While many WAFs struggle (or simply fail) to inspect large requests, with some unable to process payloads exceeding 64 KB or even 8 KB, Wallarm is designed to handle large and highly obfuscated inputs efficiently, maintaining minimal latency under heavy load.

Additionally, Wallarm performs deep, recursive parsing of all incoming requests, ensuring that every component is analyzed, regardless of its structure or encoding. Detection accuracy remains high because stamp-based logic is applied within every parameter and nested element.

Wallarm is also highly resistant to common WAF bypass techniques. Multiple encodings and obfuscation layers are automatically normalized and decoded before inspection, preventing attackers from concealing malicious payloads through transformation tricks.

Finally, Wallarm provides comprehensive coverage across multiple API protocols (including REST, GraphQL, SOAP, gRPC, and WebSockets) and inspects all request parameters, such as URI, headers, body, multipart segments, and even JWTs, ensuring consistent protection regardless of where a payload is introduced.

Wallarm Detection Capabilities

Despite detecting and blocking exploitation attempts at the traffic level, Wallarm also uses additional approaches to reveal both vulnerable instances and evidence of exploitation:

• Attack Surface Management (AASM): Uses an active scanning approach to identify vulnerable technologies on Internet-facing hosts, including those not protected by Wallarm filtering.
• Passive Detection System: Passively analyzes application traffic to detect indicators of successful exploitation attempts, helping uncover incidents that may otherwise go unnoticed.