Admins and defenders gird themselves against maximum-severity server vulnerability

Open source React executes malicious code with malformed HTML—no authentication needed.

See full article...

 

[chucklepie2]

I used to use noscript on my browser. I had to give up as more and more, site failed to work. Not that it would help in this case, unless the payload was ultimately aimed at browsers.

Including this website and especially the comments.

 

[Fristie Blade]

Can you elaborate on the server side vs client side nature of this exploit? Our servers run java and tomcat, not react, but some of the web pages we have are "react".

Edit:
I "looked up" some info here, but it seems you can run REACT as client side rendering. I am not your security professional, but it seems like client side isn't included here, nor would screwing up the end users computer harm the server.

That is exactly what it is: if you enable server-side rendering of your page, that's apparently when the vulnerability exists with if I read it correctly. When rendering on client side, you send a simple skeleton page with a great deal of (combined and minified) javascript code.
Your entire "app" is essentially running on client side and making calls for data and/or operations to be executed.

However, react apps client side have a drawback that they can become heavy to download and/or execute, or you need to polyfill for older browser clients, which may have issues. Or you may run on clients that have JS disabled.
In that case you can decide to keep the very same javascript based application (with react components) but instead of having it compile to a client-side executing set of js code, it will render an html page. Selecting items in drop downs or clicking buttons will then result in a POST call to the server, essentially telling the server what the user did and the server will respond by rendering the new content and sending it back.

If I understand it correctly, it looks like it is the payload of "current page info" to server that is being deserialized by the server to know what to render, and that's where the vulnerability is.

I am lucky in that the REACT apps where I was involved in seem unaffected: only client side rendering and none of those plugins.
Then again, I am pretty sure that lucky today means they will get me a next time

 

[Shyntae]

That is how you SHOULD run it. Its a freaking client (i.e. browser) framework for rendering User Interfaces.

Its only the janky "lets run client side code on the server" that is having the issue.

Even when running React clientside, you might want to have server-side rendering enabled for accessibility and crawlers.

 

[flow783]

React gives JS a bad name.

NPM gives JS a bad name.

Tailwind gives CSS a bad name.

Wordpress gives PHP a bad name.

I wish these 8 week coding workshop, AI deferring junior developers would learn the actual platform instead of imitating these hype filled slopfluencers.

Please, don't take a hype filled shiny shortcut.

Learn the actual platform and you don't need to reach for these hollow tools that break within a year.

As someone who has done some front and back end coding, who has on several occasion acted as a proxy for someone with a WordPress website and has occasionally lifted the lid to look at the inner workings of PHP frameworks, and someone who's an active user of NodeJS (and npm/pnpm), JS-in-the-browser and is happy to be not compelled to learn, use or even touch React, I have to, essentially, contradict this opinion.

I'm aware of the many objections and actual problems of npm (well, rather a tiny subset of them, probably). Yet I do not claim I could do better (although I have sth similar in scope on the backburner). I actively despise WordPress—politically, from a user experience standpoint, from a user interface standpoint, and from a developer's standpoint. I would not recommend writing a replacement for yourself though, except that is your calling, or you're working in a capable team for a resourceful company.

I guess what I'm saying is "don't write your own text editor", "don't write your own RDBMS", "don't write your own OS", "don't invent your own encryption", all of these with the addition "unless that's what you feel is your calling", because one of the reason for the many shortcomings in software is not that the other authors of existing software with known blemishes and bugs are stupid and I'm smart, and it's not that they're lazy and I'm not. The fundamental reason is that software is hard.

"Learn the actual platform" is a solid piece of advice that doesn't get old. "You don't need those tools" is hubris when taking to mean "you don't need that ready-made DB engine, write your own", or "you can do a complex web app with front and back end functionality from scratch, you don't need any tools, except a toothpick and JavaScript. Your grandmother and I we used to WALK to school each day!!".

