Weaver E-cology CVE-2026-22679: RCE Active Since Mid-March
Just caught the BleepingComputer report regarding CVE-2026-22679 in Weaver E-cology. It seems attackers have been leveraging a critical deserialization flaw since mid-March to execute discovery commands.
For those running E-cology (a popular OA suite in APAC), this is a high-priority issue. The vulnerability allows unauthenticated RCE, and the current TTPs involve dropping standard reconnaissance tools immediately after compromise. The report mentions they are specifically running discovery commands to map the network.
Since the exploit chain leads to command execution, I've put together a quick KQL query to hunt for the post-exploitation noise mentioned in the report. If you have this exposed, look for your web server process spawning shells:
ProcessCreationEvents
| where Timestamp > ago(7d)
| where ParentProcessName has "java" or ParentProcessName has "tomcat"
| where ProcessName in ("cmd.exe", "powershell.exe", "pwsh.exe")
| where CommandLine has "whoami" or CommandLine has "net user" or CommandLine has "ipconfig"
| project Timestamp, DeviceName, AccountName, ParentProcessName, ProcessName, CommandLine
| order by Timestamp desc
Has anyone verified if the latest patch fully addresses this deserialization vector? I know some OA vendors have a history of incomplete patches, and I'd love to confirm before we roll it out to production.
Is anyone else seeing similar IOCs in their web logs?
We actually detected this last week on a honeypot. The attackers were attempting to hit the /weaver/bsh.servlet.BshServlet endpoint specifically. If you aren't using BeanShell in your workflows, I highly recommend blocking access to that servlet at the web server level as a temporary mitigation while you patch.
Solid query, but I'd also add nltest to that command line list. In our environment, the threat actor jumped straight to domain discovery using that after successfully getting a shell. The patch for CVE-2026-22679 seems to hold up, but make sure you restart the services completely, otherwise the fix doesn't take effect.
From a pentester perspective, this exploit is surprisingly easy to weaponize. It's essentially a unsafe deserialization via a specific interface. If you can't patch immediately, strict WAF rules blocking serialized object types in the POST body to that specific endpoint are your best bet.
Valid point about nltest, Jordan. Beyond just the initial access, we've seen this actor query specific DNS records immediately after spawning a shell to map the network topology. You might want to watch for these specific queries in your DNS logs alongside the endpoint scans:
DnsEvents
| where QueryType in ("SRV", "TXT")
| where Query has "_ldap" or Query has "_gc"
Agreed on the immediate recon focus. Beyond the endpoint checks, we've found success hunting for process lineage. Since Weaver runs on a Java application server, a java.exe parent process spawning cmd.exe or powershell.exe is highly suspicious in this context. You can hunt for this behavior using this simple KQL query:
ProcessCreate
| where ParentProcessName has "java.exe"
| where ProcessName in ("cmd.exe", "powershell.exe")
This helps catch the exploit even if they obfuscate the web traffic.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access