14 ms·
RCE Vulnerability in React and Next.js
- AgentK20 10mo agoCVE 10.0 is bonkers for a project this widely used
- rs_rs_rs_rs_rs 10mo agoReact is widely used, react server components not so much.
- _jab 10mo agoNext.js is still pretty damn widely used.
- nine_k 10mo agoThe packages affected, like [1], literally say: > Experimental React Flight bindings for DOM using Webpack. > Use it at your own risk. 311,955 weekly downloads though :-| [1]: https://www.npmjs.com/package/react-server-dom-webpack https://www.npmjs.com/package/react-server-dom-webpack
- ascorbic 10mo agoThat number is misleadingly low, because it doesn't include Next.js which bundles the dependency. Almost all usage in the wild will be Next.js, plus a few using the experimental React Router support.
- root_axis 10mo agoAs far as I'm aware, transitive dependencies are counted in this number. So when you npm install next.js, the download count for everything in its dependency tree gets incremented. Beyond that, I think there is good reason to believe that the number is inflated due to automated downloads from things like CI pipelines, where hundreds or thousands of downloads might only represent a single instance in the wild.
- korm 10mo agoIt's not a transitive dependency, it's just literally bundled into nextjs, I'm guessing to avoid issues with fragile builds.
- swyx 10mo agowhy is it not normal for CI pipelines to cache these things? its a huge waste of compute and network.
- FINDarkside 10mo agoIt's certainly not uncommon to cache deps in CI. But at least at some point CircleCI was so slow at saving+restoring cache that it was actually faster to just download all the deps. Generally speaking for small/medium projects installing all deps is very fast and bandwidth is basically free, so it's natural many projects don't cache any of it.
- odie5533 10mo agoThese often do get cached at CDNs inside of the consuming data centers. Even the ISP will cache these kind of things too.
- j45 10mo agoThe subjects of theses types of posts should report the CVSS severity as 10.0 so the PR speak can't simply deflect to what needs to be done.
- WatchDog 10mo agoA CVSS score of 10.0 may be warranted in this case, but so many other CVSS scores are wildly inflated, that the scores don't mean a lot.
- j45 10mo agoRegardless it can still provide some context and adjustment cs none. The above could be seen as spin too, how could cvss be more accurate so you’d feel better?
- jeroenhd 10mo agoUnfortunately, CVSS scores are gamified hard. Companies pay more money in bug bounty programs, so there's an incentive for bug bounty hunters to talk up the impact of their discovery. Especially the CVSS v3 calculation can produce some unexpected super high or super low scores. While scores are a good way to bring this stuff to people's attention, I wouldn't use them to enforce business processes. There's a good chance your code isn't even affected by this CVE even if your security scanners all go full red alert on this bug.
- j45 10mo agoIt’s possible to create a scoring system based on actual root cause analysis and impact scores. Surprised there isn’t more talk about a solution like this or something and more downplaying CVSS. Downplaying CVSS alone can smell a little like PR talk even however unintentional.
- bitbasher 10mo agoIt's almost like trying to magically wire up your frontend to the backend through magical functions is a bad idea.
- baiwl 10mo ago[flagged]
- dizlexic 10mo agoikr, no way this could have been predicted and warned about for months and months before now.
- beders 10mo agoOne could get the impression that the only really really important non-functional requirement for such a thing is to absolutely ensure that you can only call the "good" functions with the "good" payload.
- bossyTeacher 10mo agoCV driven development needs new ideas for resume padding regardless of whether the idea is good or bad. Then you get this
- division_by_0 10mo agoThis reminds me of the recent SvelteKit Remote Functions GH discussion: > Even in systems that prevent server functions from being declared in client code (such as "use server" in React Server Components), experienced developers can be caught out. We prefer a design that emphasises the public nature of remote functions rather than the fact that they run on the server, and avoids any confusion around lexical scope. [0] [0] https://github.com/sveltejs/kit/discussions/13897 https://github.com/sveltejs/kit/discussions/13897
- ajross 10mo agoThe CVE says the that flaw is in React Server Components, which implies strongly that this is a RCE on the backend (!!), not the client.
- padjo 10mo agoWhere else would it be? What would an RCE of the client even mean?
- cyptus 10mo agoit would be an RCE on your own machine :D
- deleted 10mo ago[deleted]
- ajross 10mo agoThe term is always ambiguous. But react is generally understood as a client library and client-side vulnerabilities are hardly a new thing. XSS exists as a whole subfield of study precisely because of the difficulty of keeping site code from getting fooled by malicious input. Basically you're technically correct with your quip, but engaging in some pretty awful security analysis. IMHO most people reading this headline are not going to understand that they need to audit their server dependencies.
- dfedbeef 10mo agoLCE
- IceDane 10mo agoBravo.
- heisenbit 10mo agoI suspect client developers are also affected at least to the extent that they need to explain this RCE to CVE driven management.
- phelm 10mo agoMore detail in the React Blog post here https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components https://react.dev/blog/2025/12/03/critical-security-vulnerab...
- embedding-shape 10mo agoFrom Facebook/Meta: https://www.facebook.com/security/advisories/cve-2025-55182 https://www.facebook.com/security/advisories/cve-2025-55182 > A pre-authentication remote code execution vulnerability exists in React Server Components versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 including the following packages: react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack. The vulnerable code unsafely deserializes payloads from HTTP requests to Server Function endpoints. React's own words: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components https://react.dev/blog/2025/12/03/critical-security-vulnerab... > React Server Functions allow a client to call a function on a server. React provides integration points and tools that frameworks and bundlers use to help React code run on both the client and the server. React translates requests on the client into HTTP requests which are forwarded to a server. On the server, React translates the HTTP request into a function call and returns the needed data to the client. > An unauthenticated attacker could craft a malicious HTTP request to any Server Function endpoint that, when deserialized by React, achieves remote code execution on the server. Further details of the vulnerability will be provided after the rollout of the fix is complete.
- filearts 10mo agoGiven that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving the that is __proto__.
- mirashii 10mo agoThis comment from a dupe thread is worth considering: https://news.ycombinator.com/item?id=46137352 https://news.ycombinator.com/item?id=46137352
- harrall 10mo agoI see this type of vulnerability all the time. Seen it in Java, Lua, JavaScript, Python and so on. I think deserialization that relying on blacklists of properties is a dangerous game. I think rolling your own object deserialization in a library that isn’t fully dedicated to deserialization is about as dangerous as writing your own encryption code.
- nickthegreek 10mo agodupe: https://news.ycombinator.com/item?id=46136067 https://news.ycombinator.com/item?id=46136067
- anonymars 10mo ago[flagged]
- benmmurphy 10mo agoI suspect the commit to fix is: https://github.com/facebook/react/commit/bbed0b0ee64b89353a40d6313037bbc80221bc3d https://github.com/facebook/react/commit/bbed0b0ee64b89353a4... and it looks like its been squashed with some other stuff to hide it or maybe there are other problems as well. this pattern appears 4 times and looks like it is reducing the functions that are exposed to the 'whitelist'. i presume the modules have dangerous functions in the prototype chain and clients were able to invoke them. - return moduleExports[metadata.name]; + if (hasOwnProperty.call(moduleExports, metadata.name)) { + return moduleExports[metadata.name]; + } + return (undefined: any);
- hackhomelab 10mo agoIt could also be https://github.com/facebook/react/commit/7dc903cd29dac55efb4424853fd0442fef3a8700 https://github.com/facebook/react/commit/7dc903cd29dac55efb4... ("This also fixes a critical security vulnerability.")
- nine_k 10mo agoIt does the same thing here, too: https://github.com/facebook/react/commit/7dc903cd29dac55efb4424853fd0442fef3a8700#diff-26dd4970d5e3c8a592e7a3b7562553cb60ce7e7a1d06734c23ae647f8f59d4e6 https://github.com/facebook/react/commit/7dc903cd29dac55efb4...
- dizlexic 10mo ago[flagged]
- cluckindan 10mo agoThis is not related to ”use server”. That’s used to mark Server Actions / Server Functions, and it is not necessarily used in files with Server Components.
- ptx 10mo agoIt sounds related to me. The react.dev blog post [1] says that the vulnerability is > a flaw in how React decodes payloads sent to React Server Function endpoints and the react.dev docs for React Server Functions [2] say that > Server Components can define Server Functions with the "use server" directive [...] Client Components can import Server Functions from files that use the "use server" directive So it certainly sounds like the vulnerability is related to React Server Functions which are related to "use server". [1] https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components https://react.dev/blog/2025/12/03/critical-security-vulnerab... [2] https://react.dev/reference/rsc/server-functions https://react.dev/reference/rsc/server-functions
- cluckindan 10mo agoNo. You cannot find all vulnerable code by grepping for ”use server”, for instance.
- dizlexic 10mo agoSo that’s your “it’s not related to use server” argument? That seems like it could be a quote from their hardening guide.
- jazzypants 10mo agoI'm sorry, but you're incorrect. That is genuinely how this CVE works. All (and only) code with "use server" was vulnerable.
- dzonga 10mo agotill this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.
- nonethewiser 10mo agoeasier/more reactivity, doesnt require your api responses to be text parsable to html
- deleted 10mo ago[deleted]
- switz 10mo agoThey lend you optionality of when and where you want your code to run. Plus it enables you to define the server/client network boundary where you see fit and cross that boundary seamlessly. It's totally fine to say you don't understand why they have benefits, but it really irks me when people exclaim they have no value or exist just for complexity's sake. There's no system for web development that provides the developer with more grounded flexibility than RSCs. I wrote a blog post about this[0]. To answer your question, htmx solves this by leaning on the server immensely. It doesn't provide a complete client-side framework when you need it. RSCs allow both the server and the client to co-exist, simply composing between the two while maintaining the full power of each. [0] https://saewitz.com/server-components-give-you-optionality https://saewitz.com/server-components-give-you-optionality
- ptx 10mo agoBut is it a good idea to make it seamless when every crossing of the boundary has significant implications for security and performance? Maybe the seam should be made as simple and clear as possible instead.
- paulhebert 10mo ago
- karimf 10mo ago> Projects hosted on Vercel benefit from platform-level protections that already block malicious request patterns associated with this issue. https://vercel.com/changelog/cve-2025-55182 https://vercel.com/changelog/cve-2025-55182 > Cloudflare WAF proactively protects against React vulnerability https://blog.cloudflare.com/waf-rules-react-vulnerability/ https://blog.cloudflare.com/waf-rules-react-vulnerability/
- Rauchg 10mo agoWe collaborated with many industry partners to proactively deploy mitigations due to the severity of the issue. We still strongly recommend everyone to upgrade their Next, React, and other React meta-frameworks (peer)dependencies immediately.
- semiquaver 10mo agoDoes AWS WAF have a mitigation in place?
- odie5533 10mo agoYes, AWS WAF rule is in AWSManagedRulesKnownBadInputsRuleSet https://aws.amazon.com/security/security-bulletins/rss/aws-2025-030/ https://aws.amazon.com/security/security-bulletins/rss/aws-2...
- vanwal_j 10mo agoDoes this include any provider that does not fall under USA CLOUD Act? This vulnerability disclosure timeline is a nightmare for us Europeans, it was fully disclosed yesterday late afternoon for us and I can trace back attack logs that happend during the night. I expect some downfalls from this. I genuinely believe Next.JS is a great framework, but as an European developer working on software that should not touch anything related to CLOUD Act you're just telling me that Next.JS and React, despite being OSS, is not made for me anymore.
- bfelbo 10mo ago
- croemer 10mo agoLink should go to: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components https://react.dev/blog/2025/12/03/critical-security-vulnerab...
- javaking 10mo agoI'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb
- IceDane 10mo agoNot even remotely similar.
- mvdtnz 10mo agoThere is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs. This kind of thing is the predictable result.
- chasd00 10mo agoto be fair to bootcamp developers, i don't think they ever did "believe that there's virtue" in the setup, they were just told this is what you use and how you use it.
- homebrewer 10mo agoIt's just the latest take on what we had 20 years ago with .NET's WebForms and Java's JSF. Both of which tried to hide the network separation between client and server and were not fun to work with. Those who don't learn history are bound to repeat it, and all that.
- c-hendricks 10mo agoAnyone know how Tanstack Start isn't affected?
- dimitrisnl 10mo agoThey haven't implemented RSC yet.
- serhalp 10mo agoTanStack Start has its own implementation of Server Functions: https://tanstack.com/start/latest/docs/framework/solid/guide/server-functions https://tanstack.com/start/latest/docs/framework/solid/guide.... It doesn't use React Server Functions, in part because it intends to be agnostic of the rendering framework (it currently supports React and Solid). To be fair, they also haven't released (even experimental) RSC support yet, so maybe they lucked out on timing here.
- coffeecoders 10mo agoThis vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tighten the deserializer, but there is deeper issue. React never really acknowledged that it was building an RPC layer. If you look at actual RPC frameworks like gPRC or even old school SOAP, they all start with schemas, explicit service definitions and a bunch of tooling to prevent boundary confusion. React went the opposite way: the API surface is whatever your bundler can see, and the endpoint is whatever the client asks for. My guess is this won't be the last time we see security fallout from that design choice. Not because React is sloppy, but because it’s trying to solve a problem category that traditionally requires explicitness, not magic.
- j45 10mo agoFor the layperson, does this mean this approach and everything that doesn't use it is not secure? Building a private, out of date repo doesn't seem great either.
- coffeecoders 10mo agoNot quite. This isn’t saying React or Next.js are fundamentally insecure in general. The problem is this specific "call whatever server code the client asks" pattern. Traditional APIs with defined endpoints don’t have that issue.
- koakuma-chan 10mo agoYou mean call whatever server action the client asks? I don't think having this vulnerability was intentional.
- j45 10mo agoI don’t think I’ve heard of intentional vulnerabilities?
- kachapopopow 10mo agostatic builds save the day.
- _el1s7 10mo agoNext.js/RSC has become the new PHP :) I guess now we'll see more bots scanning websites for "/_next" path rather than "/wp-content".
- ivanjermakov 10mo agoInevitable when the line between the client and the server is blurred this much. RCE in a UI library is not a phrase you hear often.
- jacquesm 10mo agoMaybe one day we'll look back at JavaScript and conclude it was a gigantic mistake ship unaudited executable code to a few billion people every day.
- rglover 10mo agoJavaScript is fine, it's what and how people build with it that's the problem. It was never meant to be a systems language but we're desperate to make it one.
- jacquesm 10mo agoIn light of this discussion: https://news.ycombinator.com/item?id=46141771 https://news.ycombinator.com/item?id=46141771 that is an interesting observation.
- Vinnl 10mo agoI have seen a number of attempts at exploiting this on our deployment already. Luckily I saw and was able to apply the patch last night, but as a European, it wasn't great to only get the announcement after dinner time.
- halflife 10mo agoWhy does the react development team keeps investing their time on confusing features that only reinvent the wheel and cause more problems than solve? What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering? Why won’t they invest more on solving the developer experience that took a nosedive when hooks were introduced? They finally added a compiler, but instead of going the svelte route of handling the entire state, it only adds memoization? If I can send a direct message to the react team it would be to abandon all their current plans, and work on allowing users to write native JS control flows in their component logic. sorry for the rant.
- paularmstrong 10mo ago> What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering? RSC is their solution to not being able to figure out how to make SSR faster and an attempt to reduce client-side bloat (which also failed)
- halflife 10mo agoMaybe if they compiled away their runtime like svelte and somewhat like angular, then running SSR would be faster.
- cluckindan 10mo agoSSR with CSR is a worst-of-both-worlds approach. It leads to brittle ”isomorphic” behaviors when the same code needs to handle both SSR and CSR, inevitable client-side ”hydration” mismatches and various other issues. The same code needs to fetch eagerly but minimally, but also use and update the server-provided data on the client-side. Ultimately that so-called ”isomorphism” causes more numerous and difficult problems than it solves.
- halflife 10mo agoSounds a little like hooks. A purist approach with short term thinking got everyone deep in a rabbit hole with too many pitfalls.
- samdoesnothing 10mo agoThis is genuinely embarrassing for the Next.js and React teams. They were warned for years that their approach to server-client communication had risks, derided and ignored everyone who didn't provide unconditional praise, and now this. I think their time as Javascript thought leaders is past due.
- zbentley 10mo agoCurious, not critical: got links to the warnings that were given about this approach over the years? I’m interested in learning more about the history here.
- samdoesnothing 10mo agoNot really, I didn't keep receipts. This stuff was discussed heavily on X a couple years ago when they were first launched and a lot of people questioned the wisdom of implicit RPC and blurring the lines between client/server, and the increasing complexity of React. I'm sure there were some articles written as well. I believe one of the React email services got pwned because they leaked sensitive info via RSC, and there was a whole fiasco around Next.js encrypting server secrets and sending them to the client. Lo and behold just a couple years later, a lvl 10 RCE because of the complexity of their RPC approach coupled with the blurring of the lines between client/server...it's not like it's surprising to us. A repro of the vulnerability is on X & Github if you want to search for it, it's a classic deserialization bug that only exists because their format is so complex (and powerful). Remember a lot of us use React as a UI library and to see it causing our servers to get pwned is what people were uneasy about when they announced RSC. Unfortunately much of this discussion is on X which makes it hard to find, especially because I think Dan Abromov deleted his X account.
- punkbit 10mo agoDo you really need React Server Conponents or even Server Side Rendering?
- gloosx 10mo agoOf course you do, in certain cases making less round-trips to the server is just straight more efficient
- quentindanjou 10mo agoIt's very use-case dependent. SSR can be a game-changer in domains like e-commerce. But completely useless for some other use case. RSC advantages are a bit more complex to explain, because even a simple portfolio website would benefit from it. Contrary to the common belief created by long-term ReactJS dev, RSC simplifies a lot of the logic. Adapting existing code to RSC can be quite a mess and RSC is a big change of mindset for anybody used to ReactJS.
- henryfjordan 10mo agoBefore SSR (unless you were using PHP I guess) you had to ship a shell of a site with all the conditionals being decided only AFTER the browser has gotten all the HTML + JS pulled down. If you need to make any API calls, you've delayed rendering by hundreds of milliseconds or worse (round trip to your server) With SSR, those round trips to the server could be down to single-digit milliseconds assuming your frontend server is in the same datacenter as your backend. Plus you send HTML that has actual content to be rendered right away. A truly functional pageload can go from seconds to milliseconds, and you're transferring less data over the wire. Better all around at the expense of running a React Server instead of a static file host.
- jazzypants 10mo agoThank you. It's disappointing that you have to say this on a website full of supposedly technically proficient people.
- venturecruelty 10mo agoYes. Web applications were impossible before these libraries.
- ejpir 10mo agoI'm fumbled around a bit and got it working, but not entirely sure if this is how it really works: have a look at https://github.com/ejpir/CVE-2025-55182-poc https://github.com/ejpir/CVE-2025-55182-poc
- croemer 10mo agoThanks for the writeup, it's incredible!
- croemer 10mo agoThe PoC is AI generated crap - sorry for the initial comment lauding it. I should have checked better. See: https://github.com/ejpir/CVE-2025-55182-poc/issues/1 https://github.com/ejpir/CVE-2025-55182-poc/issues/1 and https://react2shell.com/ https://react2shell.com/
- WatchDog 10mo agoI ran your exploit-rce-v4.js with and without the patched react-server-dom-webpack, and both of them executed the RCE. So I don't think this mechanism is exactly correct, can you demo it with an actual nextjs project, instead of your mock server?
- ejpir 10mo agoI'm trying that, nextjs is a little different because it uses a Proxy object before it passes through, which blocks the rce. I'm debugging it currently, maybe I'm not on the right path after all.
- ejpir 10mo agoI'v updated the code, try it now with server-realistic.js: 1. npm start 2. npm run exploit
- slopfighter 10mo agoYour lump of AI-generated slop has detracted from the response to an important vulnerability. Congratulations. Your PoC is invalid and you should delete it.
- ksherlock 10mo agoYou can't have Vercel without RCE.
- gcau 10mo agoI'm a big fan of react, but all the server stuff was a cold hard mistake, it's only a matter of time before the (entire) react team realises it, assuming their nextjs overlords permit it.
- darepublic 10mo agoNext is only good for it's static build, once it drops support for that I'm out.
- cced 10mo agoYeah but even there, how do you get dynamic routes for static builds?
- ashishb 10mo agoJavaScript is meant to be run in a browser. Not on a backend server [1]. Those who are choosing JS for the backend are irresponsible stewards of their customers' data. 1- https://ashishb.net/tech/javascript/ https://ashishb.net/tech/javascript/
- odie5533 10mo agoTypeScript is really nice though.
- ashishb 10mo ago> TypeScript is really nice though. Even if that's true, it is irrelevant. - You need to decide package manager and everyone has their favorite one: npm, yarn, bun, pnpm ... - You need to depend on npmjs.com for dependencies, which has an unusually high number of malicious packages compared to other dependency sources. - You need to use some framework like Next.js, which itself is a cesspool of backward-incompatible changes, combined with outrageous security issues
- steve_adams_86 10mo agoIf you use deno you can consume dependencies much more securely from arbitrary URLs, such as your own. You can also set permissions for the runtime, though that might not save you depending on the severity of exploits. Arguably the safest approach is to embed all dependencies in your source, and vet all of them for each release. But I'm glad deno lets me choose which registry I use. Bun also allows for this but it feels a bit more tacked-on and less like an early architectural decision based around security concerns.
- ashishb 10mo ago> If you use deno you can consume dependencies much more securely How would Deno have prevented the RCE issue with React+Next.js?
- 10mo ago
- udev4096 10mo agoI am betting it would be exploited in the wild in the next few days, buckle up!
- z3ratul163071 10mo agothere can be no React RCE. if it is on the frontend, it is a browser RCE. if it is on the backend, then, as in this case it is a Next.js RCE.
- antonstihl 10mo agoThe Next.js server runs React modules. While one may argue that Next.js shouldn't bundle vulnerable dependencies, React does have modules for server-side runtimes these days and should be accountable.
- Tomuus 10mo agoThe vulnerable code exists inside of the React Flight wire protocol that is used by Next.js but also Vite, Parcel, Waku and any other custom RSC implementation that exists. Your comment was accurate circa 2019 but not since React released server components.
- steve_adams_86 10mo agoYou're wrong, but this is one of the unsettling things about the vulnerability and what React has become. Intuitively, you'd think a view library can't have RCE vulnerabilities like this. But that's not what React is anymore.
- Copenjin 10mo agoIncredibile, completely unexpected, no one ever ever pointed out that RCS and most of the rest was not good software. No one, no one.
- auggierose 10mo agoI like React, a lot. But it looks to me that RSC is not something I would use in an offline-first application anyway, is that right?
- vinnymac 10mo agoYou wouldn't use it in an offline-first application. But you can use it an offline-first application, and it isn't even very difficult. I have built electron apps for fun that utilize React Server Components entirely offline.
- Raicuparta 10mo agoPart of RSC is the ability to have each component fetch their own data on the server, or at build time. Meaning you can use this part for static pages, offline apps, etc. But that part is unrelated to this vulnerability.
- fergie 10mo agoIs there some sort of example exploit somewhere?
- darig 10mo ago[dead]
- cowsandmilk 10mo agohttps://github.com/ejpir/CVE-2025-55182-poc https://github.com/ejpir/CVE-2025-55182-poc
- cluckindan 10mo agoI will believe it works when it is demonstrated against a create-next-app project.
- Tomuus 10mo agoThis POC is not realistic and doesn't work against production builds of Next.js. It requires explicit exposure of gadgets by the user (eg. vm.runInContext) so is invalid as noted on https://react2shell.com https://react2shell.com
- slop-cop 10mo agoThe guy who discovered the actual vulnerability says otherwise. Delete this distraction to genuine blue teamers and stop shitting up the information landscape with this utter hogwash. This is why infosec is dead. https://react2shell.com/ https://react2shell.com/ https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issuecomment-3609929967 https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issueco...
- karel-3d 10mo agoI am so behind JavaScript that I didn't even know React can somehow run on a backend. I thought it's a frontend framework? Oh, well.
- mohamed_altyb 10mo ago[dead]
- sylware 10mo agoone fixed... one bazillion to go...
- spoctrial 10mo agoPOC: https://github.com/Ashwesker/Blackash-CVE-2025-55182/ https://github.com/Ashwesker/Blackash-CVE-2025-55182/
- danabramov 10mo agoThis doesn't look real to me. I don't believe a `_next/static/chunks/react-flight` endpoint even exists.
- oliverpk 10mo agoSo this can be avoided by using react like a normal person... client side rendering + bundled with vite
- testjag 10mo agoHow do hacker exploit it? I want to test on my websites
- dacodaco1 10mo ago[dead]
- dacodaco1 10mo ago[dead]