TLDR

  • Il 16 ottobre 2026 CSIRT Italia ha segnalato la compromissione di un server Nextcloud italiano tramite la CVE-2026-110447, gravità critica, CVSS 4.0 pari a 9.2.
  • La falla è una command injection nel file proxy.php di richdocumentscode, il server Collabora CODE integrato in Nextcloud, sfruttabile senza autenticazione.
  • L'attaccante ha installato tre webshell e prelevato un file di configurazione con credenziali di database, posta di servizio e segreti applicativi.
  • Aggiornare richdocumentscode alla 26.4.303 o rimuoverlo: disattivarlo dall'interfaccia non basta. Poi cercare webshell e ruotare tutti i segreti.

Perché conta ora

Se hai un Nextcloud con la suite documentale integrata, fermati cinque minuti e controlla la versione di un componente che probabilmente non ricordi nemmeno di aver installato.

Il 16 ottobre 2026 CSIRT Italia, il team di risposta agli incidenti dell'Agenzia per la cybersicurezza nazionale, ha pubblicato un bollettino su una compromissione reale, avvenuta in Italia, di un server Nextcloud usato per un servizio documentale.

La porta d'ingresso è la CVE-2026-110447, gravità critica, CVSS 4.0 pari a 9.2, nel componente Collabora Online - Built-in CODE Server, l'app richdocumentscode. È quella che permette di modificare documenti Office direttamente da Nextcloud senza installare un server Collabora separato.

La parte peggiore del bollettino è una riga: le evidenze sono compatibili con una campagna di sfruttamento automatizzata, tuttora attiva e condotta da più attori.

Tradotto: qualcuno sta scansionando Internet alla ricerca di questi server. Non è una questione di se, ma di quando.

Come funziona la vulnerabilità

La falla è di tipo OS command injection e sta nel file proxy.php del componente.

In sintesi:

  • proxy.php non valida correttamente alcuni parametri in ingresso;
  • un attaccante remoto non autenticato può inviare richieste HTTP costruite ad arte;
  • i parametri finiscono in un comando di sistema;
  • il comando viene eseguito con i privilegi dell'utente del web server.

C'è una condizione interessante: secondo l'avviso, lo sfruttamento è possibile quando il servizio CODE integrato non è in esecuzione, per esempio dopo un riavvio, un aggiornamento o un crash.

Sembra un limite, ma su un server reale è una situazione frequente. E un attaccante paziente, con una scansione automatica, prima o poi ci passa nel momento giusto.

La vulnerabilità riguarda solo questa modalità di distribuzione integrata. I server Collabora Online installati separatamente non sono interessati.

Cosa è successo nel caso italiano

Il bollettino descrive una catena classica e molto efficace:

  1. sfruttamento del componente vulnerabile sul server Nextcloud;
  2. installazione di tre webshell, cioè file che permettono di inviare comandi al server via browser;
  3. prelievo di un file di configurazione che conteneva credenziali del database locale, credenziali di una casella di posta di servizio, chiavi e segreti applicativi.

Dalle evidenze risulta un solo comando di verifica eseguito tramite una webshell. Al momento non sono emersi accessi ai documenti degli utenti, privilegi amministrativi, altri meccanismi di persistenza o movimenti laterali.

Bene, ma non benissimo. I segreti sono usciti. E con credenziali di database e di posta in mano, l'attaccante può tornare quando vuole, anche dopo la patch.

Cosa fare subito

Questa è la parte da stampare.

1. Aggiorna o rimuovi.

  • Aggiorna richdocumentscode alla versione 26.4.303 o successiva.
  • Se non puoi aggiornare, rimuovi il componente. Disattivarlo dall'interfaccia di Nextcloud non è una mitigazione sufficiente.
  • Se la tua versione di Nextcloud non è più supportata, aggiorna la piattaforma a una versione compatibile con il componente corretto, oppure rimuovi richdocumentscode.

2. Cerca le tracce.

  • Verifica l'integrità del core di Nextcloud e delle app installate. Il comando occ integrity:check-core è un buon punto di partenza.
  • Cerca file non autorizzati e possibili webshell, anche nella directory del componente vulnerabile.
  • Controlla i log del web server e del reverse proxy alla ricerca di richieste anomale verso proxy.php e di attività successive sospette.