Nobody ever points this out, seemingly, but as much as I dislike React despite not knowing it too well, some advantages of using is it are (1) now you have a communicable skill to put on your resume, that's good; (2) now you know what your baseline is at work, that's good; (3) you haven't invented yet another wholly proprietary solution which is probably not as well documented, that has zero helpful discussions to show for on the web, and that has a gazillion of open loopholes that are solely counterbalanced by its utter obscurity; (4) vulnerabilities are shared among a multitude of stakeholders who will be eager to find solutions. (Maybe this last point is somewhat counterbalanced by the fact that using a widespread piece of software puts you into a huge pool of fish that are, by virtue of their multitude, irresistible to the sharks.)

 

[Voo42]

Coincidentally, all the popular JavaScript-based frameworks seem to have a "bad name" when it comes to implementing secure, maintainable and robust code.

If only we could work out what the common denominator was, we could do something about it.

Right. Nobody but popular JavaScript frameworks ever had deserialization vulnerabilities.

I mean except for Java. Oh and .NET. Oh and Python, they had their fun share to.

And those are only the languages I pay enough attention to.

This has happened to virtually everyone who ever decided to implement a dynamic general purpose deserialization framework. Particularly any framework that was created before this came into focus (admittedly the first wave of Java exploits in that vein were in the middle of the 2000s) will probably have dubious design decisions that make this easier.

 

[Quayle]

If you own a company that develops any type of website or web application, you really should have knowledgeable folks that stay on top of stuff like this.

While most shops I have worked with do have some capacity for this, many don’t and consider such things to be low priority.

It may surprise some here, but even financial companies in charge of your money are slow to resolve security issues. Think months, and sometimes years.

You know, a place I used to work didn't like the idea of paying for backup. You know, because it was an expensive investment. I tried to explain how chosing not to do backups might prove to be more expensive.

Well, there was an incident later, where data was lost. Suddenly the thought of investing in backups wasn't such a crazy idea afterall.

I bet every IT-manager with a few years in the game, have one or several similar stories to tell.

 

[Yeay right]

Is there any way to know whether a web server has it embedded? For example, the web server running on my NAS?

Oh great, I was sure I was unaffected but now I am no longer so sure. The full list of third party software that embeds React is probably loooong.

 

[dankristy]

If you own a company that develops any type of website or web application, you really should have knowledgeable folks that stay on top of stuff like this.

While most shops I have worked with do have some capacity for this, many don’t and consider such things to be low priority.

It may surprise some here, but even financial companies in charge of your money are slow to resolve security issues. Think months, and sometimes years.

I work in state-government level IT fairly high up, and we DO have both people and capacity for this. But - and I cannot stress this enough - it also relies on dev teams to know and check their own repos and codebases... Because sometimes BOTH are needed.

I already shared this with my team, and several others, and while my team and web apps are not affected, the more teams we have pre-emptively checking, the faster we can be sure to kill this before someone can hit us.

We did the same with Log4J - we mitigated that BEFORE the security team did their diligence and notified us - however, our scan caught a piece living in maven - which we weren't aware of (and technically were not using - but still - we wanted it ALL stomped out.

These days - you have to be both reactive and proactive. There is no other way to stay uncompromised.

BTW - Ars team - thank you again for a good vulnerability writeup - I saw this news from several other sources, but once again, Ars writeup is the one I find both comprehensive enough, useful enough - and trusted enough - to share with my teams.

 

[Teletype]

It's incredibly common to call security vulnerabilities "vulns" in programming and technical areas.

How the heck do you pronounce that? Is it vul-ens? Vul-nas?
The abbreviation of words by insiders is not an excuse for foisting gibberish on the general public. I saw this story on Apple News and thought it was a mistake.

 

[jg.gutierrez]

BTW - Ars team - thank you again for a good vulnerability writeup - I saw this news from several other sources, but once again, Ars writeup is the one I find both comprehensive enough, useful enough - and trusted enough - to share with my teams.

