8 ms·

Denial of service and source code exposure in React Server Components

346 points by sangeeth96 10mo ago

See also: https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-exploitation-threat-brief/ https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-..., https://nextjs.org/blog/security-update-2025-12-11 https://nextjs.org/blog/security-update-2025-12-11

chuckadams 10mo ago
I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."
- tshaddox 10mo ago
  That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.
  - reactordev 10mo ago
    Correct, their main purpose is ecosystem lock-in. Because why return json when you can return html. Why even build a SPA when the old school model of server-side includes and PHP worked just fine? TS with koa and htmx if you must but server-side react components are kind of a waste of time. Give me one example where server side react components are the answer over a fetch and json or just fetching an html page?
    - tshaddox 10mo ago
      I like RSCs and mostly dislike SPAs, but I also understand your sentiment.
    - nawgz 10mo ago
      The only example that has any traction in my view are web-shops, which claim that time-to-render and time-to-interactivity are critical for customer retention. Surely there are not so many people building e-commerce sites that server components should have ever become so popular.
      - skydhash 10mo ago
        The thing is time to render and interactivity is much more reliant on the database queries and the internet connection of the user than anything else. Now instead of a spinner or a progress bar in the toolbar of the browser, now I got skeleton loaders and use half of GB for one tab.
        nawgz 10mo ago
        Not to defend the practice, I’ve never partaken, but I think there’s some legit timing arguments that a server renderer can integrate more requests faster thanks to being collocated with services and dbs.
        reactordev 10mo ago
        which brings me back to my main point of the web 1.0 architecture. Serving pages from the server-side, where the data lives, and we've come full circle.
    - deleted 10mo ago
      [deleted]
  - robertoandred 10mo ago
    Sure they are. Next sites are SPAs.
- deleted 10mo ago
  [deleted]
- rustystump 10mo ago
  It also decoupled fe and backend. You could use the same apis for say mobile, desktop and web. Teams didnt have to cross streams allowing for deeper expertise on each side. Now they are shoving server rendering into react native…
- pjmlp 10mo ago
  Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.
  - sangeeth96 10mo ago
    > Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks. I can understand the dislike for Next but this is such a poor comparison. If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.
    - Atotalnoob 10mo ago
      Blazor? Razor pages?
    - brazukadev 10mo ago
      We are having this discussion because at some point, the people behind React decided it should be profitable and made it become the drug gateway for NextJS/Vercel
      - pjmlp 10mo ago
        Worse, because Vercel then started its marketing wave, thus many SaaS products only support React/Next.js as extensions points. Using anything else requires yak shaving instead of coding the application code. That is the only reason I get to use them.
    - deleted 10mo ago
      [deleted]
    - tacker2000 10mo ago
      How does Next accomplish more than a PHP/Ruby/whatever backend with a React frontend? If anything the latter is much easier to maintain and to develop for.
- hedayet 10mo ago
  I'd be interested in adopting a sole-purpose framework like that.
- moomoo11 10mo ago
  I think people just never understood SPA. Like with almost everything people then shit on something they don’t understand.
- _jzlw 10mo ago
  It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.
  - c0balt 10mo ago
    Hotwire et al are also doing part of this. It isn't a new concept but it seems to come and go it terms of popularity
  - McGlockenshire 10mo ago
    > And we're all just supposed to act like this isn't absolutely insane. This is insane to you only if you didn't experience the emergence of this technique 20-25 years ago. Almost all server-side templates were already partials of some sort in almost all the server-side environments, so why not just send the filled in partial? Business logic belongs on the server, not the client. Never the client. The instant you start having to make the client smart enough to think about business logic, you are doomed.
    - crubier 10mo ago
      > The instant you start having to make the client smart enough to think about business logic, you are doomed. Could you explain more here? What do you consider "business logic". Context: I have a client app to fly drone using gamepad, mouse and keyboard, and video feedback and maps, and drone tasking etc.
  - CharlieDigital 10mo ago
    It's kinda nice. Main downside is the hot reload is not nearly as nice as TS. But the coding experience with a C# BE/stack is really nice for admin/internal tools.
  - vbezhenar 10mo ago
    I saw this kind of interactivity in Apache Wicket Java framework. It's very interesting approach.
- epolanski 10mo ago
  Yeah, but then people started building bloated static websites with those libraries instead of using a saner template engine + javascript approach which is fast, easy to cache, debug, and has stellar performance and SEO. Little it helped that even React developers were saying that it was the wrong tool for plenty use cases. Worst of all? The entire nuance of choosing the right tool for the job has been long lost on most developers. Even the comments I read on HN make me question where the engineering part of the job starts.
  - CodingJeebus 10mo ago
    It also doesn't help that non-technical stakeholders sometimes want a say in a tech stack conversation as well. I've been at more than one company where either the product team or the acquiring firm wanted us to migrate away from a tried and true Rails setup to a fullstack JS platform simply because they either wanted the UI development flexibility or to not have to hire Ruby devs. Non-technical MBA's seem to have a hard time grasping that a JS-only platform is not a panacea and comes with serious tradeoffs.
rikafurude21 10mo ago
Im confused, did the update from last week for the RCE bug also include fixes for these new CVEs or will I need to update again? npm audit says theres no issues
- billywhizz 10mo ago
  is it not obvious? > These issues are present in the patches published last week. > The patches published last week are vulnerable. > If you already updated for the Critical Security Vulnerability, you will need to update again.
- rickhanlonii 10mo ago
  GitHub has to review the advisories and publish it for it to show in `npm audit`, so it's delayed.
- theogravity 10mo ago
  You need to update again.
  - cluckindan 10mo ago
    This could be the Next.js motto.
    - kyleee 10mo ago
      You need to upgrade again, and no the docs aren’t finished (and they won’t be before the new new version).
  - qingcharles 10mo ago
    My Umami stats box got "pwned" about 15 mins after the last CVE was published and I spent an hour or so cleaning up that mess and upgrading everything. Not looking forward to doing it again today.
