Microsoft rilascia fix manuale per WSUS mentre crescono gli attacchi RCE su WordPress

🛡️ Executive Summary

• L’accumulo di metadata in SUSDB causa timeout e ritardi nelle sincronizzazioni WSUS, bloccando scansione e distribuzione degli aggiornamenti Windows.
• La catena wp2shell sfrutta CVE-2026-63030 e CVE-2026-60137 per ottenere esecuzione di codice pre-auth sui siti WordPress vulnerabili.
• Gli amministratori devono pulire ogni database WSUS seguendo Microsoft e aggiornare immediatamente WordPress, verificando eventuali indicatori di compromissione.

Microsoft ha pubblicato una procedura manuale per ripristinare le sincronizzazioni dei server Windows Server Update Services, rallentate o interrotte dall’accumulo di metadata nel database SUSDB. Nello stesso momento cresce l’attività offensiva contro installazioni WordPress vulnerabili alla catena wp2shell, composta da due falle critiche che consentono l’esecuzione remota di codice senza autenticazione. I due problemi richiedono interventi differenti ma ugualmente prioritari: WSUS deve tornare operativo per non ritardare la distribuzione delle patch aziendali, mentre i siti WordPress esposti devono essere aggiornati e controllati per escludere compromissioni già avvenute.

La pulizia di SUSDB ripristina le sincronizzazioni WSUS

Il malfunzionamento di WSUS deriva dall’accumulo di metadata di pubblicazione non più necessari, che appesantiscono le interrogazioni del database e allungano progressivamente i tempi di sincronizzazione. Nei casi più gravi, l’operazione termina con un timeout e impedisce al server di acquisire le informazioni sugli aggiornamenti disponibili per client e server Windows. L’impatto si estende anche agli ambienti che utilizzano Microsoft Configuration Manager, perché la piattaforma dipende dal catalogo WSUS per scansione, approvazione e distribuzione delle patch. Microsoft aveva già applicato una mitigazione lato servizio alle installazioni nuove o ricostruite, mentre i server esistenti richiedono ora un intervento su ogni database SUSDB. Il problema si inserisce in una fase particolarmente delicata, successiva al Patch Tuesday di luglio 2026 con centinaia di vulnerabilità corrette: una sincronizzazione incompleta può impedire alle aziende di visualizzare e distribuire aggiornamenti già disponibili, aumentando il tempo di esposizione dei sistemi. Sono interessate le infrastrutture che gestiscono Windows 10 dalla versione 1607 in avanti e Windows Server 2012 o release successive, comprese installazioni datate che dipendono ancora interamente dalla distribuzione locale.

Il fix richiede backup, query SQL e manutenzione del server

La procedura indicata da Microsoft deve iniziare con un backup completo di SUSDB, necessario per ripristinare il servizio in caso di errori durante la pulizia. Gli amministratori devono quindi collegarsi al database attraverso SQL Server Management Studio o strumenti equivalenti ed eseguire la query fornita per rimuovere i metadata problematici. Il passaggio va ripetuto su ogni database WSUS presente nell’ambiente, comprese eventuali repliche o istanze separate utilizzate da siti Configuration Manager differenti. Al termine occorre riportare MaxXMLPerRequest al valore predefinito, perché modifiche temporanee a questo parametro possono essere state utilizzate come workaround per consentire il completamento delle scansioni più pesanti. Microsoft avverte che la prima scansione successiva alla pulizia potrebbe richiedere più tempo, poiché client e server devono ricostruire parte dello stato degli aggiornamenti; le operazioni successive dovrebbero invece tornare ai tempi normali. Sono raccomandate anche la reindicizzazione di SUSDB, l’esecuzione della WSUS Server Cleanup Wizard e il riavvio di IIS o il riciclo del pool WsusPool. Il file client DataStore.edb non si riduce automaticamente dopo la rimozione dei detectoid, ma la dimensione residua non dovrebbe penalizzare le prestazioni. La manutenzione conferma le difficoltà operative già emerse durante i precedenti problemi WSUS e le modifiche al ciclo degli aggiornamenti Windows.

