[HN Gopher] RCE Vulnerability in React and Next.js
___________________________________________________________________
RCE Vulnerability in React and Next.js
Author : rayhaanj
Score : 320 points
Date : 2025-12-03 16:00 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| AgentK20 wrote:
| CVE 10.0 is bonkers for a project this widely used
| rs_rs_rs_rs_rs wrote:
| React is widely used, react server components not so much.
| _jab wrote:
| Next.js is still pretty damn widely used.
| nine_k wrote:
| 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
| ascorbic wrote:
| 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.
| root_axis wrote:
| 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.
| korm wrote:
| It's not a transitive dependency, it's just literally
| bundled into nextjs, I'm guessing to avoid issues with
| fragile builds.
| swyx wrote:
| why is it not normal for CI pipelines to cache these
| things? its a huge waste of compute and network.
| FINDarkside wrote:
| 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.
| j45 wrote:
| 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.
| bitbasher wrote:
| It's almost like trying to magically wire up your frontend to the
| backend through magical functions is a bad idea.
| baiwl wrote:
| Look at the money they've made to see if it was a bad idea or
| not.
| bitbasher wrote:
| 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.
| dizlexic wrote:
| Enron made boat loads.
| dizlexic wrote:
| ikr, no way this could have been predicted and warned about for
| months and months before now.
| beders wrote:
| 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.
| bossyTeacher wrote:
| CV driven development needs new ideas for resume padding
| regardless of whether the idea is good or bad. Then you get
| this
| division_by_0 wrote:
| 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
| ajross wrote:
| 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.
| padjo wrote:
| Where else would it be? What would an RCE of the client even
| mean?
| cyptus wrote:
| it would be an RCE on your own machine :D
| ajross wrote:
| 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.
| IceDane wrote:
| Bravo.
| heisenbit wrote:
| I suspect client developers are also affected at least to the
| extent that they need to explain this RCE to CVE driven
| management.
| phelm wrote:
| More detail in the React Blog post here
| https://react.dev/blog/2025/12/03/critical-security-vulnerab...
| embedding-shape wrote:
| 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.
| filearts wrote:
| 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__.
| mirashii wrote:
| This comment from a dupe thread is worth considering:
| https://news.ycombinator.com/item?id=46137352
| nickthegreek wrote:
| dupe: https://news.ycombinator.com/item?id=46136067
| benmmurphy wrote:
| 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. - return
| moduleExports[metadata.name]; + if
| (hasOwnProperty.call(moduleExports, metadata.name)) { +
| return moduleExports[metadata.name]; + } +
| return (undefined: any);
| hackhomelab wrote:
| It could also be
| https://github.com/facebook/react/commit/7dc903cd29dac55efb4...
| ("This also fixes a critical security vulnerability.")
| nine_k wrote:
| It does the same thing here, too: https://github.com/facebook
| /react/commit/7dc903cd29dac55efb4...
| dizlexic wrote:
| AHAHAHAHAHA, I'm sorry but we all knew this would happen.
|
| I'm just laughing because I called it when they were in the
| "random idea x posts" about use server.
|
| They'll fix it, but this was what we were warning about.
|
| edit: downvote if you want, but I'm sorry React thinking they
| could shoehorn "use server" in and not create huge
| vulnerabilities was a pipe dream at best. I vote gross negligence
| because EVERYONE knew this was going to happen.
| cluckindan wrote:
| 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.
| ptx wrote:
| 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
| cluckindan wrote:
| No. You cannot find all vulnerable code by grepping for
| "use server", for instance.
| dizlexic wrote:
| So that's your "it's not related to use server" argument?
|
| That seems like it could be a quote from their hardening
| guide.
| dzonga wrote:
| 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.
| nonethewiser wrote:
| easier/more reactivity, doesnt require your api responses to be
| text parsable to html
| switz wrote:
| 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
| ptx wrote:
| 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.
| paulhebert wrote:
| 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.
| leptons wrote:
| >now cz of the complexity I refuse to work with react.
|
| What do you like to work with now?
| TranquilMarmot wrote:
| 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.
| ethanwillis wrote:
| 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.
| AstroBen wrote:
| 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
| karimf wrote:
| > 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/
| Rauchg wrote:
| 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.
| semiquaver wrote:
| Does AWS WAF have a mitigation in place?
| serhalp wrote:
| 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
| croemer wrote:
| Link should go to: https://react.dev/blog/2025/12/03/critical-
| security-vulnerab...
| javaking wrote:
| 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
| IceDane wrote:
| Not even remotely similar.
| wepple wrote:
| Care to elaborate on what it is like, then?
| mvdtnz wrote:
| Actually he's more or less correct.
| mvdtnz wrote:
| 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.
| chasd00 wrote:
| 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.
| homebrewer wrote:
| 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.
| c-hendricks wrote:
| Anyone know how Tanstack Start isn't affected?
| dimitrisnl wrote:
| They haven't implemented RSC yet.
| serhalp wrote:
| 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.
| coffeecoders wrote:
| 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.
| j45 wrote:
| 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.
| coffeecoders wrote:
| 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.
| koakuma-chan wrote:
| You mean call whatever server action the client asks? I
| don't think having this vulnerability was intentional.
| j45 wrote:
| 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?
| sophiebits wrote:
| 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.)
| cluckindan wrote:
| "use server" is not required for this vulnerability to be
| exploitable.
| brown9-2 wrote:
| 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.
| dizlexic wrote:
| They were warned. I don't see how this can be characterized as
| anything but sloppy.
| rvnx wrote:
| 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"
| kachapopopow wrote:
| static builds save the day.
| _el1s7 wrote:
| 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".
| halflife wrote:
| 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.
| paularmstrong wrote:
| > What does server components do so much better than SSR? What
| minute performance gain is achieved more than client side
| rendering?
|
| RSC is their solution to not being able to figure out how to
| make SSR faster and an attempt to reduce client-side bloat
| (which also failed)
| halflife wrote:
| Maybe if they compiled away their runtime like svelte and
| somewhat like angular, then running SSR would be faster.
| cluckindan wrote:
| 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.
| halflife wrote:
| Sounds a little like hooks.
|
| A purist approach with short term thinking got everyone
| deep in a rabbit hole with too many pitfalls.
| samdoesnothing wrote:
| 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...
| paulhebert wrote:
| 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
| halflife wrote:
| 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
| azangru wrote:
| > 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...
| halflife wrote:
| 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
| danabramov wrote:
| 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.
| halflife wrote:
| 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.
| zackmorris wrote:
| 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:
| - 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.
| baobun wrote:
| > 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?
| samdoesnothing wrote:
| 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.
| heldrida wrote:
| Do you really need React Server Conponents or even Server Side
| Rendering?
| gloosx wrote:
| Of course you do, in certain cases making less round-trips to
| the server is just straight more efficient
| quentindanjou wrote:
| 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.
| ejpir wrote:
| 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
___________________________________________________________________
(page generated 2025-12-03 23:00 UTC)