Patch FlightReplyServer with fixes from ReactFlightClient#35277
Conversation
FlightReplyServer are for client->server and ReactFlightClient is for server->client. They're not 100% symmetrical. We did a number of refactors to ReactFlightClient in PRs like facebook#29823 and facebook#33664 to change the structure of the resolution. This PR brings those changes to synchronize the two approaches. Which addresses deep resolution of cycles and deferred error handling. This also fixes a critical security vulnerability.
github-actionsbot added the React Core Team 
sebmarkbage merged commit 7dc903c into facebook:mainUh oh!
There was an error while loading. Please reload this page.
react-sizebot commented Dec 3, 2025
sebmarkbage commented Dec 3, 2025
TL;DR: If you are using React Server Components you really must upgrade. More information in Critical Security Vulnerability in React Server Components. This vulnerability was disclosed as CVE-2025-55182 and is rated CVSS 10.0. |
jschauma commented Dec 3, 2025
With this combined commit, people now have to go through a >1500 line patch to try to understand the security relevant changes. Going forward, it would be preferable if code changes for a critical security vulnerability could be committed separately from other changes. :-) |
sebmarkbage commented Dec 3, 2025
Further details of the vulnerability will be provided after the rollout of the fix is complete. |
This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [react](https://react.dev/) ([source](https://github.com/facebook/react/tree/HEAD/packages/react)) | [`19.2.0` -> `19.2.1`](https://renovatebot.com/diffs/npm/react/19.2.0/19.2.1) |  |  | | [react-dom](https://react.dev/) ([source](https://github.com/facebook/react/tree/HEAD/packages/react-dom)) | [`19.2.0` -> `19.2.1`](https://renovatebot.com/diffs/npm/react-dom/19.2.0/19.2.1) |  |  | --- ### Release Notes <details> <summary>facebook/react (react)</summary> ### [`v19.2.1`](https://github.com/facebook/react/blob/HEAD/CHANGELOG.md#1921-Dec-3-2025) [Compare Source](facebook/react@v19.2.0...v19.2.1) ##### React Server Components - Bring React Server Component fixes to Server Actions ([@​sebmarkbage](https://github.com/sebmarkbage) [#​35277](facebook/react#35277)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi4yNy4xIiwidXBkYXRlZEluVmVyIjoiNDIuMjcuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==--> Reviewed-on: https://git.foxden.network/foxCaves/foxCaves/pulls/16 Co-authored-by: Renovate <[email protected]> Co-committed-by: Renovate <[email protected]>
justinrest commented Dec 3, 2025
the meta |
This comment was marked as outdated.
This comment was marked as outdated.
rickhanlonii commented Dec 3, 2025
@szybnev that PoC is not valid, the server in that PoC is faked to respond. |
matija2209 commented Dec 4, 2025
Probably with a reason. You do not want to make it easier to reverse engineer. What we see, they see. |
Will the fix be backported to older major versions, or are they not vulnerable? |
eps1lon commented Dec 4, 2025
There are no Neither |
| } | ||
| } | ||
| constname=path[i]; | ||
| if(typeofvalue=== 'object' &&hasOwnProperty.call(value,name)){ |
There was a problem hiding this comment.
These hasOwnProperty checks were the ones that were missing. This is the critical fix. Without it, you can drill into objects not created by the parser itself.
The rest is mainly protecting against other gadgets and to slow down reverse engineering just a bit (which seems to have been somewhat effective especially with llms).
There was a problem hiding this comment.
Could this have also been solved by re-creating an object's own properties on a new object with a null prototype? If I'm not missing something, I imagine that would avoid the "shotgun surgery" of ensuring .hasOwnProperty guards anywhere which the object's properties are traversed.
| } | ||
| } | ||
| constname=path[i]; | ||
| if(typeofvalue==='object'&&hasOwnProperty.call(value,name)){ |
There was a problem hiding this comment.
This is the other one.
The ones on the module is not that critical but good to have.
AlexDev404 commented Dec 6, 2025
It was disclosed to the React team since November 29, 2025--so it's something I'd say quite a few people have reviewed already--we're just seeing it now, because they most likely already coordinated what they're going to do. |
jschauma commented Dec 6, 2025
That's not the point, though. The issue here is that sliding in a security fix with a refactor makes it difficult for anybody to whom it has not yet been disclosed to understand the vulnerability, to develop their defenses, and for the historical record to be obscured. It is not uncommon for a vulnerability fix to be incomplete and later require additional follow-up, or for a future reference to a given code fix. This is all made more difficult here. If the concern is disclosure, then the vulnerability could be kept under embargo and patching be done with coordination (as was and still is being done, and which I appreciate), but lifting an embargo and then trying to keep the actual vulnerability obscured only leads to wasted cycles on the defenders' side (see also the large number of AI slopped "PoC"s and poorly understand speculation). Vulnerability disclosure can be done in multiple stages, but when actual public disclosure is done, it's best to be specific and clear at that point. |
There was no "sliding" of any security fix. The person went through all of the steps of responsibly disclosing the vulnerability and it was released just as any other critical vulnerability. Haven't you been keeping yourself updated with the news? If not, I can for sure see why you'd say something like this.
It's a CVE--the point of it is to go public. I don't think you understand. React is an open-source project, not proprietary. So secretly pushing in a patch and then telling everyone after would defeat the entire purpose of it being an open source project. Also how would you "propose" they do so with React being an NPM package and not a piece of software you can just update? To disclose or not disclose would be irrelevant, as anyone bright enough could easily find out what the changes were.
The changes are very clean, and very minimal. IMO only someone who doesn't have a clue about how React works would say something like this. They've been very active in telling everyone essential about what's going on. So just because they didn't tell you to update your hobby project, doesn't give you the right to just come here and think you can get all like this. |
DogRespector93 commented Dec 7, 2025
Hey, for real, you do not have to be rude to someone asking polite, critical-thinking-oriented questions about how and why developers make certain choices in their project. It is not a status symbol to bully other coders doing "hobby projects" because you think it'll impress other devs. Your attitude makes the actual hardworking React teams look bad, not good. Your projects are easily just as "hobby" as theirs, and that's fine! You aren't managing some enterprise project- you're exploring - and anyone with experience doing it professionally knows attitudes like yours are caustic to progress. They asked legitimate questions. You can say, "This isn't really the forum for these kinds of questions, and I don't actually know the answer, but here's a good place to ask: ", and no one will think any less of you. |
I think you're misunderstanding, because I never said hobby project as if it was something bad. I assumed that that person created something using React for their own personal usage, and was upset by the fact that they never got notified about the issue. And so I think you're heavily inferring on something that wasn't the case.
They never asked any questions, and instead made targeted jabs as to what was happening. If they just made questions, this probably never would've happened. See the attached thread for further context on their messages |
14 participants
FlightReplyServer are for client->server and ReactFlightClient is for server->client. They're not 100% symmetrical.
We did a number of refactors to ReactFlightClient in PRs like #29823 and #33664 to change the structure of the resolution. This PR brings those changes to synchronize the two approaches. Which addresses deep resolution of cycles and deferred error handling.
This also fixes a critical security vulnerability.