Denial of service and source code exposure in React Server Components
186 comments
·December 11, 2025simonw
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
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.
Uehreka
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).
hmcdona1
I would highly recommend just checking out TanStack Router/Start instead. It fills a different niche, with a slightly different approach, that the Next.js app router just hasn't prioritized enabling anymore.
What app router has become has its ideal uses, but if you explicitly preferred the DX of the pages router, you might enjoy TanStack Router/Start even more.
bryanrasmussen
OK I am personally surprised that anyone likes the Pages router? Pages routing has all the benefits (simple to get started the first time) and all the downsides (maintainability of larger projects goes to hell) of having your routing being determined by where in the file system things are.
I don't care about having things simple to get started the first time, because soon I will have to start things a second or third time. If I have a little bit more complexity to get things started because routing is handled by code and not filesystem placement then I will pretty quickly develop templates to handle this, and in the end it will be easier to get things started the nth time than it is with the simple version.
Do I like the app router? No, Vercel does a crap job on at least two things - routing and building (server codes etc. can be considered as a subset of the routing problem), but saying I dislike app router is praising page router with too faint a damnation.
morsmodr
Remix 2 is beautiful in its abstractions. The thing with NextJS Roadmap is that it is tightly coupled with Vercel's financial incentives. A more complex & more server code runs ensure more $$$ for them. I don't see community being able to do much change just like how useContextSelector was deprioritized by the React Core team.
Align early on wrt values of a framework and take a closer look at the funder's incentives.
reissbaker
Personally, I love App Router: it reminds me of the Meta monorepos, where everything related to a certain domain is kept in the same directory. For example, anything related to user login/creation/deletion might be kept in the /app/users directory, etc.
But I really, really do not like React Server Components as they work today. I think it's probably better to strip them out in favor of just a route.ts file in the directory, rather than the actions files with "use server" and all the associated complexity.
Technically, you can build apps like that using App Router by just not having "use server" anywhere! But it's an annoying, sometimes quite dangerous footgun to have all the associated baggage there waiting for an exploit... The underlying code is there even if you aren't using it.
I think my ideal setup would be:
1. route.ts for RESTful routes
2. actions/SOME_FORM_NAME.ts for built-in form parsing + handling. Those files can only expose a POST, and are basically a named route file that has form data parsing. There's no auto-RPC, it's just an HTTP handler that accepts form data at the named path.
3. no other built-in magic.
spoiler
Probably an unpopular take, but I really think Vercel has lost the plot. I don't know what happened to the company internally. But, it feels like the first few, early, iterations of Next were great, and then it all started progressively turning into slop from a design perspective.
An example of this is filesystem routing. Started off great, but now most Next projects look like the blast radius of a shell script gone terribly wrong.
There's also a(n in)famous GitHub response from one of the maintainers backwards-rationalising tech debt and accidental complexity as necessary. They're clearly smart, but the feeling I got from reading that comment was that they developed Stockholm syndrome towards their own codebase.
berekuk
I've been using React since its initial release; I think both RSC and App Router are great, and things are better than ever.
It's the first stack that allows me to avoid REST or GraphQL endpoints by default, which was the main source of frontend overhead before RSC. Previously I had to make choices on how to organize API, which GraphQL client to choose (and none of them are perfect), how to optimize routes and waterfalls, etc. Now I just write exactly what I mean, with the very minimal set of external helper libs (nuqs and next-safe-action), and the framework matches my mental model of where I want to get very well.
Anti-React and anti-Next.js bias on HN is something that confuses me a lot; for many other topics here I feel pretty aligned with the crowd opinion on things, but not on this.
awestroke
We're migrating away from both Next and Vercel post-haste
stack_framer
I find myself just wanting to go all the way back to SPAs—no more server-side rendering at all. The arguments about performance, time to first paint, and whatever else we're supposed to care about just don't seem to matter on any projects I've worked on.
Vercel has become a merchant of complexity, as DHH likes to say.
dawnerd
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
A lot of functionality is obviously designed for Vercel's hosting platform, with local equivalents as an afterthought.
sangeeth96
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.
stack_framer
I feel the same. In fact, I'll soon be preparing a lunch and learn on trying out Solid.js. I'm hoping to convince the team that we should at least try a different mental model and see if we like it.
thewtf
Should just use Vue.
0xblinq
This is why I'm a big advocate of Inertia.js [1]. For me it's the right balance of using "serious" batteries included traditional MVC backends like Laravel, Rails, Adonis, Django, etc... and modern component based frontend tools like React, Vue, Svelte, etc. Responsibilities are clear, working in it is easy, and every single time I used it feels like you're using the right tool for each task.
I can't recommend it enough. If you never tried/learnt about it, check it out. Unless you're building an offline first app, it's 100% the safest way to go in my opinion for 99.9% of projects.
tacker2000
I am also in love with Inertia, it lets you use a React frontend and a Laravel backend without a dedicated API or endpoints, its so much faster to develop and iterate, and you dont need to change your approach or mental model, it just makes total sense.
Instead of creating routes and using fetch() you just pass the data directly to the client side react jsx template, inertia automatically injects the needed data as json into the client page.
jaredklewis
I do think RSC and server side rendering in general was over adopted.
Have a Landing/marketing page? Then, yes, by all means render on the server (or better yet statically render to html files) so you squeeze every last millisecond you can out of that FCP. Also easy to see the appeal for ecommerce or social media sites like facebook, medium, and so on. Though these are also use cases that probably benefit the least from React to begin with.
But for the "app" part of most online platforms, it's like, who cares? The time to load the JS bundle is a one time cost. If loading your SaaS dashboard after first login takes 2 seconds versus 3 seconds, who cares? The amount of complexity added by SSR and RSC is immense, I think the payout would have to be much more than it is.
sakesun
Deeply agree.
joshdavham
I'm no javascript framework expert, but how vulnerable do people estimate other frameworks like Angular, Sveltekit and Nuxt to be to this sort of thing? Is React more disposed to be at risk? Is it just because there are more eyes on React due to its popularity?
rk06
nuxt, sveltekit etc don't have RSC equivalent. and won't have in future either. Vue has discussed it and explicitly rejected it. also RSC was proposed to sveltekit, they also rejected it citing public endpoint should not be hidden
they may get other vulnemerelities as they are also in JS, but RSC class vulelnebereleties won't be there
rk06
please forgive typos in above comment. i can no longer edit them
dirkc
I 100% agree. I didn't even bother to think about the security implications - why worry about security implications if the whole things seems like a bad idea?
In retrospect I should have given it more thought since React Server Components are punted in many places!
lmm
Yeah. Being able to write code that's polymorphic between server and client is great, but it needs to be explicit and checked rather than invisible and magic. I see an analogy with e.g. code that can operate on many different types: it's a great feature, but really you want a generics feature where you can control which types which pieces of code operate on, not a completely untyped language.
ashishb
This happens in Next.js as well https://github.com/vercel/next.js/discussions/11106
WatchDog
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
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
chuckadams
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."
mubou2
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.
seer
Isn’t that what Phoenix (Elixir) is? All server side, small js lib for partial loads, each individual website user gets their own thread on the backend with its own state and everything is tied together with websockets.
Basically you write only backend code, with all the tools available there, and a thin library makes sure to stich the user input to your backend functions and output to the front end code.
Honestly it is kinda nice.
mubou2
Idk about Phoenix, but having tried Blazor, the DX is really nice. It's just a terrible technical solution, and network latency / spotty wifi makes the page feel laggy. Not to mention it eats up server resources to do what could be done on the client instead with way fewer moving parts. Really the only advantage is you don't have to write JS.
dmix
Also what https://anycable.io/ does in Rails (with a server written in Go)
Websockets+thin JS are best for real time stuff more than standard CRUD forms. It will fill in for a ton of high-interactivity usecases where people often reach for React/Vue (then end up pushing absolutely everything needlessly into JS). While keeping most important logic on the server with far less duplication.
For simple forms personally I find the server-by-default solution of https://turbo.hotwired.dev/ to be far better where the server just sends HTML over the wire and a JS library morph-replaces a subset of the DOM, instead of doing full page reloads (ie, clicking edit to in-place change a small form, instead of redirecting to one big form).
brendanmc6
> Honestly it is kinda nice.
It's extremely nice! Coming from the React and Next.js world there is very little that I miss. I prefer to obsess over tests, business logic, scale and maintainability, but the price I pay is that I am no longer able to obsess over frontend micro-interactions.
Not the right platform for every product obviously, but I am starting to believe it is a very good choice for most.
oefrha
Yes, I say this every time this topic comes up: it took many years to finally have mainstream adoption of client-side interactivity so that things are finally mostly usable on high latency/lossy connections, but now people who’re always on 10ms connections are trying to snatch that away so that entirely local interactions like expanding/collapsing some panels are fucked up the moment a WebSocket is disconnected. Plus nice and simple stateless servers now need to hold all those long-lived connections. WTF. (Before you tell me about Alpine.js, have you actually tried mutating state on both client and server? I have with Phoenix and it sucks.)
JeremyNT
Well, maybe it isn't so insane?
Server side rendering has been with us since the beginning, and it still works great.
Client side page manipulation has its place in the world, but there's nothing wrong with the server sending page fragments, especially when you can work with a nice tech stack on the backend to generate it.
qingcharles
Sure. The problem with some frameworks is that they attached server events to things that should be handled on the front-end without a roundtrip.
For instance, I've seen pages with a server-linked HTML button that would open a details panel. That button should open the panel without resorting to sending the event and waiting for a response from the server, unless there is a very, very specific reason for it.
CharlieDigital
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.
c0balt
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
vbezhenar
I saw this kind of interactivity in Apache Wicket Java framework. It's very interesting approach.
McGlockenshire
> 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.
pjmlp
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
> 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.
acdha
> 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.
This is interesting because every Next/React project I see has a slower velocity than the median Rails/Django product 15 years ago. They’re just as busy, but pushing so much complexity around means any productivity savings is cancelled out by maintenance and how much harder state management and security are. Theoretically performance is the justification for this but the multi-second page load times are unconvincing.
From my perspective, it really supports the criticism about culture in our field: none of this is magic, we can measure things like page-weight, response times, or time to complete common tasks (either for developers or our users), but so much of it is driven by what’s in vogue now rather than data.
seer
I still remember the joy of using the flagship rails application - basecamp. Minimal JS, at least compared to now, mostly backend rendering, everything felt really fast and magical to use.
Now they accomplished this by imposing a lot of constraints on what you could do, but honestly it was solid UX at the time so it was fine.
Like the things you could do were just sane things to do in the first place, thus it felt quite ok as a dev.
React apps, _especially_ ones hosted on Next.js rarely feel as snappy, and that is with the benefit of 15 years of engineering and a few order of magnitude perf improvement to most of the tech pieces of the stack.
It’s just wild to me that we had faster web apps, with better organizarion, better dev ex, faster to build and easier to maintain.
The only “wins” I can see for a nextjs project is flexibility, animation (though this is also debatable), and maybe deployment cost, but again I’m comparing to deploying rails 15 years ago, things have improved there as well I’m sure.
I know react can accomplish _a ton_ more on the front end but few projects actually need that power.
tacker2000
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.
null
pjmlp
They weren't the new shinny to pump up the CV, and fill the Github repo for HR applications.
Atotalnoob
Blazor? Razor pages?
brazukadev
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
whizzter
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.
tshaddox
That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.
reactordev
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
I like RSCs and mostly dislike SPAs, but I also understand your sentiment.
nawgz
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.
robertoandred
Sure they are. Next sites are SPAs.
null
hedayet
I'd be interested in adopting a sole-purpose framework like that.
rustystump
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…
moomoo11
I think people just never understood SPA.
Like with almost everything people then shit on something they don’t understand.
tagraves
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
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
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
Are you reading a different link? This statement is on a React blog post, not a Twitter thread.
tom1337
But it is another React CVE. Doesn't really matter why it was uncovered, it's bad that it existed either way
brazukadev
an insecure software will have multiple CVEs, not necessarily related to each other. Those 3 are probably not the only ones.
rickhanlonii
Thanks for the feedback, I adjusted it here so the first note is related to the impacted versions:
tagraves
I appreciate the follow up! I think it looks great now and doesn’t read as defensively anymore!
rickhanlonii
Yeah agreed, thanks again for the feedback. The priority here is clear disclosure and upgrade steps.
haileys
Perception management
0xblinq
I think the same. To me it looks like a Vercel marketing employee wrote that.
hitekker
There are a lot of careers riding on the optics here.
IceDane
No, there aren't. The react team isn't going to axe half the team because there's a high severity CVE.
samdoesnothing
Also kind of funny that they're comparing it to Log2Shell. Maybe not the best sort of company to be keeping...
everfrustrated
React is the new JavaBean
zwnow
Welcome to the React, Next, Vercel ecosystem. Our tech may be shite but we look fancy.
brazukadev
The Vercel CEO post congratulating his team for how they managed the vulnerability was funny
TZubiri
Very standard in security, announcements always always always try to downplay their severity.
rickhanlonii
fwiw, the goal here wasn't to downplay the severity, but to explain the context to an audience who might not be familiar with CVEs and what's considered normal. I moved the note down so the more important information like severity, impacted versions, and upgrade instructions are first.
isodev
> an audience who might not be familiar with CVEs
If there are so many React developers out there using server side components while not familiar with the concept of CVEs, we’re in very serious trouble.
TZubiri
It's ok, you gotta play the game. I'm more concerned about the fact that the downtime issue ranks higher than the security issue. But I'm assuming it relates to the specifics of the issue rather than reflecting on the priorities of the project as a whole.
hbbio
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
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.
Philpax
You might be interested in Electric Clojure [1], although I must admit that I have not used it myself.
hollowturtle
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
TZubiri
But the react-components are a separate library, they are not installed by default
hollowturtle
? afaik react server components made it to core
silverwind
They shouldn't be loaded in a React SPA at least, e.g. `react-dom` and `react` packages should be unaffected.
ivanjermakov
git checkout v15.0.0
There we go.
hollowturtle
Can I have v15 with the rendering optimizations of further versions?
dizlexic
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.
danabramov
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.
jdkoeck
A tale as old as time: hubris. A successful system is destined to either stop growing or morph into a monstrosity by taking on too many responsibilities. It's hard to know when to stop.
React lost me when it stopped being a rendering library and became a "runtime" instead. What do you know, when a runtime starts collapsing rendering, data fetching, caching, authorization boundaries, server and client into a single abstraction, the blast radius of any mistake becomes enormous.
hu3
I never saw brilliance in his contributions. Specially as React keeps being duct-taped.
Making complex things complex is easy.
Vue on the other hand is just brilliant. No wonder it's creator, Evan You went on to also create Vite. A creation so superior that it couldn't be confined to Vue and React community adopted it.
peacebeard
You might be more brilliant than you think.
locallost
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.
nathants
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.
kpozin
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.)
_heimdall
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.
sangeeth96
Next team just published this: https://nextjs.org/blog/security-update-2025-12-11
Seems to affect 14.x, 15.x and 16.x.
delifue
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).
See also: https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-..., https://nextjs.org/blog/security-update-2025-12-11