Weaver E-cology CVE-2026-22679: a 9.8 RCE actively exploited since mid-March. The patch + IR runbook.

# Weaver E-cology CVE-2026-22679: a 9.8 RCE actively exploited since mid-March. The patch + IR runbook.

The Hacker News and gbhackers.com both lit up today (May 5, 2026) with active-exploitation reporting on CVE-2026-22679 — an unauthenticated remote code execution in Weaver E-cology, the dominant office-automation platform across China and a growing footprint in Asian-pacific enterprise. CVSS 9.8. Vulnerable path is /papi/esearch/data/devops/. Affects Weaver E-cology 10.0 versions prior to build 20260312. Public PoCs are already circulating on Chinese-language security forums; English-language coverage came today.

The ugly part: exploitation telemetry traces back to mid-March 2026. That's roughly seven weeks of stealth exploitation before the public disclosure landed. If you operate any internet-facing Weaver E-cology instance — and you don't already know you've been compromised — you are reading this post in the wrong order. Your IR is now an exercise in reading old logs, not preventing intrusion. Patch and assume compromise.

This post is the defender's runbook. Same shape as my CVE-2024-23897 Jenkins post and the CVE-2026-31431 Linux kernel post: detect first, patch second, contain third, notify fourth. If you operate E-cology in the US enterprise via a Chinese-software acquisition, in a multinational where the Asia-Pacific subsidiary procures it, or in any joint venture footprint, this runbook is for you.

#What Weaver E-cology actually does (the blast radius)

Weaver (also marketed as Fanwei or 泛微) is a Chinese-headquartered enterprise software vendor whose flagship product, E-cology, is an office-automation / collaboration suite. The accurate Western analog is "Microsoft 365 + ServiceNow + Confluence + DocuSign for one organisation, all bolted together into a single platform." It handles:

• Internal email (or routes through Exchange/IMAP backends)
• Document storage and approval workflows
• Contract drafting and digital signatures
• HR forms (leave requests, expense reports, performance reviews)
• Financial workflows that touch accounts payable, purchase orders, vendor onboarding
• Customer-facing portal extensions in some configurations
• LDAP/AD-bridged user identity

When E-cology is deployed in an enterprise, it is typically the single most data-rich application on the network. Owning E-cology means owning every internal contract, every HR record, every approval that flowed through the company in the last decade, every vendor relationship and the financial terms thereof, and a frequently-stale-but-still-valid LDAP credential map of every employee.

The customer footprint is heavily Chinese (Weaver claims 60K+ enterprise customers, including SOEs, banks, and major industrials), but a non-trivial number of multinationals run E-cology in their Chinese subsidiaries because it is the local-market default. Western companies with Chinese JVs, manufacturing operations, supplier offices, or simply a regional HR system are routinely E-cology customers without knowing it at the parent-company level. If your asset inventory says "no Weaver in our environment" but your company has any meaningful presence in mainland China, double-check.

#CVE-2026-22679 — what we know

