A perfect CVSS 10 🧑🏻🍳💋
CVE-2025-55182: Unauthenticated remote code execution vulnerability in React Server Components
The vuln is in versions 19.0, 19.1.0, 19.1.1, and 19.2.0:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
Upgrade immediately!
you can try setting NEXT_PRIVATE_DEBUG_CACHE=1, it's not great but it's something
idk, i guess we just figured that advanceStage() is the happy path, and abandonRender() is the abort path. but there's some stuff we'll need to change in the abandon flow anyway, so it might not stay like that, we'll see
FWIW we reject them after the render is finished. in the case of Dan's bug report, we just accidentally weren't doing that, i fixed that here
github.com/vercel/next....
...and that's why we're doing the staging stuff -- by carefully ordering when promises are allowed to resolve, we can divide the RSC stream into parts that correspond to what we'd prerender statically (or in a runtime prefetch) *while also performing a full render*
github.com/vercel/next....
btw there's one important thing to know here. you can take an RSC payload and cut it off at some point in time (after some row). when you do this, all the promises that haven't resolved at that point will just be left hanging (i.e. suspend). this is the basis of prerendering in Cache Components
we need that separation for a couple reasons, e.g. for labelling stuff correctly in suspense devtools, but mostly for validation (where we check if we can render a static shell). we recently implemented that here:
github.com/vercel/next....
the general idea is that we want to separate the content that:
1. would be statically prerendered
2. would be rendered in a runtime prefetch
3. would be rendered in a navigation ("dynamic")
and in order to achieve this, we resolve various promises at specific times (see `pipelineInSequentialTasks`)
yeah, agreed, but sometimes you just happen to be grumpy and being nice and considerate doesn't come as easily 😅
these two PRs introduced most of the "staged" stuff:
github.com/vercel/next....
github.com/vercel/next....
i guess i'd try tracing code back to the PR that introduced it, and figuring out the background + seeing how it's described there. these features are built over time, so tracing their evolution over time is probably the least overwhelming way to see which parts are relevant
so anyway. again, sorry for being rude in the thread, but i hope that with this explanation, it makes more sense why i reacted the way i did. cheers, and hope that the next time we meet, it's under nicer circumstances :)
and while this is an open source project, and we like to be inviting to external contributors, that doesn't mean every incorrect suggestion will get a careful and considerate reply explaining why it's wrong. i'd love to, but i don't have time for that, sorry!
if u were a coworker or someone i know, then i would've spent the time to explain what's wrong with ur ideas. but that takes a bunch of effort -- in this case, it'd need quite a bit of explanation about how the whole "staged rendering + restart on cache miss" setup works.
ofc this can be "you don't know what you don't know" situation, i'm guessing that's what it was in this case.
but i hope that you can understand why i might react the way i did to someone coming in and talking about solutions while clearly missing a lot of context and background. i don't need that!
... and yes, this might not be obvious to someone who hasn't touched the staged rendering code, but that's my point -- if you don't know the code, perhaps you should familiarize yourself with it before jumping in and suggesting changes. otherwise, you might just waste people's time.
e.g. in this case, suggesting moving dynamic fetches to an earlier stage *fundamentally* doesn't make sense -- we specifically set up the dynamic stage so that dynamic stuff happens there (and is blocked earlier)!
the bug is not the fetch patch itself, it's related to restarting the render in dev
i don't want to discourage u from contributing, but if you're trying to do that, you should make sure that you actually understand what you're talking about enough to suggest something helpful.
while i appreciate the enthusiasm and desire to help, "joining the discussion" isn't valuable in and of itself. it's only valuable if your contribution is actually valuable. in this case, despite good intentions, it wasn't helpful. this is what i meant by "you're adding noise".
however, there's something that i'd like to get across so that you understand why i reacted in the way i did. it relates to something you said:
> I don't know the best way to fix this, so I didn't immediately come up with a PR, but joined the discussion
(sorry, it took me a while to collect my thoughts and reply)
alright. so first of all, i'd like to apologize for my tone in the thread. my rudeness wasn't warranted, and i could've communicated my point in a kinder way.
i'm guessing this might be related to our interaction on dan's issue earlier today. happy to discuss more if you'd like
some of us are also available here :)
(feeling vulnerable might delete later etc)
also just very destabilizing like. mentally. everything sucks
ugh us->eu jetlag is so upsetting
(although "static shell" is not quite accurate -- if it contains a cache, the shell will become ISR and will revalidate as often as needed to satisfy the specified staleTime)
the other important part is that in PPR + dynamicIO it serves as a marker that says "this can be part of the static shell" (if the staleTime is long enough), don't create a dynamic hole here". so it's kind of a lot of things in one
not sure wym by "something more official", but happy to answer questions
yeah the transform itself isn't that involved, in next we're repurposing most of the "use server" logic for it
cacheLife is important, one of the goals of this is to not just cache things server side but also inform the client-side router about how long stuff is allowed to be stale