Critical Weaver E-cology RCE flaw is now being exploited in real attacks

A critical remote code execution flaw in Weaver E-cology is being actively exploited, putting unpatched enterprise collaboration systems at serious risk.

The vulnerability, tracked as CVE-2026-22679, affects Weaver E-cology 10.0 builds before 20260312. It has a CVSS score of 9.8 because attackers can exploit it remotely without logging in.

The issue sits in an exposed debug endpoint that should not be reachable in production environments. Attackers can abuse it to run operating system commands through the application server.

What makes CVE-2026-22679 dangerous

Weaver E-cology is used as an office automation and collaboration platform, so a compromised server can expose internal workflows, business documents, employee data, and other sensitive enterprise assets.

The vulnerable endpoint is located at /papi/esearch/data/devops/dubboApi/debug/method. Security advisories say attackers can reach command-execution helpers through attacker-controlled request parameters.

This means the flaw does not only create an application-level risk. In a successful attack, the vulnerable server can become a gateway for system discovery, payload delivery, and broader network compromise.

Vulnerability	Details
CVE ID	CVE-2026-22679
Affected product	Weaver E-cology 10.0
Affected builds	Builds before 20260312
Severity	Critical, CVSS 9.8
Attack type	Unauthenticated remote code execution
Primary fix	Upgrade to build 20260312 or later

Attackers moved within days of the patch

Vega Threat Research found exploitation activity on a compromised host as early as March 17, 2026. That was only five days after the vendor released the patched build on March 12.

The timing shows how quickly attackers can move once a high-impact enterprise vulnerability becomes known. Vega also said its earliest evidence came 14 days before Shadowserver’s first public in-the-wild report on March 31.

The observed activity did not rely on a long-running interactive shell. Instead, the attackers used the vulnerable endpoint to send commands and read the returned output directly from the application response.

How the observed attack unfolded

The first stage focused on confirming remote code execution. Attackers used ping callbacks to check whether commands ran successfully from the target server.

After that, they tried several payload delivery methods. Vega reported attempts to drop executable files, run a malicious Windows Installer package, and retrieve PowerShell scripts from attacker-controlled infrastructure.

Endpoint defenses reportedly blocked several of these attempts, including the executable payloads and later PowerShell activity. Even so, the activity shows that attackers treated the flaw as a live entry point, not just a scanner finding.

• Attackers checked command execution with network callbacks.
• They attempted to download multiple payloads to the victim host.
• They tried to deploy an MSI file named fanwei0324.msi.
• They copied PowerShell into a renamed file to evade simple process-name detection.
• They ran discovery commands to learn more about the system.

Why defenders should treat this as urgent

The most important action is to upgrade affected Weaver E-cology 10.0 systems to build 20260312 or later. Vega says the vendor fix removes the vulnerable debug endpoint, which makes patching the primary mitigation.

Security teams should also check whether Weaver E-cology servers were exposed to the internet before patching. Any exposed and outdated system deserves a compromise review, especially if logs show access to the vulnerable API path.

Defenders should look for suspicious process chains where java.exe launches tools such as cmd.exe, powershell.exe, ping.exe, or msiexec.exe. Those patterns can indicate exploitation attempts through the application server.

What to check	Why it matters
Weaver E-cology build number	Builds before 20260312 remain vulnerable.
Access logs for the debug endpoint	Repeated hits may show scanning or exploitation.
Java child processes	Unusual command-line tools launched by Java can signal RCE.
PowerShell activity	Attackers attempted script-based payload retrieval.
Outbound connections to suspicious IPs	Callbacks and payload downloads can leave network traces.

Indicators reported by researchers

Vega published indicators linked to the observed activity, including payload names, a malicious MSI hash, and infrastructure used for callback checks and payload hosting.

Security teams should treat these indicators as starting points rather than complete coverage. Attackers can rotate hosting infrastructure and rename files quickly after public reporting.

A stronger detection approach should combine IOCs with behavior-based monitoring, especially Java spawning command interpreters, suspicious PowerShell execution, and unusual traffic from Weaver E-cology servers.

Indicator type	Examples reported
Suspicious files	vsgbt.exe, hjchhb.exe, nvm.exe, fanwei0324.msi, 2.txt, config.js
PowerShell payload names	xx.ps1, x.ps1
Malicious MSI hash	147ac3f24b2b63544d65070007888195a98d30e380f2d480edffb3f07a78377f
Suspicious process behavior	java.exe spawning cmd.exe, powershell.exe, ping.exe, or msiexec.exe

What organizations should do now

Organizations running Weaver E-cology should patch first, then investigate. Removing internet exposure without patching may reduce risk, but it does not fix the vulnerable code path.

After updating, teams should review historical logs from March 12 onward. That window matters because observed exploitation began within days of the patch release.

Network, endpoint, and application teams should coordinate the review because this attack crosses all three areas. Web logs can show access attempts, endpoint telemetry can show spawned processes, and network logs can show callbacks or payload downloads.

• Upgrade Weaver E-cology 10.0 to build 20260312 or later.
• Restrict access to E-cology servers from the public internet where possible.
• Review access logs for the vulnerable debug API path.
• Hunt for java.exe launching command-line utilities.
• Check for the reported filenames, hash, and suspicious outbound traffic.
• Reset credentials if investigation finds evidence of compromise.

FAQ