[HN Gopher] Denial of service and source code exposure in React ...
___________________________________________________________________
Denial of service and source code exposure in React Server
Components
See also: https://blog.cloudflare.com/react2shell-rsc-
vulnerabilities-..., https://nextjs.org/blog/security-
update-2025-12-11
Author : sangeeth96
Score : 129 points
Date : 2025-12-11 20:46 UTC (2 hours ago)
(HTM) web link (react.dev)
(TXT) w3m dump (react.dev)
| chuckadams wrote:
| 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 wrote:
| That was indeed one of the main points of SPAs, but React
| Server Components are generally not used for pure SPAs.
| reactordev wrote:
| 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 wrote:
| I like RSCs and mostly dislike SPAs, but I also understand
| your sentiment.
| rustystump wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Blazor? Razor pages?
| whizzter wrote:
| I sometimes feel like I go on and on about this... but there
| is a difference between application and pages (even if blurry
| at times), and Next is a result of people doing pages
| adopting React that was designed for applications when they
| shouldn't have.
| hedayet wrote:
| I'd be interested in adopting a sole-purpose framework like
| that.
| rikafurude21 wrote:
| 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 wrote:
| 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 wrote:
| GitHub has to review the advisories and publish it for it to
| show in `npm audit`, so it's delayed.
| theogravity wrote:
| You need to update again.
| ChrisArchitect wrote:
| Related:
|
| _React2Shell and related RSC vulnerabilities threat brief -
| Cloudflare_
|
| https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-...
| (https://news.ycombinator.com/item?id=46237515)
| sangeeth96 wrote:
| Next team just published this: https://nextjs.org/blog/security-
| update-2025-12-11
|
| Seems to affect 14.x, 15.x and 16.x.
| carlcortright wrote:
| dammit
| tagraves wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Are you reading a different link? This statement is on a
| React blog post, not a Twitter thread.
| tom1337 wrote:
| But it is another React CVE. Doesn't really matter why it was
| uncovered, it's bad that it existed either way
| zwnow wrote:
| Welcome to the React, Next, Vercel ecosystem. Our tech may be
| shite but we look fancy.
| samdoesnothing wrote:
| Also kind of funny that they're comparing it to Log2Shell.
| Maybe not the best sort of company to be keeping...
| haileys wrote:
| Perception management
|
| https://en.wikipedia.org/wiki/Perception_management
| rickhanlonii wrote:
| Thanks for the feedback, I adjusted it here so the first note
| is related to the impacted versions:
|
| https://github.com/reactjs/react.dev/pull/8195
| tagraves wrote:
| I appreciate the follow up! I think it looks great now and
| doesn't read as defensively anymore!
| hitekker wrote:
| There are a lot of careers riding on the optics here.
| rickhanlonii wrote:
| 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 wrote:
| The vulnerabilities existing is not a consequence of previous
| CVEs so this seems like an irrelevant non sequitur to keep
| mentioning everywhere.
| bflesch wrote:
| 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 wrote:
| Look on the bright side: maybe GitHub will be down first, so
| nobody can upload any vulnerable code right before the weekend.
| simonw wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ashishb wrote:
| This happens in Next.js as well
| https://github.com/vercel/next.js/discussions/11106
| sangeeth96 wrote:
| This is what I asked my small dev team after I recently joined
| and saw that we were using Next for the product -- do we know
| how this works? Do we have even a partial mental model of
| what's happening? The answers were sadly, pretty obvious. It
| was hard enough to get people to understand how hooks worked
| when they were introduced, but the newer Next versions seem
| even more difficult to grok.
|
| I do respect the things React + Next team is trying to
| accomplish and it does feel like magic when it works but I find
| myself caring more and more about predictability when working
| with a team and with every major version of Next + React, that
| aspect seems to be drifting further and further away.
| hedayet wrote:
| I wonder what does these vulnerabilities mean for Facebook. As
| per my knowledge, Facebook's the biggest web app written in
| React.
| jsheard wrote:
| Does Facebook actually use RSC? I thought it was mainly pushed
| by the Nextjs/Vercel side of the React team.
| samdoesnothing wrote:
| 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 wrote:
| 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-20...
|
| - https://blog.isquaredsoftware.com/2025/06/presentations-
| reac...
| shadowgovt wrote:
| 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 wrote:
| 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. :)
| ashishb wrote:
| 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/
| yread wrote:
| Were there not enough eyes on React Server Components before the
| patches from last week?
| Inviz wrote:
| 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
| hollowturtle wrote:
| 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
___________________________________________________________________
(page generated 2025-12-11 23:00 UTC)