editorially independent. We may make money when you click on links
to our partners.
Learn More
A newly released analysis from the Shadowserver Foundation shows that more than 644,000 domains are exposed to a critical vulnerability in React Server Components..
The flaw affects over 165,000 IP addresses, according to updated scanning data.
Attackers are leveraging the vulnerability “… to gain interactive, cloud-aware access to containerized workloads, aggressively harvest secrets, weaken local defenses, and monetize access through cryptomining and backdoor deployment,” said Wiz researchers.
Understanding the React Deserialization Flaw
CVE-2025-55182 stems from improper input deserialization in React Server Components (RSC).
By crafting a malicious RSC payload, attackers can abuse the server-side decoding logic to trigger a chain of gadgets that ultimately leads to remote code execution (RCE) on the server.
Because RSC sits in the request/response pipeline, successful exploitation can bypass authorization controls, execute arbitrary code, and jeopardize both server integrity and application data.
Although early analysis focused heavily on Next.js, Wiz Security’s research shows the issue is broader, affecting other platforms that implement RSC — such as Waku, Vite with RSC plugins, and custom native React servers that call the vulnerable decodeReply logic
In Next.js specifically, the RSC flow is exposed by default via the next-action header, making exploitation straightforward for any internet-facing app. In custom or less common frameworks, attackers need only identify the RSC endpoint to reach the same vulnerable code path.
Wiz has already observed active exploitation, with attackers using the bug to gain interactive shells in cloud containers, harvest environment variables and secrets, query metadata services, and exfiltrate credentials for AWS, Git, SSH, and other developer tools.
Some campaigns deploy cryptominers into Kubernetes or other cloud workloads, while others go further by installing Sliver backdoors for persistent command-and-control.
The combination of critical severity, internet-scale exposure, and confirmed in-the-wild abuse makes CVE-2025-55182 a high-priority issue.
Organizations using React Server Components — whether via Next.js, alternative frameworks, or custom implementations — should assume elevated risk until vulnerable packages are upgraded and deployments are fully validated.
How to Mitigate the React Server Components Vulnerability
Organizations can reduce risk from CVE-2025-55182 by combining immediate patching with stronger application and operational controls.
- Apply the official React patches and ensure CI/CD pipelines do not redeploy vulnerable versions.
- Inventory all applications using React Server Components and scan codebases and lockfiles for affected React packages.
- Monitor logs and telemetry for anomalous rendering behavior, unexpected server-side execution, or signs of prior exploitation.
- Implement temporary hardening measures such as tightened WAF rules, restricted sensitive endpoints, and enhanced logging around RSC operations.
- Enforce stricter runtime and container controls by limiting filesystem access, restricting shell utilities, and applying outbound egress filtering.
- Segment application tiers and limit lateral movement while restricting or gating the next-action RSC flow where possible.
- Educate development teams about the vulnerability, align patching across all environments, and rotate any secrets that may have been exposed during potential exploitation.
These measures support a more secure and consistent deployment environment.
This incident underscores a broader trend: vulnerabilities buried deep within modern web frameworks can lead to internet-scale exposure long before organizations realize they are at risk.
As server-side rendering, distributed components, and automated build pipelines become standard, a single architectural flaw can propagate across hundreds of thousands of deployments.
This growing complexity is one reason why many organizations are turning to zero-trust principles to reduce the impact of similar framework-level risks.
