Weaver E-cology N-day RCE CVE-2026-22679: exploitation attiva tramite debug API
CVE-2026-22679 colpisce Weaver E-cology 10.0 con RCE non autenticato sull’endpoint Dubbo debug. Attacchi in-the-wild dal 17 marzo 2026. Patch disponibile dal 1…
Contenuto
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Cinque giorni dopo il rilascio della patch del 12 marzo 2026, l’endpoint di debug Dubbo di Weaver E-cology 10.0 era già sotto attacco. Il Vega Research Team ha confermato exploitation in-the-wild a partire dal 17 marzo 2026, sfruttando la vulnerabilità CVE-2026-22679 per eseguire codice da remoto senza autenticazione. La finestra compressa tra correzione e abuso evidenzia un pattern ricorrente: piattaforme enterprise in cui endpoint di amministrazione interna restano esposti a Internet trasformano gli N-day in armi a raggio zero.
Punti chiave
- CVE-2026-22679 è una vulnerabilità RCE non autenticata in Weaver (Fanwei) E-cology 10.0, con punteggio CVSS 9.8.
- L’endpoint vulnerabile è
/papi/esearch/data/devops/dubboApi/debug/method, accessibile senza autenticazione. - Il vendor ha rilasciato la patch il 12 marzo 2026 (build 20260312); l’exploitation in-the-wild è iniziata il 17 marzo 2026, cinque giorni dopo.
- La campagna ha incluso verifica RCE tramite ping.exe, tentativi di drop di payload PowerShell e deploy di un MSI denominato fanwei0324.msi.
- Kerem Oruc ha pubblicato uno script Python di detection per identificare istanze vulnerabili.
La vulnerabilità CVE-2026-22679
La vulnerabilità CVE-2026-22679 interessa la piattaforma enterprise Weaver (Fanwei) E-cology 10.0. Il National Vulnerability Database (NVD) classifica la falla come Remote Code Execution non autenticata e le assegna un punteggio CVSS di 9.8. Le build precedenti al numero 20260312 risultano vulnerabili.
L’endpoint vulnerabile è /papi/esearch/data/devops/dubboApi/debug/method. Il percorso è accessibile senza autenticazione e consente a un attaccante remoto di inviare richieste HTTP POST per interagire con il sistema sottostante.
Secondo la descrizione del NVD riportata da The Hacker News, gli aggressori possono creare richieste POST con parametri interfaceName e methodName controllati per raggiungere helper di esecuzione comandi e ottenere l’esecuzione arbitraria di codice sul sistema target.
Il vendor Weaver ha rilasciato la patch il 12 marzo 2026. L’aggiornamento rimuove l’endpoint di debug nelle build 20260312 e successive. I sistemi che non hanno applicato la correzione rimangono esposti a richieste POST malevole che sfruttano i parametri interfaceName e methodName.
L’esposizione di endpoint di debug Dubbo in piattaforme enterprise come E-cology rappresenta un pattern ricorrente e particolarmente pericoloso: servizi destinati all’amministrazione interna restano accessibili da Internet, offrendo a un attaccante remoto una superficie di attacco senza autenticazione e con privilegi elevati sul sistema sottostante.
Exploitation in-the-wild confermata dal 17 marzo 2026
Il Vega Research Team ha documentato exploitation in-the-wild a partire dal 17 marzo 2026. Questa data è posteriore di cinque giorni al rilascio della patch del vendor, avvenuto il 12 marzo 2026. La finestra ridotta classifica l’attacco come exploit N-day ad alta velocità.
QiAnXin ha riprodotto con successo la vulnerabilità in un alert pubblicato il 17 marzo 2026. La Shadowserver Foundation ha rilevato i primi segni di exploitation attivo il 31 marzo 2026. Entrambe le organizzazioni confermano che la falla è stata sfruttata attivamente in rete.
Daniel Messing del Vega Research Team ha descritto l’intrusione confermata in un caso specifico. La sua analisi riporta: “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”.
Nel caso esaminato, tutta l’attività malevola ha avuto origine dal processo java.exe su un server Windows target. La prima fase ha usato ping.exe verso l’indirizzo 152.32.173[.]138 per verificare l’RCE: l’output del comando è stato restituito nelle risposte HTTP, confermando all’attaccante la possibilità di eseguire codice a piacimento.
A conferma ottenuta, gli operatori hanno tentato tre volte di far scendere payload PowerShell senza successo. Hanno poi provato a piazzare un pacchetto MSI chiamato fanwei0324.msi, mascherato da componente legittima del vendor tramite la romanizzazione cinese di Fanwei, ma nell’ambiente osservato l’installazione non ha funzionato. Infine, un breve burst di richieste ha cercato di recuperare payload PowerShell da infrastrutture controllate dall’attaccante.
Indicatori di compromissione e dettagli tecnici
Oltre al payload MSI, la campagna ha eseguito comandi di discovery quali whoami, ipconfig e tasklist. Il file fanwei0324.msi è identificato dall’hash SHA256 147ac3f24b2b63544d65070007888195a98d30e380f2d480edffb3f07a78377f.
Le fonti non specificano se il payload MSI abbia avuto successo in ambienti diversi da quello analizzato. L’identità del threat actor e il numero esatto di vittime globali rimangono al momento non determinati.
“Attackers can craft POST requests with attacker-controlled interfaceName and methodName parameters to reach command-execution helpers and achieve arbitrary command execution on the system” — NVD, riportato da The Hacker News
Il ruolo delle organizzazioni di intelligence
Il divario di quasi due settimane tra il rilevamento di Vega il 17 marzo e quello di Shadowserver il 31 marzo non è un semplice ritardo amministrativo, ma un campione di diverso intervallo di visibilità threat intelligence. Durante questo lasso, la compromissione era già in corso, visibile solo al team che aveva accesso diretto alla telemetria della vittima.
Questo “dark period” amplifica il rischio per le organizzazioni che dipendono esclusivamente da feed di intelligence globali: un sistema vulnerabile può restare sotto attacco per giorni prima che i segnali emergano nelle fonti pubbliche. QiAnXin ha confermato la riproducibilità della falla il 17 marzo 2026, offrendo una prima validazione tecnica indipendente.
Kerem Oruc ha rilasciato uno strumento di detection open source che consente alle squadre di sicurezza di verificare autonomamente la presenza della vulnerabilità sui propri asset. Strumenti di questo tipo riducono la dipendenza dai cicli di intelligence centralizzata e accorciano il tempo di reazione prima che i dati di scansione globale diventino disponibili.
Cosa fare adesso
Le organizzazioni che utilizzano Weaver E-cology 10.0 devono verificare immediatamente di aver applicato la build 20260312 o successiva. Il vendor ha rilasciato la patch il 12 marzo 2026. È necessario confermare che l’endpoint /papi/esearch/data/devops/dubboApi/debug/method non sia più raggiungibile da reti non autorizzate.
Gli operatori di sicurezza dovrebbero monitorare i log applicativi e di rete per richieste POST anomale dirette al percorso Dubbo debug. È opportuno cercare esecuzioni di ping.exe, whoami, ipconfig e tasklist avviate dal processo java.exe sui server Windows che ospitano E-cology 10.0.
È consigliato controllare la presenza del file fanwei0324.msi o dell’hash SHA256 147ac3f24b2b63544d65070007888195a98d30e380f2d480edffb3f07a78377f all’interno degli ambienti Weaver. Il tool di Kerem Oruc può supportare la fase di risposta agli incidenti e la verifica della postura di sicurezza sui sistemi E-cology 10.0.
Le reti che ospitano istanze Weaver E-cology 10.0 dovrebbero limitare l’esposizione dell’endpoint Dubbo debug ai soli indirizzi interni necessari. La segmentazione di rete riduce il rischio di scansione e sfruttamento da parte di attori esterni non autenticati.
La verifica dovrebbe essere estesa a tutti i nodi che eseguono build precedenti al 20260312, incluse eventuali istanze di test o staging. Anche sistemi non esposti direttamente a Internet possono essere attraversati da un attaccante che abbia già un punto d’appoggio nella rete.
Il rischio residuo resta concreto: cinque giorni tra patch e exploitation dimostrano che il tempo di reazione delle difese enterprise è spesso più lento della velocità con cui gli attori della minaccia convertono una correzione in un’arma operativa. Senza una riduzione drastica del tempo di patching e senza visibilità locale su endpoint di debug esposti, ogni N-day continuerà a comportare un finestrale di esposizione misurato in ore, non in settimane.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.