Explore all React2Shell and framework vulnerability guides →
Remote code execution means an attacker may be able to run code in an affected server process. Discovering an applicable RCE advisory is not proof that someone compromised your site. However, suspicious processes, unexpected deployments or unexplained credential use deserve a coordinated investigation. Start a written incident record and involve the person responsible for your hosting environment.
Separate exposure, suspicious activity and confirmed compromise
- Exposure: the service appears to match an advisory's affected version and runtime conditions. Patch promptly and assess the period it was reachable.
- Suspicious activity: logs or monitoring contain unexpected behavior requiring investigation. Preserve the evidence and label the conclusion as provisional.
- Confirmed compromise: evidence establishes unauthorized activity. Expand response scope to the accessible systems and credentials, rather than stopping after the vulnerable dependency is updated.
Contain the suspected service and preserve evidence
Coordinate containment with your hosting provider or incident responder. Restrict the affected service's access and preserve available logs and forensic evidence before routine cleanup destroys it. The Canadian Centre for Cyber Security recommends isolation, documented response actions and preservation of volatile evidence; casual rebooting can erase useful information. Let the response lead balance evidence collection with stopping active harm.
For a hosted web application, make an inventory of evidence you can actually obtain: deployment history, platform audit events, application logs, identity-provider events and database access records. Record each source's time zone, retention window and collection time. Keep sensitive logs in controlled storage rather than copying credentials or customer records into a public issue.
Build a timeline and determine the reachable scope
- Identify the affected deployment and when it became reachable. Include preview and alternate hostnames where relevant.
- Record the first observed suspicious event and distinguish observed facts from assumptions about earlier activity.
- Review which data stores, cloud roles and third-party services the application process could access.
- Ask the incident lead to evaluate related accounts and infrastructure, including unexpected configuration or deployment changes.
- Keep a timestamped decision log covering containment, evidence collection, changes and recovery approvals.
Recover from a trusted state and review credentials
Apply the vendor's remediation and verify the clean replacement artifact before routing users back to it. Coordinate secret rotation and session invalidation with the response lead so replacement credentials are not delivered into an environment still under attacker control. Review the permissions attached to each credential as well as its value. A database password change alone does not remove an unauthorized cloud account or a modified deployment pipeline.
For React2Shell specifically, the official Next.js advisory recommends rotating application secrets after patching and redeploying. Use that advisory's guidance together with the findings from your own environment. Avoid assuming that a generic HTTP response, a quiet dashboard or one clean scan proves historical compromise did not occur.
Retest the restored site without confusing a scan with forensics
Once the incident lead approves assessment, run MyPentest on the authorized, restored site for a baseline of supported website checks. Investigate reported findings and record anything unchecked. This helps assess the current application surface; it is not a forensic investigation, an RCE-specific detection guarantee or proof that every persistence mechanism was removed.
Communicate verified facts and keep follow-up ownership clear
Give stakeholders the affected service, verified impact, actions completed and remaining unknowns. Ask your designated legal or compliance contact to evaluate notification obligations against the incident facts. Assign owners for monitoring, credential review, access review and the final incident record. Recovery is easier to defend when the evidence supports each status you communicate.