This 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.
The vast majority of developers do not update their frameworks to the latest version so this is something that will linger on for years. Particularly if you're on Next something-like-12 and there's breaking changes in order to go to 16 + patch.
OTOH this is great news for bad actors and pentesters.
To me it just looks like unacceptable carelessness, not an indictment of the alleged "lack of explicitness" versus something like gRPC. Explicit schemas aren't going to help you if you're so careless that, right at the last moment, you allow untrusted user input to reference anything whatsoever in the server's name space.
But once that particular design decision is made it is a question of time before that happens. The one enables the other.
The fact that React embodies an RPC scheme in disguise is quite obvious if you look at the kind of functionality that is implemented, some of that simply can not be done any other way. But then you should own that decision and add all of the safeguards that such a mechanism requires, you can't bolt those on after the fact.
The endpoint is not whatever the client asks for. It's marked specifically as exposed to the user with "use server". Of course the people who designed this recognize that this is designing an RPC system.
A similar bug could be introduced in the implementation of other RPC systems too. It's not entirely specific to this design.
so any package could declare some modules as “use server” and they’d be callable, whether the RSC server owner wanted them to or not? That seems less than ideal.
The vulnerability exists in the transport mechanism in affected versions. Default installs without custom code are also vulnerable even if they do not use any server components / server functions.
> 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.
Now I'm worried, but I don't use React. So I will have to ask: how does SvelteKit fares in this aspect?
Eval has been known to be super dangerous since before the internet grew up and went mainstream. It is so dangerous that to deploy stuff containing it should come with a large flashing warning whenever you run it.
Half of web map solutions rely on workers, which can't be easily loaded from 3rd party origins, so are loaded as blobs. loading worker from blob is effectively an eval.
No, their whole point is that what they are doing is the literal equivalent of calling eval. Whether that actually uses the word 'eval' or a function called 'eval' is besides the point.
This is only really fine as long as you have extremely clearly, well defined actions. You need to verify that the request is sane, well-formed, and makes sense for the current context, at the very least.
Architecturally there appears to be an increasingly insecure attack surface appearing in JavaScript at large, based on the insecurities in mandatory dependencies.
If the foundation and dependencies of react has vulnerabilities, react will have security issues indirectly and directly.
This explicit issue seems to be a head scratcher. How could something so basic exist for so long?
Again I ask about react and next.js from their perspective or position of leadership in the JavaScript ecosystem. I don’t think this is a standard anyone wants.
Could there be code reviews created for LLMs to search for issues once discovered in code?
To be fair, the huge JavaScript attack surface has ALWAYS been there. JavaScript runs in a really dynamic environment and everything from XSS-onwards has been fundamentally due to why you can do with the environment.
If you remember “mashups” these were basically just using the fact that you can load any code from any remote server and run it alongside your code and code from other servers while sharing credentials between all of them. But hey it is very useful to let Stripe run their stripe.js on your domain. And AdSense. And Mixpanel. And while we are at it let’s let npm install 1000 packages for a single dependency project. It’s bad.
> 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 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.
Given 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__.
I 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.
not `__proto__` but likely `constructor`, if you access `({}).constructor` you'd get the Object constructor, then if you access `.constructor` on that you'd get the Function constructor
the one problem I haven't understood is how it manages to perform a second call afterwards, as only being able to call Function constructor doesn't really amount to much (still a serious problem though)
It's RPC. Remote procedure calls. An approach that has made a comeback in the front-end space recently. There was tRPC; then react made a splash with the release of its server components; then other frameworks started emulating the approach. I think Svelte now has something similar with its "remote functions". And Solid has been working on something similar; so that SolidStart now has a "use server" pragma. They probably don't replicate React's protocol; but the idea of calling functions on the server is similar.
> An approach that has made a comeback in the front-end space recently.
It wasn’t really a “comeback,” RPC never lost popularity. We just called them “REST” APIs that were a barely disguised adhoc JSON RPC format with a few CRUD verbs tacked on for routing requests.
Why 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.
I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a <script> (server calling client). You can still have an API layer of course, but this gives you a syntactical way to express that there's a piece of backend that prepares data for this piece of frontend.
This resolves tensions between evolving both sides: the each piece of backend always prepares the exact data the corresponding piece of frontend needs because they're literally bound by a function call (or rather JSX). This also lets you load data as granularly as you want without blocking (very nice when you have a low-latency data layer).
Of course you can still have a traditional REST API if you want. But you can also have UI-specific server computation in the middle. There's inherent tension between the data needed to display the UI (a view model) and the way the data is stored (database model); RSC gives you a place to put UI-specific logic that should execute on the backend but keeps composability benefits of components.
As merely a systems engineer sometimes having to create a Web app I really much appreciate the experience of building a well-separated app without layers of trivial but flaky boilerplate layers that is a REST API in a dynamic language. The Next app I built last year using heavily RSC is one of the most legible and easy-to-maintain apps I have created so far.
We'll see if the magic can be trusted on or if we need more explicit solutions to this, but the Next/RSC experience was vastly superior compared to writing another REST API that is never to be used with anything else than the accompanied React app, and I'd love to use it or something similar to it in the future.
The reason is probably that a REST API for a "BFF" is in many cases quite tightly coupled with the frontend, and trying to detach those in the system architecture does not separate them in some higher scheme of things. Even if the two parts could separated but would never end up used without another, the separation probably just makes an unnecessary barrier.
I mean the different aspects of my Next app are now clearly separated, but they do form functional units. The separation between frontend and BFF is gone, but that was a wrong boundary in small scale apps to begin with.
Thanks for the comment Dan, I always appreciate you commenting and explaining in civility, and I’m sorry if I came a bit harsh.
I understand the logic, but there are several issues I can think of.
1 - as I said, SSR and API layers are good enough, so investing heavily in RSC when the hooks development experience is still so lacking seems weird to me. React always hailed itself as the “just JS framework”, but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.
2 - as react was always celebrated as an unopinionated framework, RSC creates a deep coupling between 2 layers which were classically very far apart.
Here are a list of things that would rather have react provide:
- advanced form functionality that binds to model, and supports validation
- i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed
- signals, for proper reactive state
- better templating ability for control flows
- native animation library
All of these things are important so I wouldn’t have to learn each new project’s permutation of the libraries de jour.
> React always hailed itself as the “just JS framework”,
I've literally never heard someone say "React is just a JS framework". They've said React uses JSX over templates. And that React has introduced functional components. But never heard someone say what you're claiming.
> but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.
This is wild. Yes you can. You can write regular JS in components. I can go build a component right now that uses JS (either with or without hooks). You're conflating the rules of hooks with the ability to use Javascript. Yes, there are rules. No, that doesn't mean you can no longer can write JS.
> i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed
Tradeoffs. Now each update needs to be rebuilt and redeployed. I don't have that problem in React.
> better templating ability for control flows
Better templating? React uses JSX. Are you saying there exists a better way to control flows than if/else?
> signals, for proper reactive state
This has been debated ad-nauseum in the React community and everything has a trade-off. I wish people would stop saying this as if it's categorically correct. React is UI is a function of state. Singlars would totally break the current mental model of React. Data flows down. This change would come with tradeoffs.
I’ve heard, especially during the first few years when react was introduced, that you don’t need templating, compiler, or anything special to write react, “it’s just JS”.
Of course you CAN write anything you want inside a component, but then it breaks, or has awful performance. To write components the proper way you can’t use any control flows with state management, you need to keep remembering which are the correct dependencies to recreate state, it makes components 20% BL and 80% react logic.
You can’t use if-else in JSX, since only expressions are allowed. So you need to create nested ternaries, which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.
And regarding signals, preact is using it and it doesn’t seem to break anything there.
Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.
> that you don’t need templating, compiler, or anything special to write react, “it’s just JS”
This is still true. I don't currently use any of those things. And the existance of a compiler does imply you can't write Javascript. Totally different concepts. Also, pretty sure they had compiler plans for like years now.
> but then it breaks, or has awful performance.
You're gonna have to be more specific. I could repeat that sentence for every programming language/library on the planet and without specifics it would make sense.
> You can’t use if-else in JSX,
I don't need to use if-else in JSX to control flow. I can write if(condition) return html;
> which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.
See the sentence I just wrote before this. I can use if/else to control flow and return early without templating. How is that not ideal?
> And regarding signals, preact is using it and it doesn’t seem to break anything there.
It's not about literlaly "breaking" something. They could implement htem if they wanted to. It's about breaking the mental model.
In React, data flows down. That's a constraint, but not always a bad one. I know exactly where to look for data (up). With signals, that's throw out the window. And now, it's not just about what the component accepts via props/context (which again, is down) it now needs to turn itself on it's head.
I used Angular for years before React and I do not miss having things talking to each other throw multiple lateral levels.
> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state.
> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.
This is incredibly misleading (and wrong). Templates don't compose. And React is quite literlaly the king of composition.
It's starting to feel like you've never actually used React, but instead are basing your opinions on what you see other people say (who have also not used React).
You either die a hero or live long enough to see yourself become the villain. The amount of time I've spent debugging other PRs (and mine) around hooks is just unruly, then React turned its attention to the server, something that I (most of us? we?) never ever asked for; but I guess that's what Meta, a company of cancer needs. I sure don't need it. Never have I imagined during the last 15 years that I'll be happy to say I'm using the mountain of enterprise spaghetti called Angular, but now I am. For years I hoped I'll be able to get back to React projects one day; that hope is long gone.
Totally agree. Chiming in as another React dev: I really regret the last few years of choices React has made. I don't want a React-integrated BFF layer, even on greenfield projects, hooks are awful and the whole thing just gets more awkward to solve tangentially related problems.
I really do want a good frontend framework that lets me expressively build and render dynamic frontend components, but it feels like 99% of React's development in the last few years has been just been creating churn and making that core frontend experience worse and worse. Hooks solve challenges around sharing component meta-functionality but then end up far worse for all other non-trivial cases, and it seems like RSC & concurrency just break things and add constraints instead of improving any part of my existing experience.
I guess this is cool if you're building mega-projects, but it makes React actively painful to use for anything smaller. I still use it every day, but as soon as I find a good off-ramp for my product (something similar, but simpler) I will take it. Moving towards Preact & signals currently seems like the best option for existing projects so far as I can tell.
IMO angular provides such a great experience developing.
They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated.
And what they DO add? Only things that improve dev exp
It was one hell of a ride, but I would say the Angular team did one hell of a job too, supporting the glue code until v18 (not sure if the latest version still does).
Having both old and new Angular running in one project is super weird, but everything worked out in the end.
You aren’t wrong. I basically stopped using any OSS code backed by Google as a result.
I’d pushed Angular over React[0] for a massive project, and it worked well, but the migration to Angular 2 when it came created a huge amount of non-value-adding work.
Never again.
I don’t even really want to build anything against Gemini, despite how good it is, because I don’t trust Google not to do another rug pull.
[0] I’ve never enjoyed JSX/TSX syntax, nor appreciated the mix of markup with code, but I’ve subsequently learned to live with it.
No one forced you to migrate immediately. (Also, non-value-adding work? You don't think the rewrite to TS did not bring any value? And thanks to that rewrite that app can be upgraded even today to Angular v21. And likely it'll be the case for many years.)
React also went through a lot of churn. (Still does.) There's no magic optimal duration for keeping API stability. Not in general and not for specific projects.
Ecosystems sometimes undergo a phase-shift. Sometimes they take a long time, based on the size. Python 3 was released in 2008, just a year before Angular 1. And the last Py2 release was in 2020, about 2-3 years before the last AngularJS version. (And of course there are many businesses running on py2 still. I know at least one.) These things take plenty of time.
Angular1 was pretty opinionated, willing to break with the tradition of just add one more jQuery plugin.
Miško was working at Google, he persuaded some people to take a look at the framework that he and Adam Abrons were tinkering with.
Angular 2 was announced in 2014 January. And then v1 still got years of support, even the component architecture was "backported" around 1.5 (in 2016?)
You can run old v1 code side-by-side in a v2+ app up until v17. (At least the v17 docs describe the process in full and later docs link to this page. https://v17.angular.io/guide/upgrade )
...
Google did a pretty good job IMHO. Google throws products under the bus, but not so much OSS projects. (Though the sate of AOSP comes to mind.)
Well, the official statement is that 1 and 2 are 2 different frameworks. That’s why they were later named to angular JS and angular, to avoid confusion.
The migration path between angular 1 and 2 is the same as react and angular, it’s just glue holding 2 frameworks together
Easy migration was promised but never delivered. Angular 2 was still full of boilerplate. “Migrating” an AngularJS project to Angular 2 is as much work as porting it to React or anything else.
So yes, people got burnt (when we were told that there will be a migration path), and I will never rely on another Google-backed UI framework.
I'll second that Angular provides a great experience these days, but they have definitely had substantial API changes within the last few years: standalone components, swapping WebPack for esbuild, the new control-flow syntax, the new unit-test runner, etc...
IMO, a big part of it is the lack of competition (in approach) exacerbated by the inability to provide alternatives due to technical/syntactical limitations of JavaScript itself.
Vue, Svelte, Angular, Ripple - anything other than React-y JSX based frameworks require custom compilers, custom file-types and custom LSPs/extensions to work with.
React/JSX frameworks have preferential treatment with pre-processors essentially baking in a crude compile time macro for JSX transformations.
Rust solved this by having a macro system that facilitated language expansion without external pre-processors - e.g. Yew and Leptos implement Vue-like and React-like patterns, including support for JSX and HTML templating natively inside standard .rs files, with standard testing tools and standard LSP support;
So either the ECMAScript folks figure out a way to have standardized runtime & compilable userland language extensions (e.g. macros) or WASM paves the way for languages better suited to the task to take over.
Neither of these cases are likely, however, so the web world is likely destined to remain unergonomic, overly complex and slow - at least for the next 5 - 10 years.
In my opinion, the core functionality of React (view rendering) is actually good and is why it cannot be unseated.
I remember looking for a DOM library:
- dojo: not for me
- prototype.js: not for me
- MooTools: not for me
- jQuery: something I liked finally
Well, guess what library won. After I adopted jQuery, I completely stopped looking for other DOM libraries.
But I still needed a template rendering library:
- Mustache.js: not for me
- Handlebars.js: not for me
- Embedded JavaScript Templates: not for me
- XML with XSLT: not for me
- AngularJS: really disliked it SOO much*
- Knockout.js: not for me
- Backbone.js with template engine: not for me and actually it was getting popular and I really wished it would just go away at the time**
- React: something I actually liked
You must remember that when React came out, you needed a JSX transpiler too, at a time when few people even used transpilers. This was a far bigger obstacle than these days IMO.
Which leads to my hot take: core React is just really good. I really like writing core React/JSX code and I think most people do too. If someone wrote a better React, I don’t think the problem you mentioned would hamper adoption.
The problems come when you leave React’s core competency. Its state management has never been great. Although not a React project itself, I hated Redux (from just reading its docs). I think RSC at the current moment is a disaster — so many pain points.
I think that’s where we are going to see the next innovation. I don’t think anyone is going to unseat React or JSX itself for rendering templates. No one unseated jQuery for DOM manipulation — rather we just moved entirely away from DOM manipulation.
*I spent 30 minutes learning AngularJS and then decided “I’m never going to want to see this library again.” Lo and behold they abandoned their entire approach and rewrote Angular for v2 so I guess I was right.
**It went away and thankfully I avoided having to ever learn Backbone.js.
Transpilation of anything other than jsx requires a complex toolchain with layers of things like LSPs, compilers, IDE plugins, bundler plugins, etc.
Frameworks that go that route typically activate this toolchain by defining a dedicated file extension (.vue, .svelte).
This custom toolchain (LSP, IDE plugins) presents a lot of overhead to project maintainers and makes it difficult to actually create a viable alternative to the JSX based ecosystem.
For instance both Vue and Svelte took years to support TypeScript, and their integrations were brittle and often incompatible with test tooling.
Angular used decorators in a very similar way to what I am describing here. It's a source code annotation in "valid" ecmascript that is compiled away by their custom compiler. Though decorators are now abandoned and Angular still requires a lot of custom tooling to work (e.g, try to build an Angular project with a custom rspack configuration).
JSX/TSX has preferential treatment in this regard as it's a macro that's built into tsc - no other framework has this advantage.
Chicken and egg problem. JSX is supported because it's popular. If React decides to push a new syntax I don't see why everyone wouldn't reasonably quickly adapt and support it.
SSR 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.
Especially cuz the vast majority of sites can either just be client rendered SPA's or server rendered multipage apps. There is no need for the complexity for most sites and yet this is the default for pretty much all js frameworks...
They are taking care of the customers. The customers are front-end dev with little experience in servers, back-end and networking. So they want to run some code that changes state without having to deal with all of that infra and complexity. Preferably while remaining in the "React state". That is the attraction of Nextjs and RSC.
Because Facebook has a budget for R&D, which works out to several salaries, and React is one of the biggest technical assets they have, so it's someone full time job to develop features and new versions of React to increase the moat and stock value of Meta.
It works out because it keeps a workforce of React Developers on their feet, learning about the new features, rather than doing other stuff. It's like SaSS for developers, only instead of paying a monthly subscription in cash, you have to pay a monthly subscription in man-hours.
It makes it easy to have a central JSON-like state object representing what's on the page, then have components watch that for changes and re-render. That avoids the opaqueness of Redux and promise chains, which can be difficult to examine and debug (unless we add browser extensions for that stuff, which feels like a code smell).
I've also heard heard good things about Astro, which can wrap components written in other frameworks (like React) so that a total rewrite can be avoided:
I'm way outside my wheelhouse on this as a backend developer, so if anyone knows the actual names of the frameworks I'm trying to remember (hah), please let us know.
IMHO React creates far more problems than it solves:
- Virtual DOM: just use Facebook's vast budget to fix the browser's DOM so it renders 1000 fps using the GPU, memoization, caching, etc and then add the HTML parsing cruft over that
- Redux: doesn't actually solve state transfer between backend and frontend like, say, Firebase
- JSX: do we really need this when Javascript has template literals now?
- Routing: so much work to make permalinks when file-based URLs already worked fine 30 years ago and the browser was the V in MVC
- Components: steep learning curve (but why?) and they didn't even bother to implement hooks for class components, instead putting that work onto users, and don't tell us that's hard when packages like react-universal-hooks and react-hookable-component do it
- Endless browser console warnings about render changing state and other errata: just design a unidirectional data flow that detects infinite loops so that this scenario isn't possible
I'll just stop there. The more I learn about React, the less I like it. That's one of the primary ways that I know that there's no there there when learning new tools. I also had the same experience with the magic convention over configuration in Ruby.
What's really going on here, and what I would like to work on if I ever win the internet lottery (unlikely now with the arrival of AI since app sales will soon plummet along with website traffic) is a distributed logic flow. In other words, a framework where developers write a single thread of execution that doesn't care if it's running on backend or frontend, that handles all state synchronization, preferably favoring a deterministic fork/join runtime like Go over async behavior with promise chains. It would work a bit like a conflict-free replicated data type (CRDT) or software transactional memory (STM) but with full atomicity/consistency/isolation/durability (ACID) compliance. So we could finally get back to writing what looks like backend code in Node.js, PHP/Laravel, whatever, but have it run in the browser too so that users can lose their internet connection and merge conflicts "just work" when they go back online.
Somewhat ironically, I thought that was how Node.js worked before I learned it, where maybe we could wrap portions of the code to have @backend {} or @frontend {} annotations that told it where to run. I never dreamed that it would go through so much handwaving to even allow module imports in the browser!
But instead, it seems that framework maintainers that reached any level of success just pulled up the ladder behind them, doing little or nothing to advance the status quo. Never donating to groups working from first principles. Never rocking the boat by criticizing established norms. Just joining all of the other yes men to spread that gospel of "I've got mine" to the highest financial and political levels.
So much of this feels like having to send developers to the end of the earth to cater to the runtime that I question if it's even programming anymore. It would be like having people write the low-level RTF codewords in MS word rather than just typing documents via WYSIWYG. We seem to have all lost our collective minds ..the emperor has no clothes.
Yikes I didn't know that! I haven't actually used it yet hah.
For a bit of context, I come from writing blitters on 8 MHz Mac Plusses, so I have a blind spot around slowness. Basically, that nothing should ever be slow today with GHz computers. So most slowness isn't a conceptual flaw, but an inefficient implementation.
These alternative frameworks are generally small enough that it might be kind of fun to stress test them and contribute some performance improvements. Especially with AI, I really have no excuse anymore.
Edit: after pondering this for 2 seconds, I suspect that it's actually a problem with backend requests. It may have some synchronous behavior (which I want) or layout dependency issues that force it to wait until all responses have arrived before rendering. That's a harder problem, but not insurmountable. Also things like this irk me, because browsers largely solved progressive layout in the 1990s and we seem to have lost that knowledge.
Nobody is using Redux any more, and it's even publically discouraged by the creator. It's a legacy system and including it in your problems list just makes me think you have no React experience and no idea what you are talking about (beyond technical yapping also Redux as a product still achieved what it tried to solve so your dx doesn't even matter).
Firebase in this context is just a database and how you poll data on client or server from it. Nonsensical reference again.
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.
However, if I am reading this correctly, your PoC falls in the category described here: https://react2shell.com/
> Anything that requires the developer to have explicitly exposed dangerous functionality to the client is not a valid PoC. Common examples we've seen in supposed "PoCs" are vm#runInThisContext, child_process#exec, and fs#writeFile.
> This would only be exploitable if you had consciously chosen to let clients invoke these, which would be dangerous no matter what. The genuine vulnerability does not have this constraint. In Next.js, the list of server functions is managed for you, and does not contain these.
Context: This is from Lachlan Davidson, the reporter of the vulnerability
Your lump of AI-generated slop has detracted from the response to an important vulnerability. Congratulations. Your PoC is invalid and you should delete it.
That 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.
As 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.
It'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.
Unfortunately, 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.
JavaScript 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.
I 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.
Right - you can NOT tell me that a sufficiently complex application using HTMX is easier to reason about than React. I've had to deal with a complex HTMX codebase and it is a nightmare.
Right - you can NOT tell me that a sufficiently simple application using React is easier to reason about than HTMX. I've had to deal with a simple React codebase and it is a nightmare.
Yeah… one of them addresses a market populated by hundreds of thousands of developers with extensive professional experience in the framework, and the other addresses a niche of Python developers who refused to learn JavaScript until somebody hid it from them and called it hypermedia.
100’s of thousands used to use php too :) most developers (roughly 97.56% are terrible/incompetent so going with the herd should tell you you are on the wrong train :)
Thousands of developers still use PHP… and even more users… Wordpress (43% of web), Facebook (billions of users), Wikipedia (billions of users)…. all PHP.
htmx is a a toy, mildly amusing to play with, built on an insecure foundation that bypasses basic browser security controls and hands a blob of JavaScript to a bunch of backend developers who can’t be bothered to learn it because they think they know better…
No serious project uses htmx and none ever will, because it becomes an unmaintainable mess by the third developer and second year of development.
“No serious project uses [insert any framework/language/…] and none ever will, because it becomes an unmaintainable mess by the third developer and second year of development” if team is incompetent
They 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.
But 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.
Just because something is made possible and you can do it doesn't mean you should!
The criticism is that by allowing you to do something you shouldn't, there isn't any benefit to be had, even if that system allows you to do something you couldn't before.
You can optionally enhance it and use React on the client. Doing that with HTMX is doable with "islands" but a bit more of a pain in the ass - and you'll struggle hard if you attempt to share client state across pages. Actually there are just a lot of little gotchas with the htmx approach
I mean it's a lot of complexity but ideally you shouldn't bring it in unless you actually need it. These solutions do solve real problems. The only issue is people try to use it everywhere. I don't use RSC, standard SPAs are fine for my projects and simpler
This 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]
One 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.
TanStack Start has its own implementation of 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.
This 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.
Part 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.
I'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
It's an RPC. They're half a century old. Java had RMI within a year of existence. [0]
> In remote procedure call systems, client-side stub code must be generated and linked into a client before a remote procedure call can be done. This code may be either statically linked into the client or linked in at run-time via dynamic linking with libraries available locally or over a network file system. In either the case of static or dynamic linking, the specific code to
handle an RPC must be available to the client machine in compiled form... Dynamic stub loading is used only when code for a
needed stub is not already available. The argument and return types specified in the remote interfaces are made available using the same mechanism. Loading arbitrary classes into clients or servers presents a potential security problem;
There 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.
"You can run JavaScript on the frontend and the backend!" always struck me as the weakest marketing ever. I've been around the block, and which language the web application uses is hardly any sort of limiting factor in ease of development. (And ideally, your frontend has as little JavaScript as possible anyway.) There is very little that can't be programmed in a more web-friendly way, like POSTing forms and rendering HTML templates. Sure, I guess Google Maps can just be a fat application, but like... every eCommerce site doesn't need to be some big ball of React mud, I promise.
I think the main problem was that 'the standard' wasn't evolving fast enough to solve the bulk of the issues around input validation and UI building so we got this crap language that is powerful enough to hide a thousand footguns in a few lines of code. It will never be perfect so it will generate this kind of issue for the next century or so.
If instead, we would have gradually expanded the HTML standard without adding a fully functional programming language into the content stream we would have had better consistency between websites and applications and we would treat the browser like what it is: a content delivery mechanism, not an application programming platform. That's the core mistake as far as I'm concerned.
to 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.
It'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.
> There 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.
First, "same code on the client and the serve" is wrong. Since when do RSC's run on both the client and the server?
Also, you honestly believe that wanting to use the same language across paradigms is a "coding bootcamp" thing lol? That something like Blazor was born out of a coding bootcamp?
Have you ever built a web app? Both front and back end? Have you ever had to deal with the tension of duplicating code? Models, validation, ideas?
If you answered yes to those questions but still don't see how de-duplicating code like that can be important, than I'm 100% positive you're still in the boot camp.
This 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
The 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.
The 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.
Before 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.
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.
I think they have a point, before cgi-bin it was almost impossible to have a real web application. It took a decade for server-side rendering to fall out of favour. Flash websites and Gmail starting to become seriously interactive in the mid 2000s were the start of frontend-first web applications, but even those relied on the backend to provide them with an initial data set to make performance usable.
No, they were not. They required a lot more round-trips to the server though, and rendering the results was a lot harder. But if you think of a browser as an intelligent terminal there is no reason why you couldn't run the application server side and display the UI locally, that's just a matter of defining some extra primitives. Graphical terminals were made first in the 60's or so.
I'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.
The 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.
This 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.
It 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".
I think the top-level comment was criticizing the entire feature (server functions) enabled by "use server". The vulnerability is in this feature, so (as I understand it) you're correct that grepping for "use server" won't find the vulnerable code, but if there was no such thing as "use server" the vulnerability wouldn't exist.
- 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
This 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).
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.
Indeed this is pretty bad.
The vast majority of developers do not update their frameworks to the latest version so this is something that will linger on for years. Particularly if you're on Next something-like-12 and there's breaking changes in order to go to 16 + patch.
OTOH this is great news for bad actors and pentesters.
To me it just looks like unacceptable carelessness, not an indictment of the alleged "lack of explicitness" versus something like gRPC. Explicit schemas aren't going to help you if you're so careless that, right at the last moment, you allow untrusted user input to reference anything whatsoever in the server's name space.
But once that particular design decision is made it is a question of time before that happens. The one enables the other.
The fact that React embodies an RPC scheme in disguise is quite obvious if you look at the kind of functionality that is implemented, some of that simply can not be done any other way. But then you should own that decision and add all of the safeguards that such a mechanism requires, you can't bolt those on after the fact.
this
I always felt server-action had too much "magic"
All mistakes can be blamed to "carelessness". This doesn't change the fact that some designs are more error-prone and more unsafe.
The endpoint is not whatever the client asks for. It's marked specifically as exposed to the user with "use server". Of course the people who designed this recognize that this is designing an RPC system.
A similar bug could be introduced in the implementation of other RPC systems too. It's not entirely specific to this design.
(I contribute to React but not really on RSC.)
”use server” is not required for this vulnerability to be exploitable.
wait I'm only using React for SPA (no server rendering)
am I also vulnerable??????
Only if you are running a vulnerable version of Next.js server.
No, unless you run the React Server Component runtime on your server, which you wouldn't do with a SPA, you would just serve a static bundle.
so any package could declare some modules as “use server” and they’d be callable, whether the RSC server owner wanted them to or not? That seems less than ideal.
The vulnerability exists in the transport mechanism in affected versions. Default installs without custom code are also vulnerable even if they do not use any server components / server functions.
> 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.
Now I'm worried, but I don't use React. So I will have to ask: how does SvelteKit fares in this aspect?
They were warned. I don't see how this can be characterized as anything but sloppy.
You can call anything, anytime, anywhere without restrictions or protection.
Imagine these dozens of people, working at Meta.
They sit at the table, they agree to call eval() and not think "what could go wrong"
Eval has been known to be super dangerous since before the internet grew up and went mainstream. It is so dangerous that to deploy stuff containing it should come with a large flashing warning whenever you run it.
Half of web map solutions rely on workers, which can't be easily loaded from 3rd party origins, so are loaded as blobs. loading worker from blob is effectively an eval.
The client sort of exists to have code injected into it though?
If you want to describe text mark-up as programming, then yes. But most people do not do that.
hmm isn't eval is used in figurative-sense here eh?
maybe you should get some sleep
No, their whole point is that what they are doing is the literal equivalent of calling eval. Whether that actually uses the word 'eval' or a function called 'eval' is besides the point.
> The server was deserializing untrusted input from the client directly into
If I had a dollar for every time a serious vulnerability that started like this was discovered in the last 30 years...
Just like the old days of PHP servers exposing their source code
For 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.
Not 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.
You mean call whatever server action the client asks? I don't think having this vulnerability was intentional.
This is only really fine as long as you have extremely clearly, well defined actions. You need to verify that the request is sane, well-formed, and makes sense for the current context, at the very least.
You would probably need to do the same if you were writing back-end in Go or something. I don't see how that is conceptually different.
I don’t think I’ve heard of intentional vulnerabilities?
Log4j almost seemed like it
xz?
I’m not asking if it’s fundamentally insecure.
Architecturally there appears to be an increasingly insecure attack surface appearing in JavaScript at large, based on the insecurities in mandatory dependencies.
If the foundation and dependencies of react has vulnerabilities, react will have security issues indirectly and directly.
This explicit issue seems to be a head scratcher. How could something so basic exist for so long?
Again I ask about react and next.js from their perspective or position of leadership in the JavaScript ecosystem. I don’t think this is a standard anyone wants.
Could there be code reviews created for LLMs to search for issues once discovered in code?
To be fair, the huge JavaScript attack surface has ALWAYS been there. JavaScript runs in a really dynamic environment and everything from XSS-onwards has been fundamentally due to why you can do with the environment.
If you remember “mashups” these were basically just using the fact that you can load any code from any remote server and run it alongside your code and code from other servers while sharing credentials between all of them. But hey it is very useful to let Stripe run their stripe.js on your domain. And AdSense. And Mixpanel. And while we are at it let’s let npm install 1000 packages for a single dependency project. It’s bad.
> it’s trying to solve a problem category that traditionally requires explicitness, not magic.
i've been thinking basically this for so long, i'm kinda happy to be validated about this lol
From Facebook/Meta: 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-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.
Given 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__.
I 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.
Only if you're deserializing into objects with behavior.
not `__proto__` but likely `constructor`, if you access `({}).constructor` you'd get the Object constructor, then if you access `.constructor` on that you'd get the Function constructor
the one problem I haven't understood is how it manages to perform a second call afterwards, as only being able to call Function constructor doesn't really amount to much (still a serious problem though)
This comment from a dupe thread is worth considering: https://news.ycombinator.com/item?id=46137352
"React Server Functions allow a client to call a function on a server"
Intentionally? That's a scary feature
> Intentionally?
It's RPC. Remote procedure calls. An approach that has made a comeback in the front-end space recently. There was tRPC; then react made a splash with the release of its server components; then other frameworks started emulating the approach. I think Svelte now has something similar with its "remote functions". And Solid has been working on something similar; so that SolidStart now has a "use server" pragma. They probably don't replicate React's protocol; but the idea of calling functions on the server is similar.
> An approach that has made a comeback in the front-end space recently.
It wasn’t really a “comeback,” RPC never lost popularity. We just called them “REST” APIs that were a barely disguised adhoc JSON RPC format with a few CRUD verbs tacked on for routing requests.
used to wire up form submission in a type-safe way, so that part makes sense at least
whatever monstrosity hides underneath these nice high-level TypeScript frameworks to make all of it happen in JS, usually that's the worrying part
Why 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.
Server Components is not really related to SSR.
I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a <script> (server calling client). You can still have an API layer of course, but this gives you a syntactical way to express that there's a piece of backend that prepares data for this piece of frontend.
This resolves tensions between evolving both sides: the each piece of backend always prepares the exact data the corresponding piece of frontend needs because they're literally bound by a function call (or rather JSX). This also lets you load data as granularly as you want without blocking (very nice when you have a low-latency data layer).
Of course you can still have a traditional REST API if you want. But you can also have UI-specific server computation in the middle. There's inherent tension between the data needed to display the UI (a view model) and the way the data is stored (database model); RSC gives you a place to put UI-specific logic that should execute on the backend but keeps composability benefits of components.
As merely a systems engineer sometimes having to create a Web app I really much appreciate the experience of building a well-separated app without layers of trivial but flaky boilerplate layers that is a REST API in a dynamic language. The Next app I built last year using heavily RSC is one of the most legible and easy-to-maintain apps I have created so far.
We'll see if the magic can be trusted on or if we need more explicit solutions to this, but the Next/RSC experience was vastly superior compared to writing another REST API that is never to be used with anything else than the accompanied React app, and I'd love to use it or something similar to it in the future.
The reason is probably that a REST API for a "BFF" is in many cases quite tightly coupled with the frontend, and trying to detach those in the system architecture does not separate them in some higher scheme of things. Even if the two parts could separated but would never end up used without another, the separation probably just makes an unnecessary barrier.
I mean the different aspects of my Next app are now clearly separated, but they do form functional units. The separation between frontend and BFF is gone, but that was a wrong boundary in small scale apps to begin with.
Thanks for the comment Dan, I always appreciate you commenting and explaining in civility, and I’m sorry if I came a bit harsh.
I understand the logic, but there are several issues I can think of.
1 - as I said, SSR and API layers are good enough, so investing heavily in RSC when the hooks development experience is still so lacking seems weird to me. React always hailed itself as the “just JS framework”, but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.
2 - as react was always celebrated as an unopinionated framework, RSC creates a deep coupling between 2 layers which were classically very far apart.
Here are a list of things that would rather have react provide:
- advanced form functionality that binds to model, and supports validation
- i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed
- signals, for proper reactive state
- better templating ability for control flows
- native animation library
All of these things are important so I wouldn’t have to learn each new project’s permutation of the libraries de jour.
Do you have a moment to talk about our Lord and Savior VueJS?
> React always hailed itself as the “just JS framework”,
I've literally never heard someone say "React is just a JS framework". They've said React uses JSX over templates. And that React has introduced functional components. But never heard someone say what you're claiming.
> but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.
This is wild. Yes you can. You can write regular JS in components. I can go build a component right now that uses JS (either with or without hooks). You're conflating the rules of hooks with the ability to use Javascript. Yes, there are rules. No, that doesn't mean you can no longer can write JS.
> i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed
Tradeoffs. Now each update needs to be rebuilt and redeployed. I don't have that problem in React.
> better templating ability for control flows
Better templating? React uses JSX. Are you saying there exists a better way to control flows than if/else?
> signals, for proper reactive state
This has been debated ad-nauseum in the React community and everything has a trade-off. I wish people would stop saying this as if it's categorically correct. React is UI is a function of state. Singlars would totally break the current mental model of React. Data flows down. This change would come with tradeoffs.
I’ve heard, especially during the first few years when react was introduced, that you don’t need templating, compiler, or anything special to write react, “it’s just JS”.
Of course you CAN write anything you want inside a component, but then it breaks, or has awful performance. To write components the proper way you can’t use any control flows with state management, you need to keep remembering which are the correct dependencies to recreate state, it makes components 20% BL and 80% react logic.
You can’t use if-else in JSX, since only expressions are allowed. So you need to create nested ternaries, which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.
And regarding signals, preact is using it and it doesn’t seem to break anything there.
Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.
> that you don’t need templating, compiler, or anything special to write react, “it’s just JS”
This is still true. I don't currently use any of those things. And the existance of a compiler does imply you can't write Javascript. Totally different concepts. Also, pretty sure they had compiler plans for like years now.
> but then it breaks, or has awful performance.
You're gonna have to be more specific. I could repeat that sentence for every programming language/library on the planet and without specifics it would make sense.
> You can’t use if-else in JSX,
I don't need to use if-else in JSX to control flow. I can write if(condition) return html;
> which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.
See the sentence I just wrote before this. I can use if/else to control flow and return early without templating. How is that not ideal?
> And regarding signals, preact is using it and it doesn’t seem to break anything there.
It's not about literlaly "breaking" something. They could implement htem if they wanted to. It's about breaking the mental model.
In React, data flows down. That's a constraint, but not always a bad one. I know exactly where to look for data (up). With signals, that's throw out the window. And now, it's not just about what the component accepts via props/context (which again, is down) it now needs to turn itself on it's head.
I used Angular for years before React and I do not miss having things talking to each other throw multiple lateral levels.
> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state.
> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.
This is incredibly misleading (and wrong). Templates don't compose. And React is quite literlaly the king of composition.
It's starting to feel like you've never actually used React, but instead are basing your opinions on what you see other people say (who have also not used React).
You either die a hero or live long enough to see yourself become the villain. The amount of time I've spent debugging other PRs (and mine) around hooks is just unruly, then React turned its attention to the server, something that I (most of us? we?) never ever asked for; but I guess that's what Meta, a company of cancer needs. I sure don't need it. Never have I imagined during the last 15 years that I'll be happy to say I'm using the mountain of enterprise spaghetti called Angular, but now I am. For years I hoped I'll be able to get back to React projects one day; that hope is long gone.
Totally agree. Chiming in as another React dev: I really regret the last few years of choices React has made. I don't want a React-integrated BFF layer, even on greenfield projects, hooks are awful and the whole thing just gets more awkward to solve tangentially related problems.
I really do want a good frontend framework that lets me expressively build and render dynamic frontend components, but it feels like 99% of React's development in the last few years has been just been creating churn and making that core frontend experience worse and worse. Hooks solve challenges around sharing component meta-functionality but then end up far worse for all other non-trivial cases, and it seems like RSC & concurrency just break things and add constraints instead of improving any part of my existing experience.
I guess this is cool if you're building mega-projects, but it makes React actively painful to use for anything smaller. I still use it every day, but as soon as I find a good off-ramp for my product (something similar, but simpler) I will take it. Moving towards Preact & signals currently seems like the best option for existing projects so far as I can tell.
I wish React wasn’t the “default” framework.
I agree that the developer experience provided by the compiler model used in Svelte and React is much nicer to work with
IMO angular provides such a great experience developing. They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated.
And what they DO add? Only things that improve dev exp
> They had minimal API changes in the last 10 years
The 1 to 2 transition was one hell of a burn though; people are probably still smarting...
It was one hell of a ride, but I would say the Angular team did one hell of a job too, supporting the glue code until v18 (not sure if the latest version still does).
Having both old and new Angular running in one project is super weird, but everything worked out in the end.
You aren’t wrong. I basically stopped using any OSS code backed by Google as a result.
I’d pushed Angular over React[0] for a massive project, and it worked well, but the migration to Angular 2 when it came created a huge amount of non-value-adding work.
Never again.
I don’t even really want to build anything against Gemini, despite how good it is, because I don’t trust Google not to do another rug pull.
[0] I’ve never enjoyed JSX/TSX syntax, nor appreciated the mix of markup with code, but I’ve subsequently learned to live with it.
No one forced you to migrate immediately. (Also, non-value-adding work? You don't think the rewrite to TS did not bring any value? And thanks to that rewrite that app can be upgraded even today to Angular v21. And likely it'll be the case for many years.)
React also went through a lot of churn. (Still does.) There's no magic optimal duration for keeping API stability. Not in general and not for specific projects.
Ecosystems sometimes undergo a phase-shift. Sometimes they take a long time, based on the size. Python 3 was released in 2008, just a year before Angular 1. And the last Py2 release was in 2020, about 2-3 years before the last AngularJS version. (And of course there are many businesses running on py2 still. I know at least one.) These things take plenty of time.
Angular1 was pretty opinionated, willing to break with the tradition of just add one more jQuery plugin.
Miško was working at Google, he persuaded some people to take a look at the framework that he and Adam Abrons were tinkering with.
Angular 2 was announced in 2014 January. And then v1 still got years of support, even the component architecture was "backported" around 1.5 (in 2016?)
You can run old v1 code side-by-side in a v2+ app up until v17. (At least the v17 docs describe the process in full and later docs link to this page. https://v17.angular.io/guide/upgrade )
...
Google did a pretty good job IMHO. Google throws products under the bus, but not so much OSS projects. (Though the sate of AOSP comes to mind.)
Well, the official statement is that 1 and 2 are 2 different frameworks. That’s why they were later named to angular JS and angular, to avoid confusion.
The migration path between angular 1 and 2 is the same as react and angular, it’s just glue holding 2 frameworks together
And that change happened 10 years ago
> That’s why they were later named to angular JS and angular, to avoid confusion.
Angular.js and angular. That's not confusing at all :-)
this -- even google search results were mixed up
should be more different: eg "rect-angular vs angular"
Easy migration was promised but never delivered. Angular 2 was still full of boilerplate. “Migrating” an AngularJS project to Angular 2 is as much work as porting it to React or anything else.
So yes, people got burnt (when we were told that there will be a migration path), and I will never rely on another Google-backed UI framework.
> I will never rely on another Google-backed UI framework.
Lit is pretty good :-) Though it was never positioned as a framework. And it recently was liberated from google.
I tried it once, and it was like, you have to edit 5 files to add 1 button.
same 5 files in every project at every company on earth
I'll second that Angular provides a great experience these days, but they have definitely had substantial API changes within the last few years: standalone components, swapping WebPack for esbuild, the new control-flow syntax, the new unit-test runner, etc...
React is good enough, so it's very hard to come up with a strong case to use anything else.
It really isn't good enough
I like the hooks :(
I agree. Incoming hot take.
IMO, a big part of it is the lack of competition (in approach) exacerbated by the inability to provide alternatives due to technical/syntactical limitations of JavaScript itself.
Vue, Svelte, Angular, Ripple - anything other than React-y JSX based frameworks require custom compilers, custom file-types and custom LSPs/extensions to work with.
React/JSX frameworks have preferential treatment with pre-processors essentially baking in a crude compile time macro for JSX transformations.
Rust solved this by having a macro system that facilitated language expansion without external pre-processors - e.g. Yew and Leptos implement Vue-like and React-like patterns, including support for JSX and HTML templating natively inside standard .rs files, with standard testing tools and standard LSP support;
https://github.com/leptos-rs/leptos/blob/main/examples/count...
https://github.com/yewstack/yew/blob/master/examples/counter...
So either the ECMAScript folks figure out a way to have standardized runtime & compilable userland language extensions (e.g. macros) or WASM paves the way for languages better suited to the task to take over.
Neither of these cases are likely, however, so the web world is likely destined to remain unergonomic, overly complex and slow - at least for the next 5 - 10 years.
OK I got my own extremely hot take.
In my opinion, the core functionality of React (view rendering) is actually good and is why it cannot be unseated.
I remember looking for a DOM library:
- dojo: not for me
- prototype.js: not for me
- MooTools: not for me
- jQuery: something I liked finally
Well, guess what library won. After I adopted jQuery, I completely stopped looking for other DOM libraries.
But I still needed a template rendering library:
- Mustache.js: not for me
- Handlebars.js: not for me
- Embedded JavaScript Templates: not for me
- XML with XSLT: not for me
- AngularJS: really disliked it SOO much*
- Knockout.js: not for me
- Backbone.js with template engine: not for me and actually it was getting popular and I really wished it would just go away at the time**
- React: something I actually liked
You must remember that when React came out, you needed a JSX transpiler too, at a time when few people even used transpilers. This was a far bigger obstacle than these days IMO.
Which leads to my hot take: core React is just really good. I really like writing core React/JSX code and I think most people do too. If someone wrote a better React, I don’t think the problem you mentioned would hamper adoption.
The problems come when you leave React’s core competency. Its state management has never been great. Although not a React project itself, I hated Redux (from just reading its docs). I think RSC at the current moment is a disaster — so many pain points.
I think that’s where we are going to see the next innovation. I don’t think anyone is going to unseat React or JSX itself for rendering templates. No one unseated jQuery for DOM manipulation — rather we just moved entirely away from DOM manipulation.
*I spent 30 minutes learning AngularJS and then decided “I’m never going to want to see this library again.” Lo and behold they abandoned their entire approach and rewrote Angular for v2 so I guess I was right.
**It went away and thankfully I avoided having to ever learn Backbone.js.
Does transpilation not cover this? That's how they did JSX.
Transpilation of anything other than jsx requires a complex toolchain with layers of things like LSPs, compilers, IDE plugins, bundler plugins, etc.
Frameworks that go that route typically activate this toolchain by defining a dedicated file extension (.vue, .svelte).
This custom toolchain (LSP, IDE plugins) presents a lot of overhead to project maintainers and makes it difficult to actually create a viable alternative to the JSX based ecosystem.
For instance both Vue and Svelte took years to support TypeScript, and their integrations were brittle and often incompatible with test tooling.
Angular used decorators in a very similar way to what I am describing here. It's a source code annotation in "valid" ecmascript that is compiled away by their custom compiler. Though decorators are now abandoned and Angular still requires a lot of custom tooling to work (e.g, try to build an Angular project with a custom rspack configuration).
JSX/TSX has preferential treatment in this regard as it's a macro that's built into tsc - no other framework has this advantage.
Chicken and egg problem. JSX is supported because it's popular. If React decides to push a new syntax I don't see why everyone wouldn't reasonably quickly adapt and support it.
> 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)
Maybe if they compiled away their runtime like svelte and somewhat like angular, then running SSR would be faster.
SSR 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.
Sounds a little like hooks.
A purist approach with short term thinking got everyone deep in a rabbit hole with too many pitfalls.
Especially cuz the vast majority of sites can either just be client rendered SPA's or server rendered multipage apps. There is no need for the complexity for most sites and yet this is the default for pretty much all js frameworks...
They are taking care of the customers. The customers are front-end dev with little experience in servers, back-end and networking. So they want to run some code that changes state without having to deal with all of that infra and complexity. Preferably while remaining in the "React state". That is the attraction of Nextjs and RSC.
[dead]
Because Facebook has a budget for R&D, which works out to several salaries, and React is one of the biggest technical assets they have, so it's someone full time job to develop features and new versions of React to increase the moat and stock value of Meta.
It works out because it keeps a workforce of React Developers on their feet, learning about the new features, rather than doing other stuff. It's like SaSS for developers, only instead of paying a monthly subscription in cash, you have to pay a monthly subscription in man-hours.
I couldn't agree more. I'll probably switch from React to something like ArrowJS in my personal work:
https://www.arrow-js.com/docs/
It makes it easy to have a central JSON-like state object representing what's on the page, then have components watch that for changes and re-render. That avoids the opaqueness of Redux and promise chains, which can be difficult to examine and debug (unless we add browser extensions for that stuff, which feels like a code smell).
I've also heard heard good things about Astro, which can wrap components written in other frameworks (like React) so that a total rewrite can be avoided:
https://docs.astro.build/en/guides/imports/
I'm way outside my wheelhouse on this as a backend developer, so if anyone knows the actual names of the frameworks I'm trying to remember (hah), please let us know.
IMHO React creates far more problems than it solves:
I'll just stop there. The more I learn about React, the less I like it. That's one of the primary ways that I know that there's no there there when learning new tools. I also had the same experience with the magic convention over configuration in Ruby.What's really going on here, and what I would like to work on if I ever win the internet lottery (unlikely now with the arrival of AI since app sales will soon plummet along with website traffic) is a distributed logic flow. In other words, a framework where developers write a single thread of execution that doesn't care if it's running on backend or frontend, that handles all state synchronization, preferably favoring a deterministic fork/join runtime like Go over async behavior with promise chains. It would work a bit like a conflict-free replicated data type (CRDT) or software transactional memory (STM) but with full atomicity/consistency/isolation/durability (ACID) compliance. So we could finally get back to writing what looks like backend code in Node.js, PHP/Laravel, whatever, but have it run in the browser too so that users can lose their internet connection and merge conflicts "just work" when they go back online.
Somewhat ironically, I thought that was how Node.js worked before I learned it, where maybe we could wrap portions of the code to have @backend {} or @frontend {} annotations that told it where to run. I never dreamed that it would go through so much handwaving to even allow module imports in the browser!
But instead, it seems that framework maintainers that reached any level of success just pulled up the ladder behind them, doing little or nothing to advance the status quo. Never donating to groups working from first principles. Never rocking the boat by criticizing established norms. Just joining all of the other yes men to spread that gospel of "I've got mine" to the highest financial and political levels.
So much of this feels like having to send developers to the end of the earth to cater to the runtime that I question if it's even programming anymore. It would be like having people write the low-level RTF codewords in MS word rather than just typing documents via WYSIWYG. We seem to have all lost our collective minds ..the emperor has no clothes.
> do we really need this when Javascript has template literals now
yea? JSX is much more than templating.
But then there are packages like htm that are doing basically the same thing with just tagged templates.
For a single page of HTML, ArrowJS's site loads really slow. I sat for almost a full second on just the header showing.
Yikes I didn't know that! I haven't actually used it yet hah.
For a bit of context, I come from writing blitters on 8 MHz Mac Plusses, so I have a blind spot around slowness. Basically, that nothing should ever be slow today with GHz computers. So most slowness isn't a conceptual flaw, but an inefficient implementation.
These alternative frameworks are generally small enough that it might be kind of fun to stress test them and contribute some performance improvements. Especially with AI, I really have no excuse anymore.
Edit: after pondering this for 2 seconds, I suspect that it's actually a problem with backend requests. It may have some synchronous behavior (which I want) or layout dependency issues that force it to wait until all responses have arrived before rendering. That's a harder problem, but not insurmountable. Also things like this irk me, because browsers largely solved progressive layout in the 1990s and we seem to have lost that knowledge.
> I also had the same experience with the magic convention over configuration in Ruby.
I'm not sure what this is a reference to? Is it actually about Rails?
Nobody is using Redux any more, and it's even publically discouraged by the creator. It's a legacy system and including it in your problems list just makes me think you have no React experience and no idea what you are talking about (beyond technical yapping also Redux as a product still achieved what it tried to solve so your dx doesn't even matter).
Firebase in this context is just a database and how you poll data on client or server from it. Nonsensical reference again.
I love reading this while my boss is pushing "redux everything" as the next step in our (React 17) codebase...
I suspect the commit to fix is:
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.
It could also be https://github.com/facebook/react/commit/7dc903cd29dac55efb4... ("This also fixes a critical security vulnerability.")
It does the same thing here, too: https://github.com/facebook/react/commit/7dc903cd29dac55efb4...
> 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
> Cloudflare WAF proactively protects against React vulnerability
https://blog.cloudflare.com/waf-rules-react-vulnerability/
We 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.
Does AWS WAF have a mitigation in place?
Yes, AWS WAF rule is in AWSManagedRulesKnownBadInputsRuleSet https://aws.amazon.com/security/security-bulletins/rss/aws-2...
Same for Netlify: https://www.netlify.com/changelog/2025-12-03-react-security-...
and Deno Deploy/Subhosting: https://deno.com/blog/react-server-functions-rce
I patched and rebuilt what I could and added custom Crowdsec WAF rules for this, in case I missed something.
I'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
very interesting to read.
However, if I am reading this correctly, your PoC falls in the category described here: https://react2shell.com/
> Anything that requires the developer to have explicitly exposed dangerous functionality to the client is not a valid PoC. Common examples we've seen in supposed "PoCs" are vm#runInThisContext, child_process#exec, and fs#writeFile.
> This would only be exploitable if you had consciously chosen to let clients invoke these, which would be dangerous no matter what. The genuine vulnerability does not have this constraint. In Next.js, the list of server functions is managed for you, and does not contain these.
Context: This is from Lachlan Davidson, the reporter of the vulnerability
I 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?
I'v updated the code, try it now with server-realistic.js:
1. npm start 2. npm run exploit
I'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.
FYI as of just now, the author has (correctly) added a disclaimer that this poc doesnt quite work.
The 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://github.com/ejpir/CVE-2025-55182-poc/issues/1#issueco...
Thanks for the writeup, it's incredible!
The 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 and https://react2shell.com/
Your lump of AI-generated slop has detracted from the response to an important vulnerability. Congratulations. Your PoC is invalid and you should delete it.
HMU, proud owner of slopcop.ai and have been itching to put it to good use.
CVE 10.0 is bonkers for a project this widely used
The 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
That 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.
As 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.
It's not a transitive dependency, it's just literally bundled into nextjs, I'm guessing to avoid issues with fragile builds.
why is it not normal for CI pipelines to cache these things? its a huge waste of compute and network.
It'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.
These often do get cached at CDNs inside of the consuming data centers. Even the ISP will cache these kind of things too.
The 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.
Unfortunately, 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.
A 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.
Regardless 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?
React is widely used, react server components not so much.
Next.js is still pretty damn widely used.
Next.js/RSC has become the new PHP :)
I guess now we'll see more bots scanning websites for "/_next" path rather than "/wp-content".
Inevitable 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.
Maybe 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.
JavaScript 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.
In light of this discussion:
https://news.ycombinator.com/item?id=46141771
that is an interesting observation.
I 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.
More detail in the React Blog post here https://react.dev/blog/2025/12/03/critical-security-vulnerab...
You can't have Vercel without RCE.
I 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.
POC: https://github.com/Ashwesker/Blackash-CVE-2025-55182/
This doesn't look real to me. I don't believe a `_next/static/chunks/react-flight` endpoint even exists.
Link should go to: https://react.dev/blog/2025/12/03/critical-security-vulnerab...
till 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.
>now cz of the complexity I refuse to work with react.
What do you like to work with now?
Right - you can NOT tell me that a sufficiently complex application using HTMX is easier to reason about than React. I've had to deal with a complex HTMX codebase and it is a nightmare.
Right - you can NOT tell me that a sufficiently simple application using React is easier to reason about than HTMX. I've had to deal with a simple React codebase and it is a nightmare.
They don't address the exact same markets.
Yeah… one of them addresses a market populated by hundreds of thousands of developers with extensive professional experience in the framework, and the other addresses a niche of Python developers who refused to learn JavaScript until somebody hid it from them and called it hypermedia.
100’s of thousands used to use php too :) most developers (roughly 97.56% are terrible/incompetent so going with the herd should tell you you are on the wrong train :)
Thousands of developers still use PHP… and even more users… Wordpress (43% of web), Facebook (billions of users), Wikipedia (billions of users)…. all PHP.
htmx is a a toy, mildly amusing to play with, built on an insecure foundation that bypasses basic browser security controls and hands a blob of JavaScript to a bunch of backend developers who can’t be bothered to learn it because they think they know better…
No serious project uses htmx and none ever will, because it becomes an unmaintainable mess by the third developer and second year of development.
“No serious project uses [insert any framework/language/…] and none ever will, because it becomes an unmaintainable mess by the third developer and second year of development” if team is incompetent
They 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
But 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.
Yep! It’s really hard to reason in Next about when things happen on the server vs client. This makes it harder to make things secure.
You can create clean separation in your code to make this easier to understand but it’s not well enforced by default.
Just because something is made possible and you can do it doesn't mean you should!
The criticism is that by allowing you to do something you shouldn't, there isn't any benefit to be had, even if that system allows you to do something you couldn't before.
You can optionally enhance it and use React on the client. Doing that with HTMX is doable with "islands" but a bit more of a pain in the ass - and you'll struggle hard if you attempt to share client state across pages. Actually there are just a lot of little gotchas with the htmx approach
I mean it's a lot of complexity but ideally you shouldn't bring it in unless you actually need it. These solutions do solve real problems. The only issue is people try to use it everywhere. I don't use RSC, standard SPAs are fine for my projects and simpler
React lets you inflate your salary.
easier/more reactivity, doesnt require your api responses to be text parsable to html
It's almost like trying to magically wire up your frontend to the backend through magical functions is a bad idea.
This 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
One 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.
ikr, no way this could have been predicted and warned about for months and months before now.
CV driven development needs new ideas for resume padding regardless of whether the idea is good or bad. Then you get this
Look at the money they’ve made to see if it was a bad idea or not.
I don't think money is a good proxy for idea quality. AI? Blockchain? Crime in general? Plenty of bad ideas make a whole lot of money.
Enron made boat loads.
Anyone know how Tanstack Start isn't affected?
TanStack Start has its own implementation of 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.
They haven't implemented RSC yet.
This 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.
I 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?
Part 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.
You 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.
I'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
It's an RPC. They're half a century old. Java had RMI within a year of existence. [0]
> In remote procedure call systems, client-side stub code must be generated and linked into a client before a remote procedure call can be done. This code may be either statically linked into the client or linked in at run-time via dynamic linking with libraries available locally or over a network file system. In either the case of static or dynamic linking, the specific code to handle an RPC must be available to the client machine in compiled form... Dynamic stub loading is used only when code for a needed stub is not already available. The argument and return types specified in the remote interfaces are made available using the same mechanism. Loading arbitrary classes into clients or servers presents a potential security problem;
https://pdos.csail.mit.edu/archive/6.824-2009/papers/waldo-r...
There 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.
"You can run JavaScript on the frontend and the backend!" always struck me as the weakest marketing ever. I've been around the block, and which language the web application uses is hardly any sort of limiting factor in ease of development. (And ideally, your frontend has as little JavaScript as possible anyway.) There is very little that can't be programmed in a more web-friendly way, like POSTing forms and rendering HTML templates. Sure, I guess Google Maps can just be a fat application, but like... every eCommerce site doesn't need to be some big ball of React mud, I promise.
I think the main problem was that 'the standard' wasn't evolving fast enough to solve the bulk of the issues around input validation and UI building so we got this crap language that is powerful enough to hide a thousand footguns in a few lines of code. It will never be perfect so it will generate this kind of issue for the next century or so.
If instead, we would have gradually expanded the HTML standard without adding a fully functional programming language into the content stream we would have had better consistency between websites and applications and we would treat the browser like what it is: a content delivery mechanism, not an application programming platform. That's the core mistake as far as I'm concerned.
to 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.
It'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.
> There 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.
First, "same code on the client and the serve" is wrong. Since when do RSC's run on both the client and the server?
Also, you honestly believe that wanting to use the same language across paradigms is a "coding bootcamp" thing lol? That something like Blazor was born out of a coding bootcamp?
Have you ever built a web app? Both front and back end? Have you ever had to deal with the tension of duplicating code? Models, validation, ideas?
If you answered yes to those questions but still don't see how de-duplicating code like that can be important, than I'm 100% positive you're still in the boot camp.
Not even remotely similar.
Care to elaborate on what it is like, then?
Actually he's more or less correct.
Is there some sort of example exploit somewhere?
[dead]
https://github.com/ejpir/CVE-2025-55182-poc
This 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
I will believe it works when it is demonstrated against a create-next-app project.
The 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://github.com/ejpir/CVE-2025-55182-poc/issues/1#issueco...
Next is only good for it's static build, once it drops support for that I'm out.
there 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.
The 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.
The 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.
Incredibile, completely unexpected, no one ever ever pointed out that RCS and most of the rest was not good software. No one, no one.
Do you really need React Server Conponents or even Server Side Rendering?
Before 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.
Thank you. It's disappointing that you have to say this on a website full of supposedly technically proficient people.
It'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.
Yes. Web applications were impossible before these libraries.
If you truly believe that than we must really be moving backwards
I think they have a point, before cgi-bin it was almost impossible to have a real web application. It took a decade for server-side rendering to fall out of favour. Flash websites and Gmail starting to become seriously interactive in the mid 2000s were the start of frontend-first web applications, but even those relied on the backend to provide them with an initial data set to make performance usable.
No, they were not. They required a lot more round-trips to the server though, and rendering the results was a lot harder. But if you think of a browser as an intelligent terminal there is no reason why you couldn't run the application server side and display the UI locally, that's just a matter of defining some extra primitives. Graphical terminals were made first in the 60's or so.
Of course you do, in certain cases making less round-trips to the server is just straight more efficient
I'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.
one fixed... one bazillion to go...
static builds save the day.
I am betting it would be exploited in the wild in the next few days, buckle up!
The CVE says the that flaw is in React Server Components, which implies strongly that this is a RCE on the backend (!!), not the client.
I suspect client developers are also affected at least to the extent that they need to explain this RCE to CVE driven management.
Where else would it be? What would an RCE of the client even mean?
it would be an RCE on your own machine :D
The 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.
LCE
Bravo.
dupe: https://news.ycombinator.com/item?id=46136067
[flagged]
[dead]
[flagged]
This 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.
It 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-vulnerab...
[2] https://react.dev/reference/rsc/server-functions
No. You cannot find all vulnerable code by grepping for ”use server”, for instance.
So that’s your “it’s not related to use server” argument?
That seems like it could be a quote from their hardening guide.
I think the top-level comment was criticizing the entire feature (server functions) enabled by "use server". The vulnerability is in this feature, so (as I understand it) you're correct that grepping for "use server" won't find the vulnerable code, but if there was no such thing as "use server" the vulnerability wouldn't exist.
I'm sorry, but you're incorrect. That is genuinely how this CVE works. All (and only) code with "use server" was vulnerable.
The official blog post disagrees.
> Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.
JavaScript 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/
Sorry you feel that way.
TypeScript is really nice though.
> TypeScript is really nice though.
Even if that's true, it is irrelevant.
... if your baseline is JavaScript.