You mean other than getting the most basic info wrong? This statement: "React versions 19.0.1, 19.1.2, or 19.2.1 contain the vulnerable code." is false - those are the patched versions. From the linked aikido.dev page (as well as other sources):

Install a patched React version such as 19.0.1, 19.1.2, or 19.2.1. These include hardened input handling.

 

[spamwell]

How the heck do you pronounce that? Is it vul-ens? Vul-nas?
The abbreviation of words by insiders is not an excuse for foisting gibberish on the general public. I saw this story on Apple News and thought it was a mistake.

However you pronounce the first part of vulnerability and pluralise it by sticking an s on the end. Not trying to be funny, I just don't know what dialect of English you speak.

This is a tech site, for nerds, it's entirely reasonable to use common industry parlance in articles. Also you learnt something new today so everyone is a winner.

 

[enlightened.doggo]

I've been testing out the various implementations of server functions recently as part of my contract work, and I have to say they don't really solve React's SSR problem. Server functions are a downgrade from running fetch against REST endpoints in seemingly every way. What React really needs is a first-class integration with express.

 

[RickRoyLeonPrisZhoraRacha]

And now we get to see who reacts fastest.

Its not just Patch Tuesday anymore.... Zero-Day is more like Minus One Day.

 

[ArcCoyote]

From the PoC repo linked in the article:

THIS IS NOT A REAL POC - EDUCATIONAL ONLY ​