wp2shell consente RCE senza autenticazione su WordPress

Sul fronte web, gli aggressori stanno sfruttando CVE-2026-63030 e CVE-2026-60137, due vulnerabilità critiche riunite nella catena denominata wp2shell. L’exploit permette a un utente remoto non autenticato di raggiungere l’esecuzione di codice sul server e ottenere il controllo completo dell’installazione WordPress. Le falle interessano le installazioni predefinite pubblicate da dicembre 2025 in avanti e hanno registrato una rapida crescita degli attacchi dopo la diffusione del codice dimostrativo. Le prime attività osservate puntavano all’esfiltrazione di hash e credenziali, mentre la disponibilità di maggiori dettagli tecnici ha consentito agli operatori di passare alla RCE completa. Il percorso segue una dinamica ricorrente nelle campagne contro i CMS: la divulgazione pubblica riduce drasticamente il tempo necessario per trasformare una vulnerabilità in scansioni automatizzate su larga scala. A luglio erano già state documentate campagne globali contro WordPress e Joomla capaci di installare web shell, mentre la precedente operazione WP-SHELLSTORM aveva mostrato l’interesse degli attaccanti per l’accesso persistente ai siti WordPress. wp2shell alza ulteriormente il rischio perché non richiede credenziali, plugin amministrativi compromessi o interazioni con un utente autenticato.

Le scansioni di massa arrivano da infrastrutture distribuite

La telemetria disponibile ha identificato almeno 13 indirizzi IP coinvolti nello sfruttamento, distribuiti tra Svizzera, Germania, Regno Unito, Indonesia, Lituania, Paesi Bassi e Singapore. La provenienza geografica non attribuisce l’attacco agli operatori presenti in quei Paesi, perché VPS, proxy e server compromessi vengono normalmente utilizzati come nodi intermedi. Il dato dimostra però che l’attività non dipende da un’unica infrastruttura facilmente bloccabile e che le scansioni possono continuare anche dopo il filtraggio dei primi indirizzi.

Una RCE WordPress permette di caricare web shell, modificare temi e plugin, creare account amministrativi, rubare configurazioni e utilizzare il sito per phishing, redirect, spam o distribuzione di malware. Le organizzazioni devono aggiornare immediatamente il core alle versioni corrette e verificare l’integrità dei file, la presenza di utenti sconosciuti, cron job anomali e modifiche recenti nelle directory wp-content, wp-includes e wp-admin. Devono essere controllati anche log HTTP contenenti richieste insolite, processi PHP avviati con argomenti inattesi e connessioni in uscita dal web server. La semplice applicazione della patch non elimina eventuali backdoor installate prima dell’aggiornamento, come mostrato dalle numerose compromissioni supply-chain dei plugin WordPress.

WSUS e WordPress richiedono due piani di risposta distinti

Per WSUS la priorità consiste nel ripristinare la capacità di sincronizzare e distribuire gli aggiornamenti senza danneggiare il database. La procedura va quindi pianificata, testata su una copia di SUSDB e accompagnata da verifiche sulle approvazioni, sui gruppi di computer e sull’integrazione con Configuration Manager. Nel caso di WordPress, lo sfruttamento attivo impone invece una risposta da incidente: aggiornamento immediato, analisi dei log, ricerca di persistenza e rotazione delle credenziali amministrative, del database, dell’hosting e delle chiavi applicative. I siti che non possono essere corretti rapidamente devono essere isolati o resi temporaneamente non raggiungibili, perché firewall e blocchi IP offrono una protezione limitata contro exploit distribuiti. Le due emergenze sono collegate dalla stessa dipendenza operativa: un’infrastruttura di aggiornamento rallentata può ritardare le patch proprio mentre vulnerabilità pubbliche vengono convertite in attacchi automatizzati. Ripristinare WSUS e chiudere wp2shell non sono quindi attività separate, ma parti dello stesso processo di riduzione del tempo tra disponibilità della correzione e protezione effettiva dei sistemi.