Half of exposed React servers remain unpatched amid active exploitation
- Reference: 1765539069
- News link: https://www.theregister.co.uk/2025/12/12/vulnerable_react_instances_unpatched/
- Source link:
That's the assessment from Alon Schindel, VP of AI and Threat Research at Wiz, who [1]says CVE-2025-55182 – the React server-side vulnerability dubbed "React2Shell" – is now being actively exploited at scale, with researchers tracking at least 15 distinct intrusion clusters in the wild over the past 24 hours alone.
According to Wiz's latest telemetry, roughly 50 percent of publicly exposed resources known to be vulnerable are still running unpatched code, giving attackers a comfortable head start.
[2]
The critical-severity flaw, first disclosed earlier this month, affects React Server Components and dependent frameworks such as [3]Next.js and stems from unsafe deserialization in React's server-side packages, allowing an unauthenticated attacker to send a crafted request to achieve remote code execution. As The Register previously reported, [4]the bug quickly proved attractive to attackers because of React's ubiquity in modern web stacks, particularly in cloud-hosted environments where a single exposed endpoint can provide a foothold into far larger estates.
[5]
[6]
What began as opportunistic scanning and cryptomining has now broadened into something messier. Wiz says it is seeing a clear split between "commodity" exploitation – dominated by familiar cryptomining operations using tools like Kinsing, C3Pool, and custom loaders – and more deliberate intrusion sets deploying post-exploitation frameworks and bespoke malware.
Among the clusters observed are Python-based campaigns masquerading as miner droppers while quietly exfiltrating secrets, Sliver command-and-control infrastructure used for hands-on-keyboard operations, and a JavaScript file injector that systematically infects every server-side *.js file it can reach. Wiz also reports the re-emergence of EtherRat backdoor variants, a family of malware that had previously fallen out of favor but appears to have been dusted off for this wave of exploitation.
[7]
The technical sophistication is also creeping upward. Multiple miscreants are actively attempting to frustrate incident response by manipulating timestamps, minimizing logs, and otherwise scrubbing evidence of compromise. Those anti-forensics techniques, Wiz warned, suggest operators who expect to be hunted and intend to linger.
[8]Cloudflare blames Friday outage on borked fix for React2shell vuln
[9]Beijing-linked hackers are hammering max-severity React bug, AWS warns
[10]'Exploitation is imminent' as 39 percent of cloud environs have max-severity React hole
[11]Meta will move React to Linux Foundation to address vendor dominance fears
Other security firms are now corroborating that assessment. Palo Alto Networks' Unit 42 team has [12]linked the exploitation of CVE-2025-55182 to North Korean and Chinese threat groups. They stopped short of pinning it on any single baddie, but said the tooling and reused infrastructure look more like long-term intrusion work than smash-and-grab cryptomining.
"Unit 42 has identified activity that reportedly shares overlap with North Korean (DPRK) Contagious Interview tooling, though no formal attribution has occurred at this time. Contagious Interview is a campaign where threat actors associated with the DPRK pose as recruiters to install malware on the devices of job seekers in the tech industry," Unit 42 said. "Additionally, we've observed instances of the Linux backdoor BPFDoor. This is a Linux implant attributed to Chinese-linked threat actor Red Menshen."
React's dominance means vulnerable code isn't confined to obscure hobby projects, but sits inside production systems at startups, enterprises, and cloud-heavy organizations alike. Many of those deployments are internet-facing by design, and patching is not always straightforward.
As with so many modern web vulnerabilities, the danger is not just the bug itself but how quickly it becomes industrialized. React2Shell has already crossed that line, and with half the vulnerable surface still exposed, attackers have little incentive to move on just yet. ®
Get our [13]Tech Resources
[1] https://www.linkedin.com/posts/activity-7404544875360108544---cY/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAC2xvMBLPggh7Z3PC8i4V4yQ0JB56a2MlM
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aTxKKHTX7jwD_MtPnvYgSgAAAIs&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] http://next.js
[4] https://www.theregister.com/2025/12/05/aws_beijing_react_bug/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aTxKKHTX7jwD_MtPnvYgSgAAAIs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aTxKKHTX7jwD_MtPnvYgSgAAAIs&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aTxKKHTX7jwD_MtPnvYgSgAAAIs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2025/12/05/react2shell_pocs_exploitation/
[9] https://www.theregister.com/2025/12/05/aws_beijing_react_bug/
[10] https://www.theregister.com/2025/12/03/exploitation_is_imminent_react_vulnerability/
[11] https://www.theregister.com/2025/10/09/meta_react_foundation/
[12] https://unit42.paloaltonetworks.com/cve-2025-55182-react-and-cve-2025-66478-next/
[13] https://whitepapers.theregister.com/
Re: The web stack - let's see . . .
"Worse is better". It always wins, as its just simpler to learn the ropes by cobbling something up in your browser than installing a runtime for a properly designed language.
People often say that the web would have looked much better if Netscape had stuck with their original plan (Scheme or Lua, I dont recall, some decent language instead something homebrew that got pushed put too quickly) but no, someone would have implemented something sloppy on top and everybody would have pivoted to that.
In the absence of software engineering with quality and safety standards, the easiest solution will keep winning.
Re: The web stack - let's see . . .
Much as I dislike Javascript, Crockford is a _very_ outdated view of it at this point. ES6 fundamentally resolved the vast majority of issues by providing much better lambdas, classes and variable scoping. You _can_ write things the wrong way still if you're really determined, but you shouldn't - the features are only there because you don't want to just go round breaking backward compatibility on 20 years of old websites. Add in Typescript and you've got a reasonably solid framework for writing code, which is nicer than various of the other scripting languages.
While I can see an argument for pulling in "properly engineered" languages, applets written in Java 1.0-1.5 really weren't that. Java was itself a relatively immature language, and coding Swing was an almost infinitely worse experience than using JS and the DHTML APIs of the time. Whilst Java is a lot better now, and the JDK is a really nice platform, the advent of Webassembly has really delivered everything Applets could have done, but with a wider selection of source languages and better integration into the web platform.
Agree entirely on the Javascript dependencies problem though, and the wild obsession with pulling in massive frameworks to do something which could be achieved in 5 lines of code.
Re: The web stack - let's see . . .
>> Crockford is a _very_ outdated view of it at this point.
Crockford is 100% right on one aspect: 'Most of the people writing in JavaScript are not programmers. They lack the training and discipline to write good programs.' This is true for other languages too, of course. But there's heaps of bad JavaScript out there. And PHP.
The web stack - let's see . . .
Javascript, a mongrel of functional and OO approaches, looking deceptively simple although fundamentally toxic (see Crockford). Heaps of petty & not-so trivial ependencies pulled in en masse from unknown sources are considered normal.
CSS- declarative and impenetrable (except to experts).
HTML- a mess, parsers cursed by decades of "lenient" programming, a "casserole of nonsense".
And now we are unleashing the random element of Jive Talkin' & a1 to the development process.
And applets running a properly engineered language in a controlled environment were somehow considered a bad idea at the time?
Human beings make strange decisions.