ChrisArchitect 10mo ago
Related: React2Shell and related RSC vulnerabilities threat brief - Cloudflare https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-exploitation-threat-brief/ https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-... (https://news.ycombinator.com/item?id=46237515 https://news.ycombinator.com/item?id=46237515)
sangeeth96 10mo ago
Next team just published this: https://nextjs.org/blog/security-update-2025-12-11 https://nextjs.org/blog/security-update-2025-12-11 Seems to affect 14.x, 15.x and 16.x.
carlcortright 10mo ago
dammit
tagraves 10mo ago
It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
- treesknees 10mo ago
  What’s concerning about it? The first thing I thought when I read the headline was “wow, another react CVE?” It’s not a justification, it’s an explanation to the most obvious immediate question.
  - vcarl 10mo ago
    It's definitely a defensive statement, proactively covering the situation as "normal". Normal it may be, but emphasizing that in the limited space of a tweet thread definitely indicates where their mind is on this, I'd think.
    - treesknees 10mo ago
      Are you reading a different link? This statement is on a React blog post, not a Twitter thread.
  - tom1337 10mo ago
    But it is another React CVE. Doesn't really matter why it was uncovered, it's bad that it existed either way
  - brazukadev 10mo ago
    an insecure software will have multiple CVEs, not necessarily related to each other. Those 3 are probably not the only ones.
- zwnow 10mo ago
  Welcome to the React, Next, Vercel ecosystem. Our tech may be shite but we look fancy.
rickhanlonii 10mo ago
After Log4Shell, additional CVEs were reported as well. It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.
- PKop 10mo ago
  The vulnerabilities existing is not a consequence of previous CVEs so this seems like an irrelevant non sequitur to keep mentioning everywhere.
- deleted 10mo ago
  [deleted]
bflesch 10mo ago
So we have a new React CVE and tomorrow is Friday, so please be prepared for a new outage brought to you by the super-engineers at Cloudflare.
- venturecruelty 10mo ago
  Look on the bright side: maybe GitHub will be down first, so nobody can upload any vulnerable code right before the weekend.
simonw 10mo ago
React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server. It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we've recently seen, is a risky spot in terms of potential security vulnerabilities.
- tom1337 10mo ago
  I was a fan of NextJS in the pages router era. You knew exactly where the line was between server and client code and it was pretty easy to keep track of that. Then I've began a new project and wanted to try out app router and I hated it. So many (to me common things) where just not possible because the code can run in the client and on the server so Headers might not always be available and it was just pure confusion whats running where.
  - dawnerd 10mo ago
    I pretty much dumped a side project that was using next over the new router. It's so much more convoluted, way too many limitations. Who even really wants to make database queries in front end code? That's sketchy as heck.
    - Frotag 10mo ago
      A lot of functionality is obviously designed for Vercel's hosting platform, with local equivalents as an afterthought.
  - Uehreka 10mo ago
    I think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear anyone say they like the App Router (and this is a pretty contrarian site, so if they existed I’d expect to see them here).
hedayet 10mo ago
I wonder what does these vulnerabilities mean for Facebook. As per my knowledge, Facebook's the biggest web app written in React.
- jsheard 10mo ago
  Does Facebook actually use RSC? I thought it was mainly pushed by the Nextjs/Vercel side of the React team.
  - samdoesnothing 10mo ago
    No they don't. I think Meta is just big enough that they don't really care what is happening with React anymore haha.
  - acemarke 10mo ago
    No, but it's primarily because Meta has their own server infrastructure already. RSCs are essentially the React team trying to generalize the data fetching patterns from Meta's infrastructure into React itself so they can be used more broadly. I wrote an extensive post and did a conference talk earlier this year recapping the overall development history and intent of RSCs, as best as I understand it from a mostly-external perspective: - https://blog.isquaredsoftware.com/2025/06/react-community-2025/ https://blog.isquaredsoftware.com/2025/06/react-community-20... - https://blog.isquaredsoftware.com/2025/06/presentations-react-community-2025/ https://blog.isquaredsoftware.com/2025/06/presentations-reac...
    - brazukadev 10mo ago
      So contrary to all other changes, this one was not done for Facebook to use. What was the reason behind RSC then?
      - cluckindan 10mo ago
        Market capture?
shadowgovt 10mo ago
Oh boy, I somehow missed that React was offering these. Google has a similar technology in-house, and it was a bit of a nightmare a few years back; the necessary steps to get it working correctly required some very delicate dancing. I assume it's gotten better given time.
aatd86 10mo ago
LOL. I must have divination powers. I am currently working on a UI framework and opened an issue just 3 weeks ago that says: *** Seems that server functions are all the rage. We are unlikely to have them. The main reason is that it ties the frontend and the backend together in undesirable ways. It forces a js backend upon people (what if I want to use Go for instance). The api is not client agnostic anymore. How to specify middleware is not clear. Requires a bundler, so destroys isomorphism (isomorphic code requires no difference between the client and the server/ environment agnostic). Even if it requires a bundler because it separates client and server implementation files, it blurs the data scoping (especially worrying for sensitive data) Do one thing and do it well: separate frontend and backend. It might be something that is useful for people who only plan on having a javascript web frontend server separate from the API server that links to the backend service. Besides, it is really not obvious to me how it becomes architecturally clearer. It would double the work in terms of security wrt authorization etc. This is at least not a generic pattern. So I'd tend to go opposite to the trend and say no. Who knows, we might revisit it if anything changes in the future. *** And boy, look at the future 3 weeks later... To be fair, the one good thing is that they are hardening their implementation thanks to these discoveries. But still seems to me that this is wholly unnecessary and possibly will never be safe enough. Anyway, not to toot my own horn, I know for a fact these things are difficult. Just found the timing funny. :)
- brazukadev 10mo ago
  I'm curious about your UI framework, is it public?
  - aatd86 10mo ago
    Not public yet. Under review.
ashishb 10mo ago
The JavaScript fanatics will downvote me for saying this, but I'll say this, "using a single JavaScript codebase on your client-side and server-side is like cooking food in your toilet, sooner or later, contamination is guaranteed" [1] 1 - https://ashishb.net/tech/javascript/ https://ashishb.net/tech/javascript/
- leptons 10mo ago
  This isn't a Javascript problem, this is a React problem. You could theoretically rewrite React and RSC in any language and the outcome would be the same. Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.
  - ashishb 10mo ago
    > This isn't a Javascript problem, this is a React problem. It happened with Next.js as well https://github.com/vercel/next.js/discussions/11106 https://github.com/vercel/next.js/discussions/11106 > Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript. Yes. And since Python does not natively run in the browser, that mistake never happens. With JavaScript, the desire to have "backend and frontend in a single codebase" requires active resistance.
    - rounce 10mo ago
      > It happened with Next.js as well It's the same vulnerabilities because Next uses the vulnerable parts of React. Your rational is quite poor as I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? Look, many of us also strongly dislike JavaScript but generally that distaste is based on its actual shortcomings and failures, you don't have to invent new ones plenty already exist.
      - ashishb 10mo ago
        > I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? If you have a single codebase for Go-based code running in an untrusted browser (the "toilet") and a trusted backend (the "kitchen"), then the same contamination is highly likely.
yread 10mo ago
Were there not enough eyes on React Server Components before the patches from last week?
- Inviz 10mo ago
  have you seen the code of next.js? its completely impenetrable, and the packages have legacy versions of the same files coexisting, it's like huge hairball
- manfre 10mo ago
  I've noticed a pattern in the security reports for a project I'm involved in. After a CVE is released, for the next month or so there will likely be additional reports targeting the same (or similar) areas of the framework. There is definitely a competitive spirit amongst security researchers as they try to get more CVEs credited to them (and potentially bounties).
hollowturtle 10mo ago
Wouldn't make more sense keeping React smaller and left those features to frameworks? I liked it more when it was marketed as the View in MVC. Surely can still be used like that today but it still feels bloated
- ivanjermakov 10mo ago
  git checkout v15.0.0 There we go.
  - hollowturtle 10mo ago
    Can I have v15 with the rendering optimizations of further versions?
- TZubiri 10mo ago
  But the react-components are a separate library, they are not installed by default
  - hollowturtle 10mo ago
    ? afaik react server components made it to core
    - silverwind 10mo ago
      They shouldn't be loaded in a React SPA at least, e.g. `react-dom` and `react` packages should be unaffected.
      - TZubiri 10mo ago
        So they are part of the standard distribution (like through npm install react), but are unused by default? Something like that?
        danabramov 10mo ago
bitbasher 10mo ago
I remember when my greatest fear was sql injection. It’s great to see we have become more secure with our technology.
_heimdall 10mo ago
I do hope this means we can finally stop hearing about RSC. The idea is an interesting solution to problems that never should exist in the first place.
rvz 10mo ago
React patches one vulnerability and two more are revealed, just like a Hydra. At this point you might as well deprecate RSC as it is clearly a contraption for someone trying to justify a promotion at Meta. Maybe they are going to silently remove “Built RSC at Meta!” in their LinkedIn bios after this. So what other vulnerabilities are going to be revealed in React after this one?
- marksomnian 10mo ago
  Meta don’t use RSC: https://bsky.app/profile/en-js.bsky.social/post/3lmvwmr5rfs23 https://bsky.app/profile/en-js.bsky.social/post/3lmvwmr5rfs2... > We are not using RSC at Meta yet, bc of limits of our packaging infra (it’s great at different things) and because Relay+GraphQL gives us many of the same benefits as RSCs. But we are fans and users of server driven UI and incrementally working toward RSC. (as of April 2025)
ginkgotree 10mo ago
I'm only surprised it took this long for an exposure of backend data to the front end to be discovered in RSC
hbbio 10mo ago
We pioneered a lot of things with Opa, 15 years ago now. Opa featured automatic code "splitting" between client and server, introduced the JSX syntax although it wasn't called that way (Jordan at Facebook used Opa before creating React, but the discussions around the syntax happened at W3C notably with another Facebook employee, Tobie). Since the Opa compiler was implemented in OCaml (we were looking more like Svelte than React as a pure lib), we performed a lot of statical analysis to prevent the wide range of attacks on frontend code (XSS, CSRF, etc.) and backend code. The Opa compiler became a huge beast in part because of that. In retrospect, better separation of concerns and foregoing completely the idea of automatic code splitting (what React Server Components is) or even having a single app semantics is probably better for the near future. Our vision (way too early), was that we could design a simple language for the semantics and a perfect advanced compiler that would magically output both the client and the server from that specification. Maybe it's still doable with deterministic methods. Maybe LLMs will get to automatic code generation of all parts in one shot before.
- danabramov 10mo ago
  Note that the exploits so far haven’t had much to do with “server code/data getting bundled into the client code” or similar which you’re alluding to. Also, RSC does not try to “guess” how to split code — it is deterministic and always user-controlled. The vulnerabilities so far were weaknesses in the (de)serializer stemming from the dynamism of JavaScript — ability to hijack root object prototype, ability to toString functions to get their code, ability to override a Promise then implementation, ability to construct a function from a string. The patches are patching the (de)serializer to work around those dynamic pieces of JavaScript to avoid those gaps. This is similar to mistakes in parsers where they’re fooled by properties called hasOwnProperty/constructor/etc. The serialization format is essentially “JSON with Promises and code chunk references”, and it seems like there’s enough pieces where dynamic nature of JS can leak that needed to be plugged. Hopefully with more scrutiny on the protocol, these will be well-understood by the team. The surface area there isn’t growing much anymore (it’s close to being feature-complete), and the (de)serializers themselves are roughly 5 kloc each. The problem you had in Opa is solved in RSC with build-time assertions (import "server-only" is the server environment poison pill, and import "client-only" is the client environment poison pill). These poison pills work transitively up the module import stack and are statically enforced and prevent code (eg DB code, secrets, etc) from being pulled into the wrong environment. Of course this doesn’t prevent bugs in the (de)serializer but it’s why the overall approach is sound, in the absence of (de)serialization vulnerabilities.
ydj 10mo ago
I noticed requests that were exploiting the vulnerability were turning into timeouts pretty much immediately after rolling out the patch. I’m surprised it took so long for it to be announced.
greatgib 10mo ago
In my point of view, this is well deserved to idiots that are seriously using RSC in production, despite that being a very bad idea...
delifue 10mo ago
Any attempt that blurs boundary between client and server is unsafe.
delifue 10mo ago
React server component is frontend's attempt of "eating" backend. On the contrary, HTMX is the attempt of backend "eating" frontend. HTMX preserves the boundary between client and server so it's more safe in backend, but less safe in frontend (risk of XSS).
- yawaramin 10mo ago
  Htmx doesn't really have an XSS problem, this was solved by templating language long ago. See https://htmx.org/essays/web-security-basics-with-htmx/#always-use-an-auto-escaping-template-engine https://htmx.org/essays/web-security-basics-with-htmx/#alway...
jgalt212 10mo ago
I remember some podcast interview with Miško Hevery talking about how Qwik was very emphatic about what code ran on the server and what ran on the client. Seems self-evident and prescient. It was a great interview as Miško Hevery is extremely articulate about the problems at hand. If I find it, I'll post.
tills13 10mo ago
Y'all are so pessimistic. React Server Components are great. React is a complex piece of software. Bugs happen.
- ipnon 10mo ago
  Personally I prefer simple software without bugs! This security vulnerability highlights a serious issue with React. It’s a SPA framework, a server side framework, and a functional component library all at the same time. And it’s apparently getting so complex that it’s introducing source code exposures. I’m not interested in flame wars per se, but I can tell you there are better alternatives, and that the closer you stay towards targeting the browser itself the better, because browser APIs are at least an order of magnitude more secure and performant than equivalent JS operations.
WatchDog 10mo ago
When I looked into RSC last week, I was struck by how complex it was, and how little documentation there seems to be on it. In fairness react present it as an "experimental" library, although that didn't stop nextjs from widely deploying it. I suspect there will be many more security issues found in it over the next few weeks. Nextjs ups the complexity orders of magnitude, I couldn't even figure out how to set any breakpoints on the RSC code within next. Next vendors most of their dependencies, and they have an enormously complex build system. The benefits that next and RSC offer, really don't seem to be worth the cost.
- firtoz 10mo ago
  People did complain about next exposing "react, not ready for production" things as "the latest and greatest thing from nextjs" for quite a while now I had moved off nextjs for reasons like these, the mind load was getting too heavy for not too much benefit
- mexicocitinluez 10mo ago
  > and how little documentation there seems to be on it DISCLAIMER: After years of using Angular/Ember/Jquery/VanillaJs, jumping into React's functional components made me enjoy building front-ends again (and still remains that way to this very day). That being said: This has been maybe the biggest issue in React land for the last 5 years at least. And not just for RSC, but across the board. It took them forever to put out clear guidance on how to start a new React project. They STILL refuse to even acknowledge CRA exist(s/ed). The maintainers have actively fought with library makers on this exact point, over and over and over again. The new useEffect docs are great, but years late. It'll take another 3-4 years before teh code LLMs spit out even resemble that guidance because of it. And like sure, in 2020 maybe it didn't make sense to spell out the internals of RSC because it was still in active development. But it's 2025. And people are using it for real things. Either you want people to be successful or you want to put out shiny new toys. Maybe Guillermo needs to stop palling around with war criminals and actually build some shit. It might be one of the most absurd things about React's team: their constitutional refusal to provide good docs until they're backed into a corner.
andrewmcwatters 10mo ago
[dead]
kpozin 10mo ago
A framework designed to blur the line between code running on the client and code running on the server — forgot the distinction between code running on the client and code running on the server. I don't know what they expected. (The same confusion comes up regularly whenever you touch Next.js apps.)
aabhay 10mo ago
“use insecure”
dizlexic 10mo ago
I'm not going to let go my argument with Dan Abramov on x 3 years ago where he held up rsc as an amazing feature and i told him over and over he was making a foot gun. tahdah! I'm a nobody PHP dev. He's a brilliant developer. I can't understand why he couldn't see this coming.
- peacebeard 10mo ago
  You might be more brilliant than you think.
- danabramov 10mo ago
  For what it’s worth, I’ve just built an app for myself with RSC, and I’m still a huge fan of this way of building and structuring web software. I agree I underestimated the likelihood of bugs like this in the protocol, though that’s different from most discussions I’ve had about RSC (where concerns were about user code). The protocol itself has a fairly limited surface area (the serializer and deserializer are a few kloc each), and that’s where all of the exploits so far have concentrated. Vulnerabilities are frustrating, and this seems to be the first time the protocol is getting a very close look from the security community. I wish this was something the team had done proactively. We’ll probably hear more from the team after things stabilize a bit.
  - brazukadev 10mo ago
    RSC is not a protocol, that is probably one of the reasons it is bad and affected only NextJS - most other server framework struggled and gave up this mistake that was React Server.
- locallost 10mo ago
  I'm not defending React and this feature, and I also don't use it, but when making a statement like that the odds are stacked in your favor. It's much more likely that something's a bad idea than a good idea, just as a baseball player will at best fail just 65-70% of the time at the plate. Saying for every little thing that it's a bad idea will make you right most of the time. But sometimes, occasionally, a moonshot idea becomes a home run. That's why I dislike cynicism and grizzled veterans for whom nothing will ever work.
metta2uall 10mo ago
For the vast majority of projects it seems like the disadvantages of these highly complex RPC systems far exceed the benefits... Not just in terms of security but also the reduced observability compared to simple JSON..
TZubiri 10mo ago
Interesting how DoS ranks higher than code exposure in severity. I personally think it's the other way around, since code exposure increases the odds that a security breach happens, while DoS does not increase chances of exposure, but affects reliability. Obviously we are simplifying a multidimensional severity to one dimension, but I personally think that breaches are more important than reliability. I'd rather have my app go down than be breached. And I don't think it's a trivial difference, if you'd rather have a breach than downtime, you will have a breach.
LittleOtter 10mo ago
Our team is working to fix our Next.js project.It's so painful. Now I'm doubting RSC is a good engineering technology or a good practice.The real world is tradeoffs: RSC really help us improve our develop speed as we have good teamates that has good understanding of fullstack. Do hope such things won't happen again.
- IceDane 10mo ago
  How is it painful? You need to bump a minor version? It took me less than 5 minutes 90% of which was waiting for CI. There's even a tool you can run to do it for you.
phplovesong 10mo ago
SSR is just dumb. Its very rare that you would benefit much from this approach, the only thing you get an complexity bomb exploding in your face. How about either just return html (maybe with htmx), or have a "now classic" SPA. The frontend must be the most over engineered shitshow we as devs have ever created. Its where hype meets the metal.
nathants 10mo ago
Just exchange json. Backend in python/ruby/go/rust. Frontend in javascript/typescript. Scripts in bash/zsh/nushell. One upon a time there was a low amount of friction and boilerplate with this approach, but with Claude and Codex it’s changed from low to none.
- KronisLV 10mo ago
  I really like having a good old RESTful API (well maybe kinda faking the name because don't need HATEOAS usually)! Except I find most front end stacks to lead to either endless configuration (e.g. Vue with Pinia, router, translation, Tailwind, maybe PrimeVue and a bunch of logic for handling sessions and redirects and toast messages and whatnot) and I feel the pull to just go and use Django or Laravel or Ruby on Rails mostly with server side templates - I much prefer that simplicity, even if it feels a bit icky to couple your front end and back end like that.
ManuelKiessling 10mo ago
I really wonder why the swarm intelligence of software developers still hasn’t decided on a single best clearly defined architecture for serving web applications, decades after the building blocks have been in place. Let the server render everything. Let JS render everything, server is only providing the initial div and serves only JSON from then on. Actually let JS render partial HTML rendered on the server! Websockets anyone? Imagine SQL server architecture or iOS development had this kind of ADHS syndrome.
dzonga 10mo ago
react server components is something that should've never existed anyway. are people shipping faster due to them ? or it's all complexity, security vulnerabilities like this. you're not facebook. render html the classic way if you need server rendered html. if you really do need an SPA - which is 5% of the apps out there - then yeah use client side react, vue, svelte etc - none of those RPC server actions etc
- CodingJeebus 10mo ago
  Agreed. Unfortunately, there's an entire content/bootcamp ecosystem pushing this stuff that came of age largely during the tech boom, as well as a bunch of early and mid-career devs and companies that are deeply tied to it. With major VC funding backing projects like Bun, Vercel, etc., I don't think this deeply flawed approach to development is going anywhere because the utopian JS fantasy of "it just works and runs everywhere flawlessly" is the ultimate myth of building for the web.
scotty79 10mo ago
Language with dynamic code evaluation on the server plus fat client-setver protocol that attempts to sync raw objects of the language. What could have gone wrong? I wonder if similar magic fat pipe technologies (like Blazor) have similar vulnerabilities waiting to be discovered. Maybe compiled languaged are safer by default in this scenario, but anything built in Python, PHP, Ruby or any "code is data" language would probably fare similarly poorly.

346 points by sangeeth96 10mo ago

chuckadams 10mo ago

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

tshaddox 10mo ago
That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.
- reactordev 10mo ago
  Correct, their main purpose is ecosystem lock-in. Because why return json when you can return html. Why even build a SPA when the old school model of server-side includes and PHP worked just fine? TS with koa and htmx if you must but server-side react components are kind of a waste of time. Give me one example where server side react components are the answer over a fetch and json or just fetching an html page?
  - tshaddox 10mo ago
    I like RSCs and mostly dislike SPAs, but I also understand your sentiment.
  - nawgz 10mo ago
    The only example that has any traction in my view are web-shops, which claim that time-to-render and time-to-interactivity are critical for customer retention. Surely there are not so many people building e-commerce sites that server components should have ever become so popular.
    - skydhash 10mo ago
      The thing is time to render and interactivity is much more reliant on the database queries and the internet connection of the user than anything else. Now instead of a spinner or a progress bar in the toolbar of the browser, now I got skeleton loaders and use half of GB for one tab.
      - nawgz 10mo ago
        Not to defend the practice, I’ve never partaken, but I think there’s some legit timing arguments that a server renderer can integrate more requests faster thanks to being collocated with services and dbs.
        reactordev 10mo ago
        which brings me back to my main point of the web 1.0 architecture. Serving pages from the server-side, where the data lives, and we've come full circle.
  - deleted 10mo ago
    [deleted]
- robertoandred 10mo ago
  Sure they are. Next sites are SPAs.
deleted 10mo ago
[deleted]
rustystump 10mo ago
It also decoupled fe and backend. You could use the same apis for say mobile, desktop and web. Teams didnt have to cross streams allowing for deeper expertise on each side. Now they are shoving server rendering into react native…
pjmlp 10mo ago
Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.
- sangeeth96 10mo ago
  > Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks. I can understand the dislike for Next but this is such a poor comparison. If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.
  - Atotalnoob 10mo ago
    Blazor? Razor pages?
  - brazukadev 10mo ago
    We are having this discussion because at some point, the people behind React decided it should be profitable and made it become the drug gateway for NextJS/Vercel
    - pjmlp 10mo ago
      Worse, because Vercel then started its marketing wave, thus many SaaS products only support React/Next.js as extensions points. Using anything else requires yak shaving instead of coding the application code. That is the only reason I get to use them.
  - deleted 10mo ago
    [deleted]
  - tacker2000 10mo ago
    How does Next accomplish more than a PHP/Ruby/whatever backend with a React frontend? If anything the latter is much easier to maintain and to develop for.
hedayet 10mo ago
I'd be interested in adopting a sole-purpose framework like that.
moomoo11 10mo ago
I think people just never understood SPA. Like with almost everything people then shit on something they don’t understand.
_jzlw 10mo ago
It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.
- c0balt 10mo ago
  Hotwire et al are also doing part of this. It isn't a new concept but it seems to come and go it terms of popularity
- McGlockenshire 10mo ago
  > And we're all just supposed to act like this isn't absolutely insane. This is insane to you only if you didn't experience the emergence of this technique 20-25 years ago. Almost all server-side templates were already partials of some sort in almost all the server-side environments, so why not just send the filled in partial? Business logic belongs on the server, not the client. Never the client. The instant you start having to make the client smart enough to think about business logic, you are doomed.
  - crubier 10mo ago
    > The instant you start having to make the client smart enough to think about business logic, you are doomed. Could you explain more here? What do you consider "business logic". Context: I have a client app to fly drone using gamepad, mouse and keyboard, and video feedback and maps, and drone tasking etc.
- CharlieDigital 10mo ago
  It's kinda nice. Main downside is the hot reload is not nearly as nice as TS. But the coding experience with a C# BE/stack is really nice for admin/internal tools.
- vbezhenar 10mo ago
  I saw this kind of interactivity in Apache Wicket Java framework. It's very interesting approach.
epolanski 10mo ago
Yeah, but then people started building bloated static websites with those libraries instead of using a saner template engine + javascript approach which is fast, easy to cache, debug, and has stellar performance and SEO. Little it helped that even React developers were saying that it was the wrong tool for plenty use cases. Worst of all? The entire nuance of choosing the right tool for the job has been long lost on most developers. Even the comments I read on HN make me question where the engineering part of the job starts.
- CodingJeebus 10mo ago
  It also doesn't help that non-technical stakeholders sometimes want a say in a tech stack conversation as well. I've been at more than one company where either the product team or the acquiring firm wanted us to migrate away from a tried and true Rails setup to a fullstack JS platform simply because they either wanted the UI development flexibility or to not have to hire Ruby devs. Non-technical MBA's seem to have a hard time grasping that a JS-only platform is not a panacea and comes with serious tradeoffs.

rikafurude21 10mo ago

Im confused, did the update from last week for the RCE bug also include fixes for these new CVEs or will I need to update again? npm audit says theres no issues

billywhizz 10mo ago
is it not obvious? > These issues are present in the patches published last week. > The patches published last week are vulnerable. > If you already updated for the Critical Security Vulnerability, you will need to update again.
rickhanlonii 10mo ago
GitHub has to review the advisories and publish it for it to show in `npm audit`, so it's delayed.
theogravity 10mo ago
You need to update again.
- cluckindan 10mo ago
  This could be the Next.js motto.
  - kyleee 10mo ago
    You need to upgrade again, and no the docs aren’t finished (and they won’t be before the new new version).
- qingcharles 10mo ago
  My Umami stats box got "pwned" about 15 mins after the last CVE was published and I spent an hour or so cleaning up that mess and upgrading everything. Not looking forward to doing it again today.

ChrisArchitect 10mo ago

Related: React2Shell and related RSC vulnerabilities threat brief - Cloudflare https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-exploitation-threat-brief/ https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-... (https://news.ycombinator.com/item?id=46237515 https://news.ycombinator.com/item?id=46237515)

sangeeth96 10mo ago

Next team just published this: https://nextjs.org/blog/security-update-2025-12-11 https://nextjs.org/blog/security-update-2025-12-11 Seems to affect 14.x, 15.x and 16.x.

carlcortright 10mo ago

dammit

tagraves 10mo ago

It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.

treesknees 10mo ago
What’s concerning about it? The first thing I thought when I read the headline was “wow, another react CVE?” It’s not a justification, it’s an explanation to the most obvious immediate question.
- vcarl 10mo ago
  It's definitely a defensive statement, proactively covering the situation as "normal". Normal it may be, but emphasizing that in the limited space of a tweet thread definitely indicates where their mind is on this, I'd think.
  - treesknees 10mo ago
    Are you reading a different link? This statement is on a React blog post, not a Twitter thread.
- tom1337 10mo ago
  But it is another React CVE. Doesn't really matter why it was uncovered, it's bad that it existed either way
- brazukadev 10mo ago
  an insecure software will have multiple CVEs, not necessarily related to each other. Those 3 are probably not the only ones.
zwnow 10mo ago
Welcome to the React, Next, Vercel ecosystem. Our tech may be shite but we look fancy.

rickhanlonii 10mo ago

After Log4Shell, additional CVEs were reported as well. It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.

PKop 10mo ago
The vulnerabilities existing is not a consequence of previous CVEs so this seems like an irrelevant non sequitur to keep mentioning everywhere.
deleted 10mo ago
[deleted]

bflesch 10mo ago

So we have a new React CVE and tomorrow is Friday, so please be prepared for a new outage brought to you by the super-engineers at Cloudflare.

venturecruelty 10mo ago
Look on the bright side: maybe GitHub will be down first, so nobody can upload any vulnerable code right before the weekend.

simonw 10mo ago

React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server. It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we've recently seen, is a risky spot in terms of potential security vulnerabilities.

tom1337 10mo ago
I was a fan of NextJS in the pages router era. You knew exactly where the line was between server and client code and it was pretty easy to keep track of that. Then I've began a new project and wanted to try out app router and I hated it. So many (to me common things) where just not possible because the code can run in the client and on the server so Headers might not always be available and it was just pure confusion whats running where.
- dawnerd 10mo ago
  I pretty much dumped a side project that was using next over the new router. It's so much more convoluted, way too many limitations. Who even really wants to make database queries in front end code? That's sketchy as heck.
  - Frotag 10mo ago
    A lot of functionality is obviously designed for Vercel's hosting platform, with local equivalents as an afterthought.
- Uehreka 10mo ago
  I think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear anyone say they like the App Router (and this is a pretty contrarian site, so if they existed I’d expect to see them here).

hedayet 10mo ago

I wonder what does these vulnerabilities mean for Facebook. As per my knowledge, Facebook's the biggest web app written in React.

jsheard 10mo ago
Does Facebook actually use RSC? I thought it was mainly pushed by the Nextjs/Vercel side of the React team.
- samdoesnothing 10mo ago
  No they don't. I think Meta is just big enough that they don't really care what is happening with React anymore haha.
- acemarke 10mo ago
  No, but it's primarily because Meta has their own server infrastructure already. RSCs are essentially the React team trying to generalize the data fetching patterns from Meta's infrastructure into React itself so they can be used more broadly. I wrote an extensive post and did a conference talk earlier this year recapping the overall development history and intent of RSCs, as best as I understand it from a mostly-external perspective: - https://blog.isquaredsoftware.com/2025/06/react-community-2025/ https://blog.isquaredsoftware.com/2025/06/react-community-20... - https://blog.isquaredsoftware.com/2025/06/presentations-react-community-2025/ https://blog.isquaredsoftware.com/2025/06/presentations-reac...
  - brazukadev 10mo ago
    So contrary to all other changes, this one was not done for Facebook to use. What was the reason behind RSC then?
    - cluckindan 10mo ago
      Market capture?

shadowgovt 10mo ago

Oh boy, I somehow missed that React was offering these. Google has a similar technology in-house, and it was a bit of a nightmare a few years back; the necessary steps to get it working correctly required some very delicate dancing. I assume it's gotten better given time.

aatd86 10mo ago

LOL. I must have divination powers. I am currently working on a UI framework and opened an issue just 3 weeks ago that says: *** Seems that server functions are all the rage. We are unlikely to have them. The main reason is that it ties the frontend and the backend together in undesirable ways. It forces a js backend upon people (what if I want to use Go for instance). The api is not client agnostic anymore. How to specify middleware is not clear. Requires a bundler, so destroys isomorphism (isomorphic code requires no difference between the client and the server/ environment agnostic). Even if it requires a bundler because it separates client and server implementation files, it blurs the data scoping (especially worrying for sensitive data) Do one thing and do it well: separate frontend and backend. It might be something that is useful for people who only plan on having a javascript web frontend server separate from the API server that links to the backend service. Besides, it is really not obvious to me how it becomes architecturally clearer. It would double the work in terms of security wrt authorization etc. This is at least not a generic pattern. So I'd tend to go opposite to the trend and say no. Who knows, we might revisit it if anything changes in the future. *** And boy, look at the future 3 weeks later... To be fair, the one good thing is that they are hardening their implementation thanks to these discoveries. But still seems to me that this is wholly unnecessary and possibly will never be safe enough. Anyway, not to toot my own horn, I know for a fact these things are difficult. Just found the timing funny. :)

brazukadev 10mo ago
I'm curious about your UI framework, is it public?
- aatd86 10mo ago
  Not public yet. Under review.

ashishb 10mo ago

The JavaScript fanatics will downvote me for saying this, but I'll say this, "using a single JavaScript codebase on your client-side and server-side is like cooking food in your toilet, sooner or later, contamination is guaranteed" [1] 1 - https://ashishb.net/tech/javascript/ https://ashishb.net/tech/javascript/

leptons 10mo ago
This isn't a Javascript problem, this is a React problem. You could theoretically rewrite React and RSC in any language and the outcome would be the same. Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.
- ashishb 10mo ago
  > This isn't a Javascript problem, this is a React problem. It happened with Next.js as well https://github.com/vercel/next.js/discussions/11106 https://github.com/vercel/next.js/discussions/11106 > Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript. Yes. And since Python does not natively run in the browser, that mistake never happens. With JavaScript, the desire to have "backend and frontend in a single codebase" requires active resistance.
  - rounce 10mo ago
    > It happened with Next.js as well It's the same vulnerabilities because Next uses the vulnerable parts of React. Your rational is quite poor as I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? Look, many of us also strongly dislike JavaScript but generally that distaste is based on its actual shortcomings and failures, you don't have to invent new ones plenty already exist.
    - ashishb 10mo ago
      > I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? If you have a single codebase for Go-based code running in an untrusted browser (the "toilet") and a trusted backend (the "kitchen"), then the same contamination is highly likely.

yread 10mo ago

Were there not enough eyes on React Server Components before the patches from last week?

Inviz 10mo ago
have you seen the code of next.js? its completely impenetrable, and the packages have legacy versions of the same files coexisting, it's like huge hairball
manfre 10mo ago
I've noticed a pattern in the security reports for a project I'm involved in. After a CVE is released, for the next month or so there will likely be additional reports targeting the same (or similar) areas of the framework. There is definitely a competitive spirit amongst security researchers as they try to get more CVEs credited to them (and potentially bounties).

hollowturtle 10mo ago

Wouldn't make more sense keeping React smaller and left those features to frameworks? I liked it more when it was marketed as the View in MVC. Surely can still be used like that today but it still feels bloated

ivanjermakov 10mo ago
git checkout v15.0.0 There we go.
- hollowturtle 10mo ago
  Can I have v15 with the rendering optimizations of further versions?
TZubiri 10mo ago
But the react-components are a separate library, they are not installed by default
- hollowturtle 10mo ago
  ? afaik react server components made it to core
  - silverwind 10mo ago
    They shouldn't be loaded in a React SPA at least, e.g. `react-dom` and `react` packages should be unaffected.
    - TZubiri 10mo ago
      So they are part of the standard distribution (like through npm install react), but are unused by default? Something like that?
      - danabramov 10mo ago

bitbasher 10mo ago

I remember when my greatest fear was sql injection. It’s great to see we have become more secure with our technology.

_heimdall 10mo ago

I do hope this means we can finally stop hearing about RSC. The idea is an interesting solution to problems that never should exist in the first place.

rvz 10mo ago

React patches one vulnerability and two more are revealed, just like a Hydra. At this point you might as well deprecate RSC as it is clearly a contraption for someone trying to justify a promotion at Meta. Maybe they are going to silently remove “Built RSC at Meta!” in their LinkedIn bios after this. So what other vulnerabilities are going to be revealed in React after this one?

marksomnian 10mo ago
Meta don’t use RSC: https://bsky.app/profile/en-js.bsky.social/post/3lmvwmr5rfs23 https://bsky.app/profile/en-js.bsky.social/post/3lmvwmr5rfs2... > We are not using RSC at Meta yet, bc of limits of our packaging infra (it’s great at different things) and because Relay+GraphQL gives us many of the same benefits as RSCs. But we are fans and users of server driven UI and incrementally working toward RSC. (as of April 2025)

ginkgotree 10mo ago

I'm only surprised it took this long for an exposure of backend data to the front end to be discovered in RSC

hbbio 10mo ago

We pioneered a lot of things with Opa, 15 years ago now. Opa featured automatic code "splitting" between client and server, introduced the JSX syntax although it wasn't called that way (Jordan at Facebook used Opa before creating React, but the discussions around the syntax happened at W3C notably with another Facebook employee, Tobie). Since the Opa compiler was implemented in OCaml (we were looking more like Svelte than React as a pure lib), we performed a lot of statical analysis to prevent the wide range of attacks on frontend code (XSS, CSRF, etc.) and backend code. The Opa compiler became a huge beast in part because of that. In retrospect, better separation of concerns and foregoing completely the idea of automatic code splitting (what React Server Components is) or even having a single app semantics is probably better for the near future. Our vision (way too early), was that we could design a simple language for the semantics and a perfect advanced compiler that would magically output both the client and the server from that specification. Maybe it's still doable with deterministic methods. Maybe LLMs will get to automatic code generation of all parts in one shot before.

danabramov 10mo ago
Note that the exploits so far haven’t had much to do with “server code/data getting bundled into the client code” or similar which you’re alluding to. Also, RSC does not try to “guess” how to split code — it is deterministic and always user-controlled. The vulnerabilities so far were weaknesses in the (de)serializer stemming from the dynamism of JavaScript — ability to hijack root object prototype, ability to toString functions to get their code, ability to override a Promise then implementation, ability to construct a function from a string. The patches are patching the (de)serializer to work around those dynamic pieces of JavaScript to avoid those gaps. This is similar to mistakes in parsers where they’re fooled by properties called hasOwnProperty/constructor/etc. The serialization format is essentially “JSON with Promises and code chunk references”, and it seems like there’s enough pieces where dynamic nature of JS can leak that needed to be plugged. Hopefully with more scrutiny on the protocol, these will be well-understood by the team. The surface area there isn’t growing much anymore (it’s close to being feature-complete), and the (de)serializers themselves are roughly 5 kloc each. The problem you had in Opa is solved in RSC with build-time assertions (import "server-only" is the server environment poison pill, and import "client-only" is the client environment poison pill). These poison pills work transitively up the module import stack and are statically enforced and prevent code (eg DB code, secrets, etc) from being pulled into the wrong environment. Of course this doesn’t prevent bugs in the (de)serializer but it’s why the overall approach is sound, in the absence of (de)serialization vulnerabilities.

ydj 10mo ago

I noticed requests that were exploiting the vulnerability were turning into timeouts pretty much immediately after rolling out the patch. I’m surprised it took so long for it to be announced.

greatgib 10mo ago

In my point of view, this is well deserved to idiots that are seriously using RSC in production, despite that being a very bad idea...

delifue 10mo ago

Any attempt that blurs boundary between client and server is unsafe.

delifue 10mo ago

React server component is frontend's attempt of "eating" backend. On the contrary, HTMX is the attempt of backend "eating" frontend. HTMX preserves the boundary between client and server so it's more safe in backend, but less safe in frontend (risk of XSS).

yawaramin 10mo ago
Htmx doesn't really have an XSS problem, this was solved by templating language long ago. See https://htmx.org/essays/web-security-basics-with-htmx/#always-use-an-auto-escaping-template-engine https://htmx.org/essays/web-security-basics-with-htmx/#alway...

jgalt212 10mo ago

I remember some podcast interview with Miško Hevery talking about how Qwik was very emphatic about what code ran on the server and what ran on the client. Seems self-evident and prescient. It was a great interview as Miško Hevery is extremely articulate about the problems at hand. If I find it, I'll post.

tills13 10mo ago

Y'all are so pessimistic. React Server Components are great. React is a complex piece of software. Bugs happen.

ipnon 10mo ago
Personally I prefer simple software without bugs! This security vulnerability highlights a serious issue with React. It’s a SPA framework, a server side framework, and a functional component library all at the same time. And it’s apparently getting so complex that it’s introducing source code exposures. I’m not interested in flame wars per se, but I can tell you there are better alternatives, and that the closer you stay towards targeting the browser itself the better, because browser APIs are at least an order of magnitude more secure and performant than equivalent JS operations.

WatchDog 10mo ago

When I looked into RSC last week, I was struck by how complex it was, and how little documentation there seems to be on it. In fairness react present it as an "experimental" library, although that didn't stop nextjs from widely deploying it. I suspect there will be many more security issues found in it over the next few weeks. Nextjs ups the complexity orders of magnitude, I couldn't even figure out how to set any breakpoints on the RSC code within next. Next vendors most of their dependencies, and they have an enormously complex build system. The benefits that next and RSC offer, really don't seem to be worth the cost.

firtoz 10mo ago
People did complain about next exposing "react, not ready for production" things as "the latest and greatest thing from nextjs" for quite a while now I had moved off nextjs for reasons like these, the mind load was getting too heavy for not too much benefit
mexicocitinluez 10mo ago
> and how little documentation there seems to be on it DISCLAIMER: After years of using Angular/Ember/Jquery/VanillaJs, jumping into React's functional components made me enjoy building front-ends again (and still remains that way to this very day). That being said: This has been maybe the biggest issue in React land for the last 5 years at least. And not just for RSC, but across the board. It took them forever to put out clear guidance on how to start a new React project. They STILL refuse to even acknowledge CRA exist(s/ed). The maintainers have actively fought with library makers on this exact point, over and over and over again. The new useEffect docs are great, but years late. It'll take another 3-4 years before teh code LLMs spit out even resemble that guidance because of it. And like sure, in 2020 maybe it didn't make sense to spell out the internals of RSC because it was still in active development. But it's 2025. And people are using it for real things. Either you want people to be successful or you want to put out shiny new toys. Maybe Guillermo needs to stop palling around with war criminals and actually build some shit. It might be one of the most absurd things about React's team: their constitutional refusal to provide good docs until they're backed into a corner.

andrewmcwatters 10mo ago

[dead]

kpozin 10mo ago

A framework designed to blur the line between code running on the client and code running on the server — forgot the distinction between code running on the client and code running on the server. I don't know what they expected. (The same confusion comes up regularly whenever you touch Next.js apps.)

aabhay 10mo ago

“use insecure”

dizlexic 10mo ago

I'm not going to let go my argument with Dan Abramov on x 3 years ago where he held up rsc as an amazing feature and i told him over and over he was making a foot gun. tahdah! I'm a nobody PHP dev. He's a brilliant developer. I can't understand why he couldn't see this coming.

peacebeard 10mo ago
You might be more brilliant than you think.
danabramov 10mo ago
For what it’s worth, I’ve just built an app for myself with RSC, and I’m still a huge fan of this way of building and structuring web software. I agree I underestimated the likelihood of bugs like this in the protocol, though that’s different from most discussions I’ve had about RSC (where concerns were about user code). The protocol itself has a fairly limited surface area (the serializer and deserializer are a few kloc each), and that’s where all of the exploits so far have concentrated. Vulnerabilities are frustrating, and this seems to be the first time the protocol is getting a very close look from the security community. I wish this was something the team had done proactively. We’ll probably hear more from the team after things stabilize a bit.
- brazukadev 10mo ago
  RSC is not a protocol, that is probably one of the reasons it is bad and affected only NextJS - most other server framework struggled and gave up this mistake that was React Server.
locallost 10mo ago
I'm not defending React and this feature, and I also don't use it, but when making a statement like that the odds are stacked in your favor. It's much more likely that something's a bad idea than a good idea, just as a baseball player will at best fail just 65-70% of the time at the plate. Saying for every little thing that it's a bad idea will make you right most of the time. But sometimes, occasionally, a moonshot idea becomes a home run. That's why I dislike cynicism and grizzled veterans for whom nothing will ever work.

metta2uall 10mo ago

For the vast majority of projects it seems like the disadvantages of these highly complex RPC systems far exceed the benefits... Not just in terms of security but also the reduced observability compared to simple JSON..

TZubiri 10mo ago

Interesting how DoS ranks higher than code exposure in severity. I personally think it's the other way around, since code exposure increases the odds that a security breach happens, while DoS does not increase chances of exposure, but affects reliability. Obviously we are simplifying a multidimensional severity to one dimension, but I personally think that breaches are more important than reliability. I'd rather have my app go down than be breached. And I don't think it's a trivial difference, if you'd rather have a breach than downtime, you will have a breach.

LittleOtter 10mo ago

Our team is working to fix our Next.js project.It's so painful. Now I'm doubting RSC is a good engineering technology or a good practice.The real world is tradeoffs: RSC really help us improve our develop speed as we have good teamates that has good understanding of fullstack. Do hope such things won't happen again.

IceDane 10mo ago
How is it painful? You need to bump a minor version? It took me less than 5 minutes 90% of which was waiting for CI. There's even a tool you can run to do it for you.

phplovesong 10mo ago

SSR is just dumb. Its very rare that you would benefit much from this approach, the only thing you get an complexity bomb exploding in your face. How about either just return html (maybe with htmx), or have a "now classic" SPA. The frontend must be the most over engineered shitshow we as devs have ever created. Its where hype meets the metal.

nathants 10mo ago

Just exchange json. Backend in python/ruby/go/rust. Frontend in javascript/typescript. Scripts in bash/zsh/nushell. One upon a time there was a low amount of friction and boilerplate with this approach, but with Claude and Codex it’s changed from low to none.

KronisLV 10mo ago
I really like having a good old RESTful API (well maybe kinda faking the name because don't need HATEOAS usually)! Except I find most front end stacks to lead to either endless configuration (e.g. Vue with Pinia, router, translation, Tailwind, maybe PrimeVue and a bunch of logic for handling sessions and redirects and toast messages and whatnot) and I feel the pull to just go and use Django or Laravel or Ruby on Rails mostly with server side templates - I much prefer that simplicity, even if it feels a bit icky to couple your front end and back end like that.

ManuelKiessling 10mo ago

I really wonder why the swarm intelligence of software developers still hasn’t decided on a single best clearly defined architecture for serving web applications, decades after the building blocks have been in place. Let the server render everything. Let JS render everything, server is only providing the initial div and serves only JSON from then on. Actually let JS render partial HTML rendered on the server! Websockets anyone? Imagine SQL server architecture or iOS development had this kind of ADHS syndrome.

dzonga 10mo ago

react server components is something that should've never existed anyway. are people shipping faster due to them ? or it's all complexity, security vulnerabilities like this. you're not facebook. render html the classic way if you need server rendered html. if you really do need an SPA - which is 5% of the apps out there - then yeah use client side react, vue, svelte etc - none of those RPC server actions etc

CodingJeebus 10mo ago
Agreed. Unfortunately, there's an entire content/bootcamp ecosystem pushing this stuff that came of age largely during the tech boom, as well as a bunch of early and mid-career devs and companies that are deeply tied to it. With major VC funding backing projects like Bun, Vercel, etc., I don't think this deeply flawed approach to development is going anywhere because the utopian JS fantasy of "it just works and runs everywhere flawlessly" is the ultimate myth of building for the web.

scotty79 10mo ago

Language with dynamic code evaluation on the server plus fat client-setver protocol that attempts to sync raw objects of the language. What could have gone wrong? I wonder if similar magic fat pipe technologies (like Blazor) have similar vulnerabilities waiting to be discovered. Maybe compiled languaged are safer by default in this scenario, but anything built in Python, PHP, Ruby or any "code is data" language would probably fare similarly poorly.