3. Se trovi qualcosa, tratta il server come compromesso.

  • Isola il sistema.
  • Conserva le evidenze prima di pulire: log, file sospetti, timestamp.
  • Estendi le verifiche alle altre istanze e a tutto ciò che è raggiungibile con le credenziali esposte.

4. Ruota i segreti.

Anche se non trovi nulla, se il componente era esposto e vulnerabile considera esposti i segreti presenti in configurazione:

  • password del database;
  • credenziali delle caselle di posta di servizio;
  • chiavi e segreti applicativi;
  • eventuali certificati associati.

La rotazione va fatta da un ambiente attendibile, non dal server sospetto.

5. Valuta la ricostruzione.

Per un sistema compromesso, la strada più sicura è ricostruirlo da fonti affidabili e ripristinare solo dati verificati.

Hardening: per non ritrovarsi qui il mese prossimo

CSIRT Italia chiude con indicazioni che valgono per qualsiasi server applicativo esposto:

  • rimuovi app e componenti non necessari o non più supportati;
  • esponi su Internet solo le funzioni che servono davvero e tieni l'amministrazione dietro VPN o reti dedicate;
  • segmenta la rete, così che il server applicativo parli solo con ciò che gli serve;
  • usa utenze distinte e con privilegi minimi per web server, database e posta, e proteggi i file di configurazione;
  • centralizza i log, monitora l'integrità dei file e configura avvisi per modifiche e processi anomali.

Errori comuni

"Ho disattivato l'app, sono a posto." No, va aggiornata o rimossa. Il bollettino è esplicito su questo punto.

"Ho aggiornato, non serve controllare." La patch chiude la porta, ma non caccia chi è già entrato. Una webshell installata la settimana scorsa resta lì.

"Nessuno attacca il mio piccolo Nextcloud." La campagna è automatizzata. Gli scanner non guardano chi sei, guardano che versione esponi.

"Il CODE integrato è comodo, lo lascio." Comodo sì, ma è un componente in più esposto su Internet. Per un uso aziendale stabile, un server Collabora separato e gestito è spesso la scelta più pulita.

La cosa da ricordare

Le falle che fanno più danni non sono sempre quelle nei prodotti famosi. Sono quelle nei componenti accessori, installati una volta con un clic e mai più guardati.

Patch, caccia alle webshell, rotazione dei segreti. In quest'ordine, oggi.

Se gestisci servizi esposti da casa o in un piccolo ufficio, leggi anche Cloudflare Tunnel: esporre localhost senza aprire porte a caso.

FAQ

Quali installazioni sono vulnerabili?

Quelle che usano il componente Collabora Online Built-in CODE Server per Nextcloud, cioè l'app richdocumentscode, in versioni precedenti alla 26.4.303. I server Collabora Online installati separatamente non sono interessati.

Basta disattivare l'app da Nextcloud?

No. CSIRT Italia specifica che la sola disabilitazione dall'interfaccia di Nextcloud non è una mitigazione sufficiente. Se non puoi aggiornare, il componente va rimosso.

Quando è sfruttabile la vulnerabilità?

Secondo l'avviso, lo sfruttamento è possibile quando il servizio CODE integrato non è in esecuzione, per esempio dopo un riavvio, un aggiornamento o un arresto anomalo. È una condizione che può verificarsi spesso su un server reale.

Ho aggiornato, sono al sicuro?

Solo se il server non era già stato compromesso. La campagna è automatizzata e attiva: va verificata la presenza di file non autorizzati e webshell, vanno controllati i log delle richieste a proxy.php e vanno ruotati credenziali e segreti presenti nella configurazione.

Cosa fare se trovo una webshell?

Isolare il sistema, conservare le evidenze prima della bonifica, estendere le verifiche alle risorse raggiungibili con le credenziali esposte, ruotare tutti i segreti da un ambiente pulito e valutare la ricostruzione del server da fonti attendibili. Le organizzazioni soggette a NIS devono valutare anche gli obblighi di notifica.

Fonti