← Torna al blog

Briefing sicurezza, 5 maggio 2026: RCE di Weaver, Copy Fail, backdoor in PyTorch Lightning e phishing con Amazon SES

Il modello di questa mattina è l’effetto leva attraverso infrastruttura fidata: software di workflow, kernel Linux, dipendenze di sviluppo ed e-mail cloud legittima diventano corsie veloci di attacco quando i team danno per sicuro il canale stesso.

---

---

1. Weaver E-cology ricorda che i percorsi di debug nascosti diventano veri percorsi di intrusione

BleepingComputer riferisce che CVE-2026-22679 in Weaver E-cology viene sfruttata da metà marzo. Vega descrive una RCE senza autenticazione tramite una API di debug esposta che permetteva ai parametri controllati dall’attaccante di raggiungere funzioni RPC backend e comandi di sistema. L’attività osservata include ricognizione, payload PowerShell e recuperi ripetuti di script fileless.

• Aggiornate immediatamente qualsiasi build Weaver E-cology 10.0 precedente alla fix del 12 marzo.
• Cercate sui server colpiti attività whoami, ipconfig, tasklist, ping e PowerShell avviate da java.exe.
• Trattate i sistemi collaborativi esposti come possibili appoggi per il movimento laterale, non solo come piattaforme documentali.

---

2. Copy Fail è già passato dal paper al rischio reale di root

CISA ha aggiunto CVE-2026-31431, nota come Copy Fail, al catalogo KEV un giorno dopo la divulgazione pubblica. Il bug si trova nell’interfaccia algif_aead e consente a utenti locali non privilegiati di ottenere root scrivendo byte controllati nella page cache di qualsiasi file leggibile. Theori afferma che lo stesso exploit ha funzionato in modo affidabile su Ubuntu, Amazon Linux, RHEL e SUSE.

• Date priorità agli aggiornamenti del kernel sui sistemi Linux esposti a Internet e sui server multiutente.
• Considerate sospetta ogni distribuzione costruita nella finestra vulnerabile dal 2017 finché non è patchata.
• Non liquidate il problema come banale escalation locale: dopo l’accesso iniziale, root è il vero obiettivo.

---

3. PyTorch Lightning 2.6.3 ha trasformato una dipendenza AI molto usata in una trappola per segreti all’import

Una release malevola di lightning 2.6.3 su PyPI scaricava automaticamente Bun ed eseguiva un payload JavaScript offuscato al momento dell’import. Secondo il report, il payload puntava a dati del browser, file .env, chiavi API, credenziali cloud e supportava esecuzione arbitraria di comandi. Con oltre 11 milioni di download al mese, non serve una diffusione enorme per causare una grave rottura di fiducia.

• Rimuovete subito lightning 2.6.3 e bloccate una release nota come sicura.
• Ruotate token, chiavi API, credenziali cloud e segreti su ogni sistema che ha importato la versione malevola.
• Rivedete le pipeline di build per le assunzioni cieche sulle dipendenze, soprattutto dove l’esecuzione all’import può nascondersi.

---

4. Il phishing via Amazon SES mostra come la fiducia cloud neutralizza le difese basate sulla reputazione

Kaspersky osserva un aumento di phishing inviato tramite Amazon SES, spesso reso possibile da chiavi AWS IAM esposte in repository pubblici, file .env, backup, immagini o bucket S3 aperti. Poiché i messaggi partono da infrastruttura SES legittima, possono superare SPF, DKIM e DMARC e rendere molto meno efficaci i blocchi tradizionali.

• Eseguite audit per chiavi AWS esposte e riducete i permessi SES al minimo necessario.
• Ruotate le chiavi, imponete MFA e aggiungete restrizioni IP dove possibile per le identità di invio.
• Estendete il rilevamento phishing oltre la reputazione del mittente e controllate comportamento, link e pattern di invio insoliti.

---

Cosa dovrebbero fare oggi i team di sicurezza

1. Patchare Weaver E-cology e i kernel Linux vulnerabili prima di qualsiasi attività di igiene meno prioritaria.
2. Controllare inventari software e pipeline CI per lightning 2.6.3, poi ruotare ogni segreto coinvolto.
3. Rivedere i percorsi di esposizione AWS IAM e trattare l’abuso di SES come un fallimento di identità e gestione dei segreti.
4. Allineare i responder sul tema di oggi: anche l’infrastruttura fidata va verificata, che si tratti di endpoint di debug, kernel, pacchetti o cloud mail.

---

---

Conclusione: L’errore comune di oggi è fidarsi troppo di canali che sembrano legittimi. La risposta è noiosa ma giusta: patch rapide, rotazione immediata dei segreti e verifica di ogni piattaforma fidata come se fosse già parte del percorso di attacco.