CVE-2026-22679: RCE Weaver E-cology sfruttata da marzo
Un endpoint di debug esposto in Weaver E-cology 10.0 consente RCE non autenticata. Attacchi rilevati dal 17 marzo 2026; la build 20260312 rimuove la falla.
Contenuto
Il 5 maggio 2026 il Vega Research Team ha reso noti i dettagli di una campagna di attacchi attiva da marzo 2026 contro le installazioni di Weaver E-cology 10.0. La vulnerabilità, catalogata come CVE-2026-22679 con un punteggio CVSS di 9.8, sfrutta un endpoint di debug Dubbo accessibile senza autenticazione per eseguire codice da remoto. Le organizzazioni che non hanno ancora applicato la build 20260312 rilasciata il 12 marzo 2026 si trovano esposte alla compromissione completa del sistema.
- L'endpoint
/papi/esearch/data/devops/dubboApi/debug/methodin Weaver E-cology 10.0 consente l'esecuzione remota di comandi senza alcuna forma di autenticazione. - Shadowserver Foundation ha rilevato i primi segni di exploitation attiva il 31 marzo 2026, mentre il Vega Research Team ha trovato evidenze di abuse già dal 17 marzo 2026.
- Gli attaccanti hanno tentato di distribuire un implant MSI denominato
fanwei0324.msie payload PowerShell, ma nei casi osservati le difese endpoint hanno bloccato l'esecuzione. - Il vendor ha rilasciato la build 20260312 il 12 marzo 2026, che rimuove fisicamente l'endpoint di debug vulnerabile.
L'endpoint Dubbo rimasto aperto: la catena di attacco
Il problema risiede in un endpoint di debug legato al framework Dubbo, raggiungibile all'indirizzo /papi/esearch/data/devops/dubboApi/debug/method. In Weaver E-cology 10.0, versioni precedenti alla build 20260312, questa URL risponde a richieste POST senza richiedere alcuna forma di autenticazione. Secondo la descrizione del National Vulnerability Database riportata da The Hacker News,
"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"— NIST National Vulnerability Database, via The Hacker News
I parametri controllabili dall'esterno raggiungono direttamente helper interni di esecuzione comandi, trasformando una semplice chiamata API in una shell di sistema. La criticità è massima: con un punteggio CVSS di 9.8, la falla consente a un attaccante non autenticato di prendere il controllo dell'host. Non si tratta di una complessa catena di exploit, ma di una porta di servizio lasciata aperta in produzione che espone direttamente la logica di esecuzione remota.
Timeline dell'intrusione: dal 17 marzo ai tentativi di installazione
Le prime tracce dell'attività malevola emergono in una finestra compresa tra la metà di marzo e la fine del mese. Il Vega Research Team ha individuato evidenze di abuse già il 17 marzo 2026, anche se non è possibile escludere che quella data corrisponda alla riproduzione di una proof of concept piuttosto che a exploitation reale. Shadowserver Foundation, dal canto suo, ha osservato i primi segni di attacchi attivi il 31 marzo 2026.
Secondo quanto riferito da The Hacker News citando Daniel Messing del Vega Research Team, "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". Durante questa fase, gli operatori hanno eseguito comandi di ricognizione classici come whoami, ipconfig e tasklist, confermando di aver ottenuto capacità di esecuzione remota.
Implant MSI e PowerShell: perché i payload non hanno preso piede
Nonostante l'accesso iniziale, la campagna osservata non ha portato a una compromissione persistente nei sistemi monitorati. Gli attaccanti hanno tentato di far installare un file MSI chiamato fanwei0324.msi, utilizzando la romanizzazione del nome del vendor, ma l'operazione non ha generato un'installazione funzionante. In parallelo, i threat actor hanno cercato di scaricare payload PowerShell da infrastrutture sotto loro controllo.
Il Vega Research Team, come riportato dal blog di Hendry Adrian, ha chiarito che "Endpoint defenses blocked downloads and execution, and attackers never established a persistent session on the targeted hosts". Resta tuttavia un limite: non è noto se l'implant MSI abbia avuto successo su target diversi da quelli coperti dalla visibilità del team. L'identità del gruppo responsabile è ignota e non esistono stime sul numero totale di vittime a livello globale.
Cosa fare adesso
La natura non autenticata della vulnerabilità e la presenza di exploitation attiva rendono l'aggiornamento una priorità assoluta. Ecco quattro azioni concrete per i team di sicurezza e gli amministratori di sistema.
- Aggiornare immediatamente a Weaver E-cology 10.0 build 20260312 o superiore. Il vendor ha rilasciato questa versione il 12 marzo 2026 per rimuovere fisicamente l'endpoint di debug vulnerabile.
- Verificare l'esposizione dell'endpoint
/papi/esearch/data/devops/dubboApi/debug/method. Se raggiungibile dalla rete interna o, peggio, da internet, va isolato o disabilitato fino all'applicazione della patch. - Analizzare i log delle applicazioni web e dei proxy per richieste POST sospette verso percorsi contenenti
dubboApi/debug/method, con particolare attenzione ai parametriinterfaceNameemethodNameanomali. - Utilizzare lo script Python pubblicato dal ricercatore Kerem Oruc per identificare eventuali istanze vulnerabili presenti nella propria infrastruttura.
Quando il debug rimane in produzione: il rischio enterprise
La persistenza di endpoint di sviluppo e debug in ambienti enterprise critici rappresenta una classe di rischio spesso sottostimata. Nel caso di Weaver E-cology 10.0, un'API di debug Dubbo è bastata a consentire l'esecuzione arbitraria di comandi senza alcuna barriera di autenticazione. La differenza tra una build di sviluppo e una release sicura è, in questo scenario, una singola route HTTP dimenticata.
Per il settore, l'incidente conferma che la rimozione degli strumenti di diagnostica prima del rilascio in produzione non è una buona pratica accessorio, ma un requisito di sicurezza. Le conseguenze concrete sono evidenti: aziende che gestiscono flussi di lavoro sensibili su piattaforme ERP si sono trovate esposte per settimane a compromissione totale, con un'unica richiesta HTTP a separare un attaccante esterno dalla shell di sistema.
Il caso CVE-2026-22679 dimostra che la superficie di attacco più pericolosa non è sempre una tecnologia zero-day sofisticata, ma un residuo di configurazione lasciato attivo per comodità. La rapidità con cui gli attaccanti hanno convertito la scoperta della falla in tentativi di implant, pur falliti nei casi noti, segnala un interesse operativo reale e non meramente sperimentale. Per chi amministra piattaforme enterprise, la lezione è immediata: la verifica della presenza di endpoint di debug esposti va inserita nei check pre-rilascio con la stessa rigidità riservata alla gestione delle patch.
Domande frequenti
La vulnerabilità interessa solo Weaver E-cology 10.0?
Secondo le fonti disponibili, la CPE associata a CVE-2026-22679 indica specificamente Weaver E-cology 10.0 in versioni precedenti alla build 20260312. Non risultano conferme ufficiali sull'estensione del problema ad altre major release.
Senza la patch, è possibile mitigare manualmente la minaccia?
Limitare l'accesso all'endpoint /papi/esearch/data/devops/dubboApi/debug/method e bloccare richieste POST non autenticate verso quella route riduce la superficie di attacco, ma la build 20260312 rimane l'unica contromisura definitiva documentata dal vendor.
L'attività osservata il 17 marzo 2026 è exploitation reale?
Il Vega Research Team ha trovato evidenze di abuse in quella data, ma non è in grado di escludere che si trattasse della riproduzione di una proof of concept anziché di un attacco mirato iniziato quello stesso giorno.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.