Collabora Online CVE-2026-110447: RCE sul CODE Server integrato, sfruttata in rete

Il 23 ottobre CISA ha inserito CVE-2026-110447 nel catalogo Known Exploited Vulnerabilities, fissando al 26 ottobre la scadenza per le agenzie federali USA. È una command injection OS non autenticata nel Built-in CODE Server di Collabora Online — l'app richdocumentscode che porta l'editing documentale dentro Nextcloud — con un punteggio CVSS 4.0 di 9.2. Il problema non è il punteggio. È che la falla è sfruttata in rete da settembre, che la finestra vulnerabile si riapre a ogni riavvio del servizio, e che gli amministratori stanno trovando web shell che sopravvivono alla patch.

Notizia in evoluzione — pubblicata alle 09:43 (07:43 UTC) del 24 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-110447
Prodotto / versioni colpite	Collabora Online – Built-in CODE Server (richdocumentscode) · versioni precedenti alla 26.4.303 · è colpita solo l'app integrata in Nextcloud; il Collabora Online standalone e il CODE server via Docker/pacchetto non lo sono
Corretta in	richdocumentscode 26.4.303
CVSS	9.2 Critica · CVSS 4.0 · assegnato da MITRE come CNA (Secondary); NVD non ha un punteggio primario · vettore CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Sfruttata attivamente	Sì · settembre–ottobre 2026 secondo NVD; amministratori Nextcloud segnalano web shell trovate
CISA KEV	Aggiunta 2026-10-23; scadenza federale 2026-10-26 (BOD 26-04, triage forense richiesto)
PoC pubblico	Nessun PoC pubblicato dal vendor al 2026-10-24; sfruttamento osservato dagli amministratori Nextcloud
Advisory ufficiale	GHSA-g3vx-3m76-fghh

Cosa è successo

L'editor documentale integrato di Nextcloud fa girare un server Collabora Online Development Edition (CODE) in bundle. Le richieste dal browser arrivano a un endpoint PHP, proxy.php, che le inoltra a quel server CODE locale. Quando il server CODE non è in esecuzione — subito dopo il riavvio di un container, un aggiornamento o un crash — proxy.php imbocca un percorso di codice che lo avvia costruendo un comando di shell ed eseguendolo tramite la exec di PHP. L'input controllato dall'attaccante nella richiesta raggiunge quel comando senza sanitizzazione. Il risultato, secondo l'advisory del vendor, è l'esecuzione di comandi arbitrari del sistema operativo con l'utente del web server, senza autenticazione.

Quella precondizione — "quando il server CODE non è in esecuzione" — è il motivo per cui il vettore CVSS 4.0 porta AT:P (attack requirements present) invece di un 9.8 pieno: all'attaccante serve che il servizio sia giù. In pratica non è un gran ostacolo: la finestra si apre a ogni riavvio, e un attaccante paziente può semplicemente continuare a sondare proxy.php finché non si apre. Il record NVD indica sfruttamento in rete a settembre e ottobre 2026, e precisa che è un bug distinto dal precedente CVE-2025-66208 — la correzione di quello non chiude questo percorso.

Il vendor ha pubblicato l'advisory il 14 ottobre; il primo avviso agli amministratori era comparso sul forum ufficiale Nextcloud il 3 ottobre, prima che esistesse un CVE. La voce KEV di CISA è arrivata il 23 ottobre con forensicTriage: Yes — la direttiva si aspetta che tu assuma la compromissione e verifichi, non solo che applichi la patch.

Chi è esposto, e come verificarlo

Sei colpito solo se usi l'app CODE server integrata dentro Nextcloud. Per verificare da riga di comando sull'host Nextcloud:

sudo -u www-data php occ app:list | grep -i richdocumentscode

Se richdocumentscode è elencato alla versione 26.4.302 o precedente, sei vulnerabile. Non sei colpito se servi i documenti con richdocuments puntato a un server Collabora Online separato (immagine Docker, pacchetto Linux o un provider in hosting) — solo l'app CODE autonoma incorpora il proxy.php vulnerabile.

"Abbiamo appena applicato la patch" qui non chiude il discorso. Se hai eseguito una versione vulnerabile in qualsiasi momento da inizio settembre e il tuo server CODE si è mai riavviato, dai per scontato che la finestra fosse aperta e vai a cercare — la patch ferma la nuova injection, non rimuove una shell già piazzata.

Remediation

1. Sono colpito? Esegui il controllo occ app:list qui sopra. Qualsiasi richdocumentscode sotto la 26.4.303 è in scope. Le istanze Nextcloud esposte su internet con l'editor integrato sono la priorità.

2. Patch — versione corretta esatta. Aggiorna l'app Built-in CODE Server a richdocumentscode 26.4.303 o successiva (App → le tue app installate → aggiorna, oppure sudo -u www-data php occ app:update richdocumentscode). Il vendor è esplicito: disabilitare l'app non basta — il proxy.php vulnerabile resta a bordo. Se non puoi aggiornare subito, rimuovi l'app e servi i documenti da un server Collabora Online standalone. Le istanze Nextcloud a fine vita (≤ 29) devono prima aggiornare Nextcloud.

