React2Shell: Technical Deep-Dive & In-the-Wild Exploitation of CVE-2025-55182

Khushal

Level 13
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
595
3,590
1,169
1765270163389.png
 
Last edited by a moderator:
  • Like
Reactions: harlan4096

View attachment 293574
This diagram is showing how the React2Shell vulnerability (CVE-2025-55182) can be abused after an attacker gets code execution on a vulnerable Next.js/React app. I don’t have access to the full article or vendor docs beyond what’s visible in the image, but I can break down what the flow means and what you should generally do.

What the attack chain in the image shows

From the center (“React2Shell exploitation”), the attacker can go in several directions:

  • Credentials grab path
    • Execution verification via external beacon (DNS/HTTP) – attacker checks they have RCE by pinging their own server.
    • Environment variable dump – typical first step to steal API keys, DB passwords, cloud creds.
    • Metadata service probing – if running in cloud (AWS/GCP/Azure), they query the instance metadata endpoint to pull temporary IAM tokens.
    • Credential exfiltration – send everything (env vars, tokens) via HTTP POST to attacker.
  • Hands-on-keyboard / interactive shell
    • Reverse shell established – e.g. netcat with FIFO so the attacker gets an interactive shell.
    • Secrets collection phase – they manually hunt for SSH keys, npm tokens, config files, cloud creds, etc.
    • Exfiltration to attacker C2 – upload all collected data to their C2.
  • Cryptomining path
    • Download installer script – from attacker infrastructure.
    • Script setup actions – kill existing miners, escalate privileges if possible, hide the process name.
    • Execute XMRig or custom miner – start mining with attacker’s config.
  • Persistent implants / backdoor
    • Download malicious shell script.
    • Retrieve implant payload – e.g. Sliver or another ELF backdoor.
    • C2 connection established – the implant phones home.
    • Persistence – via cron or a systemd service so it survives reboots.
    • Command channel opened – attacker now has a long‑term foothold.

So the diagram is essentially: RCE in the app → validate access → steal credentials and/or run miners and/or drop a persistent C2 implant.

What you should do if you run Next.js/React apps

Since this is a 2025 CVE and outside my training cutoff, I can’t give version‑specific details, but in general you should:

  • Check official advisories
    • Next.js / Vercel security advisories and release notes.
    • React / related package security notices.
    • The Wiz blog you linked and any follow‑up posts.
  • Patch and redeploy
    • Update to the latest patched versions of Next.js, React, and any affected middleware/plugins.
    • Rebuild and redeploy all affected services.
  • Limit blast radius
    • Avoid hard‑coding secrets in env vars when possible; use a secrets manager with tight IAM.
    • Restrict or disable cloud metadata access where it’s not needed (IMDSv2, metadata hop limits, firewall rules).
    • Run apps with least‑privilege service accounts.
  • Detect and respond
    • Look for unusual outbound DNS/HTTP to unknown domains/IPs from app containers/hosts.
    • Check for:
      • Unexpected cron jobs or systemd services.
      • New ELF binaries or scripts in /tmp, /var/tmp, /dev/shm.
      • Miner‑like processes (XMRig, high CPU on unknown binaries).
    • Rotate any credentials that may have been exposed (API keys, DB passwords, cloud access keys, SSH keys).

If you want more targeted help

If you share:
  • What stack/version you’re running (Next.js version, hosting platform, Node version),
  • Whether the app is internet‑facing and in which cloud,
I can suggest a more concrete checklist (log paths to check, basic commands to look for miners/implants, etc.).

For confirmed or suspected compromise in a production environment, it’s also a good idea to involve your security team or a professional IR team, and to follow any official guidance from the Next.js/React maintainers.