Every now and then a new critical vulnerability emerges, that has a worldwide impact and is easy to exploit. We’ve all seen Log4Shell, Spring4Shell… and now React2Shell. Despite media coverage, application teams often miss the importance of security patches.

This particular vulnerability was found during a recent pentest in a production environment of our client, and it does not require any authentication. Global public disclosure of React2Shell happened just 5 weeks before this pentest. Reconnaissance At the very beginning of the tests, during the standard web app browsing and looking for an inspiration, a presence of NextJS framework caught our attention. This is indicated by requests for NextJS- generated data to endpoints starting with /_next. Since public disclosure of React2Shell happened just a couple of weeks earlier, why not to give it a try?

The first step is to open browser’s console and type next to get the currently used version of the framework: According to NextJS’ security advisory, the vulnerability has been fixed in 15.5.7. Therefore, we used a React2Shell scanner published by Assetnote to try to confirm the issue, and proxied it through Burp Suite to see the traffic. Exploitation The PoC payload from Assetnote tries to inject a system command echo $((41*271)), which should result in a string 11111 in the HTTP response. The scanner checks whether the response contains a redirection to /login?a=11111, and if so, marks the endpoint as vulnerable. The original payload looks like below: Response from the tested host was unequivocal: To prove the vulnerability beyond the mathematical PoC, one can execute id command, or substitute the JavaScript code to any other: And observe the effect in the response header: Since the app was running in a production environment, we did not attempt to infiltrate the infrastructure beyond the shown PoC, and the issue was immediately reported to the client and patched. Takeaways We have to acknowledge that every publicly available service will be at some point scanned by malicious bots, or otherwise targeted by attackers. A simple, unauthenticated HTTP POST request to an unpatched web app results in a server compromise – this is why it is crucial to track security advisories of our software vendors and patch as soon as possible.