6 ms·

I'm fumbled around a bit and got it working, but not entirely sure if this is how it really works: have a look at https://github.com/ejpir/CVE-2025-55182-poc ht

by ejpir 10mo ago

I'm fumbled around a bit and got it working, but not entirely sure if this is how it really works: have a look at https://github.com/ejpir/CVE-2025-55182-poc https://github.com/ejpir/CVE-2025-55182-poc

croemer 10mo ago
Thanks for the writeup, it's incredible!
- croemer 10mo ago
  The PoC is AI generated crap - sorry for the initial comment lauding it. I should have checked better. See: https://github.com/ejpir/CVE-2025-55182-poc/issues/1 https://github.com/ejpir/CVE-2025-55182-poc/issues/1 and https://react2shell.com/ https://react2shell.com/
WatchDog 10mo ago
I ran your exploit-rce-v4.js with and without the patched react-server-dom-webpack, and both of them executed the RCE. So I don't think this mechanism is exactly correct, can you demo it with an actual nextjs project, instead of your mock server?
- ejpir 10mo ago
  I'm trying that, nextjs is a little different because it uses a Proxy object before it passes through, which blocks the rce. I'm debugging it currently, maybe I'm not on the right path after all.
- ejpir 10mo ago
  I'v updated the code, try it now with server-realistic.js: 1. npm start 2. npm run exploit
slopfighter 10mo ago
Your lump of AI-generated slop has detracted from the response to an important vulnerability. Congratulations. Your PoC is invalid and you should delete it.
- jondwillis 10mo ago
  HMU, proud owner of slopcop.ai and have been itching to put it to good use.
orkj 10mo ago
very interesting to read. However, if I am reading this correctly, your PoC falls in the category described here: https://react2shell.com/ https://react2shell.com/ > Anything that requires the developer to have explicitly exposed dangerous functionality to the client is not a valid PoC. Common examples we've seen in supposed "PoCs" are vm#runInThisContext, child_process#exec, and fs#writeFile. > This would only be exploitable if you had consciously chosen to let clients invoke these, which would be dangerous no matter what. The genuine vulnerability does not have this constraint. In Next.js, the list of server functions is managed for you, and does not contain these. Context: This is from Lachlan Davidson, the reporter of the vulnerability
slop-cop 10mo ago
The guy who discovered the actual vulnerability says otherwise. Delete this distraction to genuine blue teamers and stop shitting up the information landscape with this utter hogwash. This is why infosec is dead. https://react2shell.com/ https://react2shell.com/ https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issuecomment-3609929967 https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issueco...
lionkor 10mo ago
FYI as of just now, the author has (correctly) added a disclaimer that this poc doesnt quite work.

by ejpir 10mo ago

croemer 10mo ago

Thanks for the writeup, it's incredible!

croemer 10mo ago
The PoC is AI generated crap - sorry for the initial comment lauding it. I should have checked better. See: https://github.com/ejpir/CVE-2025-55182-poc/issues/1 https://github.com/ejpir/CVE-2025-55182-poc/issues/1 and https://react2shell.com/ https://react2shell.com/

WatchDog 10mo ago

I ran your exploit-rce-v4.js with and without the patched react-server-dom-webpack, and both of them executed the RCE. So I don't think this mechanism is exactly correct, can you demo it with an actual nextjs project, instead of your mock server?

ejpir 10mo ago
I'm trying that, nextjs is a little different because it uses a Proxy object before it passes through, which blocks the rce. I'm debugging it currently, maybe I'm not on the right path after all.
ejpir 10mo ago
I'v updated the code, try it now with server-realistic.js: 1. npm start 2. npm run exploit

slopfighter 10mo ago

Your lump of AI-generated slop has detracted from the response to an important vulnerability. Congratulations. Your PoC is invalid and you should delete it.

jondwillis 10mo ago
HMU, proud owner of slopcop.ai and have been itching to put it to good use.

orkj 10mo ago

very interesting to read. However, if I am reading this correctly, your PoC falls in the category described here: https://react2shell.com/ https://react2shell.com/ > Anything that requires the developer to have explicitly exposed dangerous functionality to the client is not a valid PoC. Common examples we've seen in supposed "PoCs" are vm#runInThisContext, child_process#exec, and fs#writeFile. > This would only be exploitable if you had consciously chosen to let clients invoke these, which would be dangerous no matter what. The genuine vulnerability does not have this constraint. In Next.js, the list of server functions is managed for you, and does not contain these. Context: This is from Lachlan Davidson, the reporter of the vulnerability

slop-cop 10mo ago

The guy who discovered the actual vulnerability says otherwise. Delete this distraction to genuine blue teamers and stop shitting up the information landscape with this utter hogwash. This is why infosec is dead. https://react2shell.com/ https://react2shell.com/ https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issuecomment-3609929967 https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issueco...

lionkor 10mo ago

FYI as of just now, the author has (correctly) added a disclaimer that this poc doesnt quite work.