3. Non puoi applicare la patch ora? Controlli compensativi. Rimuovi richdocumentscode invece di lasciare una copia disabilitata ma presente. Se la rimozione non è possibile in quest'ora, limita la raggiungibilità di rete dell'istanza Nextcloud e mettila dietro un filtro così che proxy.php non sia raggiungibile da client non autenticati — ma consideralo un tampone da ore, non una correzione.

4. Cerca segni di compromissione. Gli amministratori sul forum ufficiale Nextcloud segnalano indicatori concreti — trattali come segnalazioni della community, non confermati dal vendor, e verificali contro le tue evidenze:

• Una web shell piazzata in ./apps/richdocumentscode/Nx_33143.php, segnalata contenere una backdoor system($_GET[c]) su una riga; nomi precedenti seguivano i pattern shx* e shrf*.
• File .php inattesi ovunque sotto apps/richdocumentscode/ — il controllo di integrità li segnala come EXTRA_FILE (sudo -u www-data php occ integrity:check-app richdocumentscode).
• Accessi nei log del web server a proxy.php (incluso proxy.php?status) — rivedi fino al 10 settembre 2026.

Mappatura su MITRE ATT&CK: accesso iniziale tramite sfruttamento di un'applicazione pubblica (T1190), web shell per la persistenza (T1505.003), esecuzione di comandi tramite l'utente del web server (T1059).

5. Eradica e verifica. Rimuovi ogni web shell trovata, poi ruota ogni credenziale leggibile dall'utente del web server — password dei database, app password, token API, credenziali di posta — perché l'esecuzione di comandi come www-data le rendeva leggibili. Applica la patch e poi ricontrolla: una shell piazzata prima dell'aggiornamento sopravvive all'aggiornamento, e perfino alla rimozione dell'app. L'unica conclusione sicura è quella raggiunta ispezionando l'host, non leggendo la stringa di versione. Per l'inquadramento della scadenza, vedi la guida al patching basato sul rischio BOD 26-04 di CISA.

Cosa non si sa ancora

• Nessuna attribuzione pubblica. Chi stia sfruttando la falla, e se si tratti di scansione opportunistica o di una campagna mirata, non è stato dichiarato dal vendor né da CISA.
• Scala. Non c'è un conteggio pubblicato di istanze compromesse; il segnale sono le segnalazioni di web shell sul forum, non un dato di telemetria del vendor.
• Uso ransomware. CISA riporta knownRansomwareCampaignUse: Unknown.
• Un set di IOC pubblicato dal vendor. Gli indicatori qui sopra vengono dagli amministratori colpiti sul forum Nextcloud, non da un report formale del vendor o di un ricercatore. Sono plausibili e coerenti, ma vanno presi con cautela.

Aggiorneremo questo articolo man mano che le fonti primarie aggiungono dettagli.

La patch chiude la porta — il rilevamento ti dice se qualcuno è già entrato

La forma di questo incidente è quella che i difensori perdono più spesso: un servizio esposto è rimasto sfruttabile per settimane, l'attività non ha lasciato tracce evidenti nell'applicazione, e la prima prova reale è stata un file .php che qualcuno ha notato per caso. Quando arrivi a eseguire integrity:check-app, l'attaccante ha avuto da settembre per prepararsi. Aggiornare a 26.4.303 è necessario e urgente — ma la patch risponde a "possono ancora entrare", non a "sono già dentro".

Quella seconda domanda è una domanda di rete, ed è dove punta il nostro pilastro di AI Traffic Analysis. Una web shell deve parlare: la backdoor system($_GET[c]) serve a qualcosa solo quando l'operatore la richiama, cioè sessioni in uscita da un host che di norma si limita a servire documenti, callback verso destinazioni mai viste, beacon di comando e controllo che gli strumenti a firma lasciano passare. Zero Hunt fa girare un modello di deep learning proprietario con quattro teste di inferenza parallele — traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo — sulla GPU dell'apparato a 2,7+ Gbit/s, osservando esattamente questo mentre accade, non nel digest SIEM del mattino dopo. Su un apparato on-premise, senza che alcun dato del cliente esca, quello è il testimone che un web server compromesso non può zittire.

E una volta applicata la patch, il modo onesto di chiudere il ticket è dimostrarlo. Il red team autonomo di Zero Hunt può rieseguire la stessa prova che un'istanza esposta accetta l'injection — black-box, dal punto di vista dell'attaccante, con un umano che approva lo step di sfruttamento — e l'AI Remediation Advisor riverifica la correzione sulla tua build esatta invece di fidarsi del numero di versione. Se stai valutando la validazione continua rispetto agli strumenti di penetration testing automatico, questo bug a finestra di riavvio è un buon caso di prova: un pentest annuale avrebbe mancato del tutto la finestra, e così qualsiasi scanner che controlla solo un banner. Vedi anche la nostra analisi dell'RCE PHP trapelata in php2shell per lo stesso schema di web shell dopo la patch.