IMPORTANT: This repository is an unsuccessful attempt to understand and replicate CVE-2025-55182 using Claude. The PoC turned out to be intentionally insecure and does NOT represent exploitation of CVE-2025-55182. (see issue #1)

Why This Doesn't Work​

The PoC explicitly registers dangerous modules (fs, child_process, vm) in the server manifest - something real applications never do. In real React Server Components The manifest is build-time generated - only contains legitimate Server Actions.

AI spit out a PoC with a server specifically meant to be exploited. For this to work in the real world you'd have to register a dangerous module or have a dependency that does, and you'd have to know what dependency the fs, child_process, vm, etc... can be reached via.

 

[HamHands_]

EDIT: Below I mix up static site generation (SSG) with server side rendering (SSR). NextJS does both. Static site generation has the issues I describe below. SSR serves an even narrower use case which means my conclusion is still fair but the whys are different. I think the only use case for SSR is SEO, given that it doesnt even have the benefits of static site generation.

The entire react ecosystem has been pushing towoards server side rendering by default over the last few years.

React was and is primarily a client side framework for developing UIs easier and faster (not faster as in execution, faster to develop the site. Execution speed is an ancillary concern that other frameworks address better).

However some big players, namely vercel (owner of Nextjs) have been pushing everyone towards SSR. Presumably so they can sell their cloud offering which will host your React SSR project.

This has changed the APIs of react and a lot of the tooling because SSR has a set of constraints that are different from pure client side JS.

In reality SSR SSG is only useful for websites whose content changes infrequently relative to how often the content is read. Thats because of what static site rendering is: some change in data triggers a re creation of static html pages and those pages can be cached and replicated using services like Cloudfront. Meaning your clients never have to talk directly to the APIs that deliver the data. Thus reducing the load on those servers as well. if your data changes often then you ve just added an HTML generation step that adds overhead to what could be a much faster direct call for the data.

So a blog site or a news site are a perfect fit. While something like Google maps is the nightmare scenario. In short, the more dynamic you website is the less useful SSR SSG is.

EDIT: SSR is similar but narrower. In the SSR world, you render the entire website (JS and all) server side once, then send that static HTML to the browser to draw. From there the client side takes over and it operates like a traditional single page application with requests being made from the browser to get the data. The idea being that web crawlers will get a fully rendered version of your page and thus good SEO.

The best practices these days assume you should start with SSR by default. Even though this is a much more complex setup. Which means a lot of react beginners reach for SSR even though it doesn't fit the use case. After all, if everyone is recommending it, not using SSR will seem the riskier choice.

I see very dynamic websites (ie: lots of calls to data that cannot be done ahead of time) that have SSR only so they can deliver an uninteractive 'skeleton' of a page (headers, footers, nav bar) while the data loads because they think users will feel that's faster than showing a loading spinner. It's like if at a restaurant, instead of waiting for your food, the waiter hands you a picture of what food looks like while you wait. Users aren't that dumb.

I think a situation like this is a good reminder to only use a tech if it actually fits your use case, not because it's in the zeitgeist.

 

[SomewhereAroundBarstow]

These days - you have to be both reactive and proactive. There is no other way to stay uncompromised.

So you're saying in addition to React.js people should be running Proact.js?

 

[enlightened.doggo]

The entire react ecosystem has been pushing towoards server side rendering by default over the last few years.

React was and is primarily a client side framework for developing UIs easier and faster (not faster as in execution, faster to develop the site. Execution speed is an ancillary concern that other frameworks address better).

However some big players, namely vercel (owner of Nextjs) have been pushing everyone towards SSR. Presumably so they can sell their cloud offering which will host your React SSR project.

This has changed the APIs of react and a lot of the tooling because SSR has a set of constraints that are different from pure client side JS.

In reality SSR is only useful for websites whose content changes infrequently relative to how often the content is read. Thats because of what static site rendering is: some change in data triggers a re creation of static html pages and those pages can be cached and replicated using services like Cloudfront. Meaning your clients never have to talk directly to the APIs that deliver the data. Thus reducing the load on those servers as well. if your data changes often then you ve just added an HTML generation step that adds overhead to what could be a much faster direct call for the data.

So a blog site or a news site are a perfect fit. While something like Google maps is the nightmare scenario. In short, the more dynamic you website is the less useful SSR is.

The best practices these days assume you should start with SSR by default. Even though this is a much more complex setup. Which means a lot of react beginners reach for SSR even though it doesn't fit the use case. After all, if everyone is recommending it, not using SSR will seem the riskier choice.

I see very dynamic websites (ie: lots of calls to data that cannot be done ahead of time) that have SSR only so they can deliver an uninteractive 'skeleton' of a page (headers, footers, nav bar) while the data loads because they think users will feel that's faster than showing a loading spinner. It's like if at a restaurant, instead of waiting for your food, the waiter hands you a picture of what food looks like while you wait. Users aren't that dumb.

I think a situation like this is a good reminder to only use a tech if it actually fits your use case, not because it's in the zeitgeist.

SSR is needed for SEO and good initial render times. Legacy technologies have been able to fetch enough data quickly enough for a full server render for decades now. The problem in my experience is that current meta-frameworks try and replace server-side frameworks like express and nest rather than compliment them.

 

[SomewhereAroundBarstow]

SSR is needed for SEO and good initial render times. Legacy technologies have been able to fetch enough data quickly enough for a full server render for decades now. The problem in my experience is that current meta-frameworks try and replace server-side frameworks like express and nest rather than compliment them.

You know what else works for SEO and good initial render times? HTML.

 

[Corin]

The CVE says affected versions are

React Server Components versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0.

The versions listed in the article as being affected are actually the versions with the fix.

 

[Voo42]

You know what else works for SEO and good initial render times? HTML.

Wow, so you want to generate html on the server side and then send it to the client?

If only there was a name for that.

 

[mb21]

People here seem to have quite a few misconceptions regarding client vs server and static site generation vs server etc. see my https://mastrojs.github.io/guide/cl...ide-javascript-static-vs-ondemand-spa-vs-mpa/

what’s even more confusing is that even when you only look at react with a running server (e.g. next.js) there is server-side rendering (which still loads everything into the client as well unfortunately) and the newer react server components (RSC), which do some remote-procedure-call thing. But if you’re running newer versions of next.js you’re vulnerable even if you’re not using RSC.

If you ask me, React in general, and next.js specifically, are really past their prime. it’s such a heavy and bloated ecosystem and there are more modern alternatives nowadays (Svelte, Solid.js for complex interactive SPAs if you really need that, and plain modern HTML/CSS for MPAs, which should be most websites).

 

[HamHands_]

SSR is needed for SEO and good initial render times. Legacy technologies have been able to fetch enough data quickly enough for a full server render for decades now. The problem in my experience is that current meta-frameworks try and replace server-side frameworks like express and nest rather than compliment them.

Ah I forgot about SEO. I usually work on web apps that have no SEO requirement so that is a blindspot for me. However lower initial load times goes back to my restaurant analogy. It only matters if users can actually accomplish a task while other content is loading. Unless you meant that low initial load is also a metric for SEO?

Can you expand on the meta-frameworks not complimenting server side frameworks? AFAIK express and nest are both frameworks for making HTTP APIs and do integrate with SSR frameworks like NextJS because SSR frameworks can pull data from anywhere.

People here seem to have quite a few misconceptions regarding client vs server and static site generation vs server etc. see my https://mastrojs.github.io/guide/cl...ide-javascript-static-vs-ondemand-spa-vs-mpa/

what’s even more confusing is that even when you only look at react with a running server (e.g. next.js) there is server-side rendering (which still loads everything into the client as well unfortunately) and the newer react server components (RSC), which do some remote-procedure-call thing. But if you’re running newer versions of next.js you’re vulnerable even if you’re not using RSC.

If you ask me, React in general, and next.js specifically, are really past their prime. it’s such a heavy and bloated ecosystem and there are more modern alternatives nowadays (Svelte, Solid.js for complex interactive SPAs if you really need that, and plain modern HTML/CSS for MPAs, which should be most websites).

I think you're right. I mixed up static site generation with server side rendering. Doh.

Svelte/Solid/etc arent necessarily a 1 for 1 with React. They are all 'template' based IIRC, whereas React isn't. Which is why in Solidjs/Svelte you have to use '{#each' and '<For>' components to do looping for example. They're hiding that under the hood they are binding data to html templates. Certainly better than older frameworks like KnockoutJS, but still a little limiting. In react you can use the standard JS for control flow and looping because each component is ultimately just a function that returns objects. Very simple conceptually, though maybe not so much in practice. I haven't quite made up my mind yet.

EDIT: You are right that most people should just be writing standard HTML and JS for static websites.

And who knows, maybel all of this discussion around react will be moot when WASM allows us to make websites using WinForms as god intended.

 

[raschumacher]

How do human minds even discover vulns such as this?

 

[mb21]

Svelte/Solid/etc arent necessarily a 1 for 1 with React. They are all 'template' based

That’s just a different syntax. JSX is a template language that’s “embedded” in the host language (JavaScript). Solid and Svelte really are pretty much 1:1 replacements, minus the ecosystem and mindshare of course, but much more efficient.

 

[SomewhereAroundBarstow]

Wow, so you want to generate html on the server side and then send it to the client?

If only there was a name for that.

My cranky perspective (that I guess I have to spell out explicitly, since you and others seem to have missed it) is that these frameworks have abstracted server-side rendering of HTML so much that most younger devs I've dealt with don't even really think about what they're rendering.

Templating with PHP and the like may be terrible in many respects but at least with it the HTML being produced was the result of human choices, not just blindly calling a function that spits out a chunk that can be styled but is typically filled with unnecessary nesting, non-semantic attribute values, etc.

Clearly there are reasons I no longer build front-ends for multi-billion dollar companies, but as far as I'm concerned we took a very wrong turn when the actual "Web 2.0" era was co-opted to become...this. There was a shining moment when we were moving to embrace the DOM with all its interoperability and transformation, and we could have had that without the JS framework BS that a few big players pushed out as they undercut the W3C. It didn't need to be XML/XSLT, but keeping the data as data and then transforming it with stylesheets that humans actually built would have been a better way to go. It's possible to do it with JSON and things like Handlebars but I usually see those used to make very minor elements of sites with needlessly bloated HTML coming out of frameworks.

I got out of the field a decade ago, so I'm sure there are lots of things people can point to as counter examples that I don't know about, but on a philosophical level I think we embraced the wrong approach for the wrong reasons.

 

[mb21]

My cranky perspective (that I guess I have to spell out explicitly, since you and others seem to have missed it) is that these frameworks have abstracted server-side rendering of HTML so much that most younger devs I've dealt with don't even really think about what they're rendering.

Templating with PHP and the like may be terrible in many respects but at least with it the HTML being produced was the result of human choices, not just blindly calling a function that spits out a chunk that can be styled but is typically filled with unnecessary nesting, non-semantic attribute values, etc.

Clearly there are reasons I no longer build front-ends for multi-billion dollar companies, but as far as I'm concerned we took a very wrong turn when the actual "Web 2.0" era was co-opted to become...this. There was a shining moment when we were moving to embrace the DOM with all its interoperability and transformation, and we could have had that without the JS framework BS that a few big players pushed out as they undercut the W3C. It didn't need to be XML/XSLT, but keeping the data as data and then transforming it with stylesheets that humans actually built would have been a better way to go. It's possible to do it with JSON and things like Handlebars but I usually see those used to make very minor elements of sites with needlessly bloated HTML coming out of frameworks.

I got out of the field a decade ago, so I'm sure there are lots of things people can point to as counter examples that I don't know about, but on a philosophical level I think we embraced the wrong approach for the wrong reasons.

I couldn’t agree more! Because I’m still in the field, this is what compelled me to build https://mastrojs.github.io/

 

[SomewhereAroundBarstow]

I couldn’t agree more! Because I’m still in the field, this is what compelled me to build https://mastrojs.github.io/

Heh. I've looked at your project before but haven't had an excuse to download it!

 

[mb21]

Heh. I've looked at your project before but haven't had an excuse to download it!

oh, cool! where did you come across it?
good thing is you don’t even need to download it: https://github.dev/mastrojs/template-basic (this web-only version requires a github account though)

 

[SomewhereAroundBarstow]

oh, cool! where did you come across it?
good thing is you don’t even need to download it: https://github.dev/mastrojs/template-basic (this web-only version requires a github account though)

That's a good question. Probably when I was looking into static site generation tools as a possible way to replace my WP blog, but since I never update it anyway that's been a largely moot point. (When I get HTML under my fingernails these days it's because I'm doing a side art project for myself, although I am easing into a consulting role that may become paid if I help them generate enough income with some people publishing with Ghost so I've been starting to dig into how theming works there.)

I do have a github account, though as a general rule I like to run things locally. One thing I did on more than one big site I worked on was listen to complaints about how slow it loaded (and the smarter UX and SEO people understood the cost of that) and then say "If we fetched all those web fonts and analytics scripts and review scripts, etc. and concatenated them into a single locally hosted JS file with a TTL of ten minutes" nearly every user session would load more than a second faster." No one seems to give a shit about that anymore. I just sit watching big sites fail to render for half a minute while some BS server with some BS script on it that they're probably refreshing on Clouflare from an S3 bucket or something takes forever to reach my browser.

 

[HamHands_]

That’s just a different syntax. JSX is a template language that’s “embedded” in the host language (JavaScript). Solid and Svelte really are pretty much 1:1 replacements, minus the ecosystem and mindshare of course, but much more efficient.

At a high level they are close replacements, but they are not the same. JSX transpiles to plain old javascript functions. A React component is a javascript function that returns another function. Rendering is execute the functions until there are no more functions to execute all you have is the HTML. Frameworks like Svelte process the code you write into HTML fragments and bind data to certain fragments (aka data binding / signaling). This allows more fine-grained updates (aka faster updates) but requires them to restrict how you write your components.

Which is why I can use any JS function I want in a react render, for example:
// I can use for loops, maps, filters, etc and anything JS
{[1,2,3,4,5].map(n => <div>{n}</div>}}
// I can call functions that I've defined in my render or literally anywhere else.
{mysillyloopingfunction(n => <div>{n}</div>}

But can't in svelte, you must use the builtin {#each operator and if you want to call a function it must be
{#each [1, 2, 3, 4, 5] as in}
<div>{in}</div>
{/each}

// Using a function i define is a little different too as I need to separate it's execution from the template rendering.
<script>
import { mysillyloopingfunction} from '$lib/utils.js';
const dataArray = mysillyloopingfunction();
</script>
{#each dataArray as n}
<div>{n}</div>
{/each}

And in Solid you can have arbitrary JS so the .map would be valid but they want you to use <For> so that the framework can apply databinding. The docs say if you do .map, it'll just recreate the elements on every render. I'm not sure if that means a DOM update everytime or if they have some sort of VDOM implementation to fallback on. If it is a DOM update then it'd be slower than the equivalent react if you chose not to use <For>. I'm too lazy to convert the mysillyloopingfunction example. But its roughly the same idea as in svelte.

// This is the preferred approach that actually engages the databinding
<For each={data}>
{(item) => <div>{item}</div>}
</For>
// Even though this is valid solidjs too
{[1,2,3,4,5].map(n => <div>{n}</div>}}

The idea about React was that allowing people to draw their UIs using functions returning functions was fast enough for most people. However in practice, there was a lotta gotchas. Which is why I'm not settled on it despite building web apps in it since it came out. However they are working on some neat compiler improvements that may eliminate those.

 

[htysc]

How the heck do you pronounce that? Is it vul-ens? Vul-nas?
The abbreviation of words by insiders is not an excuse for foisting gibberish on the general public. I saw this story on Apple News and thought it was a mistake.

About the pronunciation: In the sonority hierarchy in linguistics, approximants like "l" are more sonorant than nasals like "n", and so it is natural to have "l" before "n" at the end of a syllable (but not vice versa; "vunl" would have to have two syllables).

More concretely, there is a word "kiln" in English, pronounced as it is spelled. So unless English isn't your first language, surely you're exaggerating about how hard it is to pronounce "vuln"?

 

[alansh42]

How do human minds even discover vulns such as this?

It's identifying a risky pattern (like deserializing arbitrary objects) and seeing if they've accounted for the risks.

 

[Secondfloor]

I'm so glad that I am now a retired IT Manager

26 months to go. I can coast in from here

 

[ArsLongaVitaBrevis_4321]

Angular v2+ and React are very similar, to the point where I would say that Google ditched what made Angular different and useful and just turned it into another React clone with a weird compiler at the beginning.

React used to need a lot of third-party libraries and frameworks, but as of React 18 I think you can pretty much get away without anything besides a UI library that handles all the intricacies of web accessibility and maybe one for internationalization to handle multiple languages. Everything else is either part of web standards now or has been brought in-house to the React project itself.

As part of that they also really stepped up linting and compile-time checks in the last few versions.

That said, my horse hasn't really been in the race for a bit. I'm trying out a small project in Vue and I can already tell it would be much harder to manage a 10+ person team with it compared to React, without just reimplementing React along the way.

And while I'm at it, even though Facebook is (or was) technically the "owner" of the project, I think it's Microsoft and outside devs that are really carrying it nowadays.

You’re going to need to provide some solid data, or at least a much better argument, if you’re going to make bold claims like: “…I can already tell it would be much harder to manage a 10+ person team with it compared to React, …”

Here’s some data, or at least anecdotal-data: I’ve been a maintainer on multiple React projects (started by others typically), over the last 10 years or so. There was essentially no React coding commonality between them, except the use of JSX. And React has changed its approach and abstractions greatly, in that period: Hooks vs. Class Components vs. Higher-Order components, and probably a few more I’m forgetting…

In that time period (ignoring the ‘experimental’ Vue.js 1 release), Vue has had only two APIs: options, and composition; and they’re both well supported.

You do you, but it’s really pleasant not to have to re-learn a framework every year; just because somebody at Facebook or Vercel wants to get promoted…

Oh and I don’t worry about finding developers who already have Vue experience—all of the HTML, and CSS, just looks familiar. And the JavaScript is straightforward too, unless you decide to adopt the composition API (NOT hard to learn), and/or TypeScript. And Vue’s CSS name-spacing makes CSS’s biggest maintenance issue just go away.

My team has previous experience with React (and Angular, plus some lesser-known frameworks). As a result of that experience, we have a HARD ‘no React’ policy!

 

[ArsLongaVitaBrevis_4321]

I hated React so much that I just refused to learn it. I do shit the hard way by writing it from scratch without relying on a giant ass library that is controlled by one of the most evil companies in the world

Hey, come on over to: Vue.js — we have cookies!

OK, no cookies, but it’s: Facebook-free (and Vercel-free)…
It’s also Google-free (i.e., unlike: ‘Angular’).

https://vuejs.org/

A top-3 web framework, for many years now.

 

[mb21]

JSX transpiles to plain old javascript functions.

what doesn’t?

A React component is a javascript function that returns another function.

no, that’s a higher-order component. a react component is a function that returns a jsx object (and if it calls some hooks, it’s not pure anymore and not at all like plain js anymore).

but yes, solid (and svelte runes) use signals, which enabled much finer-grained updates instead of rerendering everything on every change like react does. I wouldn’t get too hung up on the loop syntax. as you said, in solid you can even use .map and it will actually fall back to a vdom-like diffing for arrays.

right, react has been working on that compiler since forever, while getting distracted with RSCs. but they’re still having the synthetic event system which adds to bundle size etc. I really don’t see the advantage when starting a new project, except that “nobody ever got fired for choosing react” (yet).

 

[darren_duncan]

They say we should be quick to update our React versions to resolve the problem, but 19.2.1 the vulnerable version IS the latest one available.

 

[oldbrew]

Is there any way to know whether a web server has it embedded? For example, the web server running on my NAS?

Don't expose your NAS to the public internet. While it might seem convenient, but just don't do it.

If you must expose it, put a firewall in front of it and limit to a list of IPs that you maintain.

 

[HamHands_]

what doesn’t?

Most templates don't transpile to functions and objects. They're fragments of HTML with some event handlers bound to elements. That's materially different than react's VDOM approach.

no, that’s a higher-order component. a react component is a function that returns a jsx object (and if it calls some hooks, it’s not pure anymore and not at all like plain js anymore).

A function that returns an object with a render function executed is to me the same as a function that returns a function. Ie: whether the chain is component1() returns component2() returns <div> or compontent1.render() returns component2.render() returns <div> isn't really different from each other.

Purity, hooks, HoCs, other react pattersn, etc wasnt really part of the point I was trying to make. I was trying to illustrate how React draws UIs vs how Solid/Svelete/etc draws UIs and how that difference creates a meaningful difference in how UI code is written.

I wouldn’t get too hung up on the loop syntax. as you said, in solid you can even use .map and it will actually fall back to a vdom-like diffing for arrays.

That's kind of the entire point that I was making. That difference in syntax and more importantly, execution, is meaningful to me and how I prefer to write UI code. It's the reason I stick with React instead of moving over to other frameworks. Or at least the reason I look for other frameworks use React's draw strategy, even if I have to go to other languages eg ElmJS / Dioxus / Lustre.

Regarding Solid specifically, I did more digging and it appears Solid doesnt fallback to a VDOM. So .map very likely recreates DOM elements, effectively having the same restrictions as Svelte

JSX allows you to use JavaScript to control the logic flow in the templates. However, without a Virtual DOM, using things like Array.prototype.map would wastefully recreate all the DOM nodes on every update. Instead it is common for Reactive libraries to use template helpers. In Solid we wrap them in components.

 

[AnotherBelgian]

SSR is needed for SEO

You don't need SSR for SEO. Every search engine worth its salt renders client-side Javascript before crawling the page.