The vulnerable path is /papi/esearch/data/devops/. The vulnerability is an unauthenticated, server-side endpoint that was apparently a debug API in the development build of E-cology 10.0 and was inadvertently shipped in production releases. The endpoint accepts crafted parameters that cause the server to deserialize attacker-controlled input through one of the bundled Java deserialization gadgets (the public PoCs use the Commons-Collections gadget chain, but other chains are available depending on the deployed version's classpath).

What the public reporting establishes:

• No authentication required. The endpoint is reachable from any client that can hit the E-cology HTTP listener.
• Unauthenticated remote code execution as the user running the E-cology service. On most deployments that's a dedicated weaver or tomcat system account, but on a meaningful number of legacy installs it's root because the deployment guide of yore said to run it that way.
• Reachable on whatever port E-cology is listening on, which is typically 80/443 for the customer-facing portal, often also exposed on the LAN at 8080 directly.
• Versions affected: Weaver E-cology 10.0 prior to build 20260312. Earlier major versions (8.x, 9.x) have separate vulnerability profiles and are not the subject of this CVE, but they have plenty of their own issues and are end-of-life or close to it — if you're running 9.x, this is a perfect time to upgrade past it entirely.
• Active exploitation since mid-March 2026. The CN-CERT and the corporate IR firms in the Chinese market have observed in-the-wild exploitation against multiple high-profile customers since approximately March 14-18, 2026. English-language coverage is catching up six weeks late.

The post-exploitation pattern observed in the wild is typical Chinese-targeting threat actor playbook:

1. RCE via /papi/esearch/data/devops/ to drop a JSP webshell into the E-cology web root (commonly WEB-INF/ or webapps/ecology/jsp/)
2. Credential theft from the E-cology DB (the database holds bcrypt-hashed user passwords, but the operator pulls them and brute-forces selectively against high-value accounts)
3. Lateral movement via reused credentials into the AD/LDAP environment
4. Exfiltration of HR records, contracts, financial documents — the high-value blob
5. Persistence via additional shells in less-obvious locations (a cron entry, a modified startup script, a scheduled task) and via the creation of additional administrative E-cology user accounts

#Detection commands — run these first, before patching

If you operate E-cology, run these against the production box and *also* against any disaster-recovery replica or pre-prod box that's even partially exposed.

HTTP log scan for requests to the vulnerable path.

zgrep -h '/papi/esearch/data/devops' /var/log/nginx/access*.log* \
                                     /var/log/httpd/access*.log* \
                                     /var/log/tomcat*/localhost_access*.log* 2>/dev/null \
  | awk '{print $1, $4, $7, $9}' \
  | sort -u

Any hit on this path before you patched is suspicious. Cross-reference the source IP with your operations and DR networks. Anything you don't recognize is a candidate exploitation event.

Process tree scan for shells spawned by the E-cology service user.

ps -eo pid,ppid,user,cmd | grep -E 'weaver|tomcat' | grep -vE 'java|grep'
ps auxf | grep -A3 -E 'tomcat|weaver'

You're looking for sh, bash, python, perl, nc, curl, wget running as the E-cology service account. None of those are normal under a Java application server.

For historical detection, audit the bash history of the service user:

cat /home/weaver/.bash_history /home/tomcat/.bash_history 2>/dev/null
ls -la /home/weaver/.bash_history /home/tomcat/.bash_history 2>/dev/null

If .bash_history is symlinked to /dev/null or is zero bytes despite the account being long-lived, treat that as IoC — operators routinely null out the history to hide.

File timeline analysis on the WEB-INF directory.

find /usr/local/ecology/ /opt/ecology/ /opt/tomcat*/webapps/ecology/ \
     -type f \( -name "*.jsp" -o -name "*.jspx" -o -name "*.class" \) \
     -newer /var/log/cpanel-install.log 2>/dev/null \
  | xargs ls -la --time=ctime 2>/dev/null \
  | sort -k 6,8

Adjust the -newer pivot to a known-good reference file from before the suspected compromise window. Any JSP file in the E-cology webapp directory that postdates your last legitimate deployment is a candidate webshell. Open them and check.

JSP webshell signatures to grep for:

grep -rE 'Runtime\.getRuntime\(\)\.exec|ProcessBuilder|Class\.forName|defineClass' \
     /usr/local/ecology/ /opt/tomcat*/webapps/ecology/ 2>/dev/null \
  | grep -vE 'src/|\.java:'

Any non-source-file hit on those patterns is suspect. Open the file. If it's a small standalone JSP that takes a cmd parameter or a serialized object body and runs it, it's a webshell.

Database audit for unauthorized accounts. Login to the E-cology database and pull the user table:

-- E-cology stores users in the `hrmresource` table on most builds
SELECT id, loginid, lastname, status, createrid, dateadd(d, -60, getdate()) as cutoff
FROM hrmresource
WHERE created > dateadd(d, -60, getdate())
ORDER BY created DESC;

(Adjust dialect — E-cology supports SQL Server, Oracle, MySQL/MariaDB, and DM depending on the deployment.)

Any account created in the last 60 days that you don't recognize is suspect. Check the permission and role joins to see what privileges the new account has — operators often grant themselves admin-equivalent permissions immediately on creation.

Audit the E-cology operation log. E-cology maintains an operation log for sensitive actions (account creation, permission changes, document export). The table is sysoperationlog or syslog depending on version.

SELECT operatedate, operator, operatedesc, ip
FROM syslog
WHERE operatedate > dateadd(d, -60, getdate())
  AND operatedesc LIKE '%export%' OR operatedesc LIKE '%admin%' OR operatedesc LIKE '%create%user%'
ORDER BY operatedate DESC;

Look for bulk document exports, permission changes, and admin grants from unusual IPs.

Review IIS/Tomcat logs for outbound exfiltration patterns. If E-cology has been exfiltrating documents, you should see large-bytes responses to non-browser user agents:

zgrep -h 'GET\|POST' /var/log/tomcat*/localhost_access*.log* 2>/dev/null \
  | awk '$10 > 10000000 {print $1, $4, $7, $10, $11}' \
  | sort -k4 -n -r \
  | head -50

Any 10+ MB response to an unauthenticated client or to an unusual user-agent string is a candidate exfiltration event.

#Patch order — exact sequence

Order matters here too. Don't rotate credentials before patching, or the operator (if still resident) gets your new credentials back through the same vector.

1. Take an emergency snapshot of the system. Before you do anything else, snapshot the VM disk, the database, and the application home directory. If you discover compromise mid-IR you'll want a forensic baseline. Hetzner Cloud, AWS EBS, VMware, Hyper-V — all support live snapshots; use yours.

2. Block external access to the E-cology service at the network edge. Whitelist your operations IPs only:

# iptables example - adjust to your firewall stack
iptables -A INPUT -p tcp --dport 80 -s <ops-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s <ops-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -s <ops-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP
iptables -A INPUT -p tcp --dport 8080 -j DROP

This prevents new exploitation while you work, and is reversible. Persist the rules with iptables-save or your distro's mechanism.

3. Apply the Weaver patch. Weaver's update mechanism varies by deployment — some installs use the bundled patch tool, some require a manual JAR/WAR replacement. The vendor advisory references build 20260312. Specifically:

• Stop the E-cology Tomcat / application server
• Back up WEB-INF/lib/ and WEB-INF/classes/
• Replace with the patched WAR or apply the vendor's hotfix patch
• If the vendor patch is not yet available in your support channel (likely if you're on an older support contract), the immediate mitigation is to block the /papi/esearch/data/devops/ path entirely at your reverse proxy:

# nginx
location ~ ^/papi/esearch/data/devops/ {
    return 403;
}

# Caddy
@blocked path /papi/esearch/data/devops/*
respond @blocked 403

# Apache
<LocationMatch "^/papi/esearch/data/devops/">
    Require all denied
</LocationMatch>

Path-based blocking at the proxy is a stopgap, not a fix. The underlying deserialization gadget is still in the code; adjacent endpoints could be vulnerable. Apply the real patch as soon as your support channel delivers it.

4. Restart the application server. Confirm the patch is loaded.

5. Rotate every credential the OA system touches.

• E-cology admin account passwords (force reset)
• Database credentials used by E-cology (the connection-string credential)
• LDAP/AD bind credentials if E-cology has an LDAP integration
• Email-relay credentials (E-cology often holds an SMTP credential for outbound notifications)
• Any API keys for integrations (DingTalk, WeChat Work, custom enterprise integrations)
• Service account credentials for any system that E-cology calls into (HR system bridge, financial system bridge, document-store bridge)

Anything E-cology had a credential for, treat as exposed. The database read in the post-exploitation playbook above means the operator has hashed copies of every user password, and brute-forcing is cheap.

6. Force password reset for every E-cology user. All of them. The admin tools support a forced-reset flag on the user table. Set it. Users will be prompted to choose a new password on next login.

7. Audit user accounts created in the last 60 days. From the database query in the detection section. Any account you don't recognize: disable, then investigate. Don't delete — preserve for forensics.

8. Audit the role and permission tables for unauthorized grants. The same approach — pull the changes from the last 60 days, cross-reference against your change-management records.

9. Restore Web app integrity. If you found webshells, the cleanest answer is redeploy the entire E-cology web app from a known-clean WAR. Don't try to surgically delete shells one-by-one — there will always be one you missed. Stop Tomcat, blow away the webapps/ecology/ directory, redeploy from a clean WAR, restore configuration files (carefully — review them for malicious modifications), restart.

10. Reopen network access. Once patched, re-allow the legitimate users back in.

#Containment if compromised

If detection turned up evidence of compromise (Sorry.txt for ransomware, webshells in WEB-INF, unauthorized accounts, suspicious database queries), shift modes from "patch" to "incident response." The runbook:

Step 1. Continue isolation. Don't reopen network access until forensics is complete. Operations downtime is the cost of a thorough IR.

Step 2. Pull a memory image. On a Linux box, lime or avml. On Windows (which is most Chinese E-cology deployments), winpmem. Memory has unencrypted session keys, in-flight queries, attacker tooling residue. It is golden evidence.

Step 3. Preserve the disk image. The snapshot from step 1 of the patch flow. Tag it as forensic evidence, don't let it expire on a default snapshot retention policy.

Step 4. Commission a full forensic IR. This is the point at which you call in either your retained IR firm or — if you don't have one — find one. The work is: timeline reconstruction (which files were modified when, by whom), webshell analysis (what commands were run, what data was read), exfiltration analysis (what left the network, when, to where), persistence enumeration (what other accounts, shells, scheduled tasks, cron jobs, registry keys, init scripts were modified). This is multi-week work, not a one-day scramble.

Step 5. Decide between rebuild versus deep-clean. For an E-cology box that's been compromised for seven weeks, the honest professional answer is rebuild on a clean OS image and restore data from a known-clean backup, not deep-clean the existing system. Seven weeks is enough dwell time that the operator could have planted persistence in places forensics won't find. Trust the rebuild, not the cleanup.

Step 6. Restore data, not configuration. Follow the same shape as the cPanel ransomware post: restore the *data* (the database dump from a known-clean date, the user-uploaded documents from before compromise), but rebuild the *configuration* (E-cology installation, user permissions, integration settings) from your authoritative configuration sources. Operators plant config-level persistence (a malicious workflow, an extra admin user with a clean-looking name, a tampered authentication callback) that survives a "tar-restore everything" approach.

Step 7. Force-rotate everything one more time. After rebuild and restore, do another full credential rotation. Treat the pre-rebuild credentials as compromised even if you already rotated them once during patching, because you don't know exactly when persistence was established.

#Notification

Compromise of an OA platform is a notifiable event in most jurisdictions:

• China: PIPL (Personal Information Protection Law) requires notification to the Cyberspace Administration of China and to affected individuals when personal information is breached. The HR records and personnel data E-cology holds qualifies.
• China: DSL (Data Security Law) categorizes business data into tiers. Operational and contract data above certain thresholds requires regulatory notification.
• EU: If your E-cology deployment held data on EU data subjects (employees in EU subsidiaries, EU vendor contacts), GDPR Article 33 requires notification within 72 hours of becoming aware of the breach.
• US states: California, New York, and most other states have breach notification laws that apply to employee personal information held in HR systems. CCPA/CPRA covers California. SHIELD Act covers NY. The patchwork triggers depending on what data was held.
• Sector-specific: Financial services (NYDFS 23 NYCRR 500, SEC Cyber Disclosure Rule), healthcare (HIPAA OCR), defense (DFARS 7012) all have breach reporting timelines that the company must meet on top of the general data-protection laws.

Notify your customers, vendors, and counterparties whose contracts or data passed through the E-cology system. They have their own regulatory obligations triggered by your breach, and they cannot meet those obligations if you do not tell them in time.

The ugly truth on most E-cology compromises in the Chinese market historically: notification has been late, partial, or skipped, and regulators have not enforced. Don't rely on that pattern continuing. PIPL enforcement has been ramping. CSRC has been more active on listed-company disclosure failures. Western multinationals operating Chinese subsidiaries face additional exposure under their home-jurisdiction reporting rules.

#Tre's call — the pattern recognition

CVE-2024-23897 (Jenkins arbitrary file read), CVE-2026-31431 (Linux kernel local priv esc), CVE-2026-41940 (cPanel WHM auth bypass), and now CVE-2026-22679 (Weaver E-cology RCE). Same shape, every time:

1. Enterprise platform with a large customer base, frequently internet-facing
2. One vulnerability lands, often in a debug or admin-only interface that was never supposed to be reachable in production
3. Window of stealth exploitation between attacker discovery and public disclosure — for E-cology, seven weeks
4. Public disclosure
5. Mass exploitation by opportunistic actors who pile on after the disclosure
6. Long tail of unpatched instances exposed for months while the long-tail customer base catches up
7. The patient, well-funded threat actors (the ones who had the seven-week head start) used it to plant persistence and have already moved laterally; they're not coming back to use the patched bug, they're using the credentials and footholds they extracted while it was open

The defenders' lesson is depressingly consistent: assume any enterprise OA / collaboration / admin platform you operate on the public internet has at least one CVE being exploited at any given time. The math says so. The history says so. Plan accordingly.

That means:

• Don't expose admin platforms to the public internet if you can avoid it. E-cology, ServiceNow, Jenkins, Confluence, Jira admin, Atlassian Data Center products, GitLab self-managed, Active Directory web admin, vCenter, iLO/iDRAC management interfaces — none of these belong on the open internet. Tailscale, Cloudflare Access, Citrix Secure Workspace, Zscaler ZPA, or even just a VPN hop is the right answer.
• If you must expose, monitor aggressively. Web Application Firewall in front of the platform, log every request, alert on anomalous patterns. The seven weeks of stealth on the E-cology bug were possible because nobody was watching the /papi/esearch/data/devops/ path. A WAF rule that alerts on traffic to undocumented admin paths would have caught it on day 1.
• Patch within 7 days for high-severity admin platform CVEs, not within 90 days. The window between disclosure and mass exploitation is now measured in days, sometimes hours. A 30-day patch SLA is a guarantee of being in the long tail.
• Maintain an asset inventory that knows about your subsidiaries. The Chinese subsidiary running E-cology that the parent-company security team didn't know existed is a real pattern, and it's the one that gets you breached.

#Action items checklist

Today:

• [ ] Inventory whether your organization operates Weaver E-cology (including subsidiaries). Don't trust your asset DB without verifying.
• [ ] If yes: confirm version, identify exposure level (internet-facing or LAN-only)
• [ ] Block external access to E-cology at the network edge until patched
• [ ] Apply build 20260312+ patch (or vendor hotfix when delivered)
• [ ] Run all detection commands from this post; preserve outputs as IR baseline
• [ ] Rotate E-cology admin and integration credentials
• [ ] Force password reset for all E-cology users
• [ ] Audit user accounts and permissions created in last 60 days
• [ ] Notify customers, regulators, counterparties as legally required if compromise found

Within a week:

• [ ] Complete forensic IR if compromise indicators found
• [ ] Rebuild E-cology on clean infrastructure if compromise confirmed
• [ ] Implement WAF in front of E-cology with monitoring and alerting on unusual paths
• [ ] Move E-cology behind identity-aware proxy (Tailscale, Cloudflare Access) — remove from public internet permanently
• [ ] Update asset inventory with full subsidiary footprint
• [ ] Establish patch SLA of 7 days for critical CVEs on enterprise admin platforms
• [ ] Brief board / CIO if material compromise is identified

#How Valtik helps

We do incident response on enterprise OA / collaboration platform compromises, including E-cology, Confluence, Jenkins, GitLab, ServiceNow, and Atlassian Data Center installations. The work is forensic timeline reconstruction, persistence enumeration, exfiltration scope determination, and the rebuild/restore plan. We also do the proactive version of this engagement — the same runbook applied to your environment *before* the next CVE drops, with WAF rules, asset inventory work, and identity-aware proxy migration so the next E-cology-shaped event isn't an exposure for you.

If you operate E-cology and the seven-weeks-of-stealth detail in this post made your stomach drop, that's the right instinct. Reach out at hello@valtikstudios.com for E-cology incident response or for a proactive collaboration-platform security audit.

Patch. Detect. Contain. Notify. Same cycle every time. The discipline is in running the playbook fast enough to stay ahead of the long tail.