42 giorni dal primo exploit al KEV: dove si trovava il segnale

Il primo avviso pubblico non è comparso su X né in un feed basato sugli ID CVE. È comparso nel tracker delle issue su GitHub del progetto stesso. L'11 settembre 2026 un amministratore di Nextcloud ha pubblicato dei log di accesso che mostravano attacchi all'app integrata del document server Collabora (nome dell'app richdocumentscode). È successo 32,5 giorni prima che l'ID CVE diventasse pubblico e 42,2 giorni prima che la CISA aggiungesse la vulnerabilità al suo catalogo KEV (Known Exploited Vulnerabilities). Il 26 ottobre 2026, dalle 10:17 alle 10:56 ora di Singapore (SGT), abbiamo inviato 60 richieste a EveryInfra (52 addebitate, 0,029576 $ in totale). Abbiamo confrontato i risultati con la cronologia delle modifiche di NVD, la serie storica EPSS di FIRST e altre 24 voci recenti del KEV.

Il risultato è netto. Una ricerca su X per ID CVE ha restituito 106 post: zero prima della CVE e 80 dopo il KEV. Abbiamo etichettato ogni post una sola volta con una regola scritta in anticipo (senza un secondo valutatore), e il 93,4% era costituito da repost, bot o promozioni. Il campo SSVC leggibile dalle macchine nel record CVE ha indicato «non sfruttata» per 9 giorni. L'EPSS è rimasto all'1,2% per 10 giorni.

In questo articolo, un «processo verificabile dal segnale alla risposta» si compone di cinque passaggi quotidiani. Interroghi i tracker delle issue dei progetti, i forum dei vendor e alcune piattaforme social con i nomi dei tuoi componenti (non solo con gli ID CVE). Salvi ogni risposta grezza con il suo orario. Confronti i risultati con il tuo inventario degli asset ed elimini il rumore. Poi aggiorni, rimuovi o indaghi, e registri chi ha svolto ogni passaggio, quando e su quali evidenze. Il processo indica ai team operativi e di sicurezza quale elemento viene prima e perché, ma non prevede lo sfruttamento né sostituisce gli advisory dei vendor.

Cosa non trattiamo

Scriviamo solo di monitoraggio e risposta. Non descriviamo metodi di attacco, dettagli di sfruttamento o formati delle richieste. Quando citiamo una compromissione, diciamo solo dove ha scritto un amministratore, quando e cosa ha segnalato. Nascondiamo i nomi degli account personali e citiamo solo account istituzionali (per esempio CISA, CERT.LV, il CSIRT italiano e Censys) e i maintainer dei progetti. Non giudichiamo le decisioni di divulgazione di nessun vendor e ci limitiamo ad affiancare gli orari riportati nei registri pubblici.

Per chi lavora nelle agenzie federali statunitensi, un dettaglio conta più di tutti. In base alla BOD 26-04, la CISA fissa le scadenze per la correzione a partire da quattro elementi: lo stato KEV, lo sfruttamento automatizzabile, l'impatto tecnico e l'esposizione su internet. Per questa CVE, la voce del KEV ha concesso alle agenzie tre giorni e ha richiesto un triage forense, che è la scadenza più stretta prevista dalla direttiva. Quel conto alla rovescia parte dal KEV, ma gli attacchi erano iniziati 42 giorni prima. Questo articolo parla di quel divario e dei luoghi pubblici in cui era possibile vederlo.

I criteri che abbiamo scritto prima della prima richiesta

Alle 10:16 SGT del 26 ottobre, prima della prima richiesta, abbiamo scritto cinque criteri nel nostro file di verifica. Alle 10:29 SGT, prima di aprire i risultati dell'analisi trasversale, ne abbiamo aggiunti altri due. La tabella seguente mostra ogni criterio accanto al suo risultato, e le sezioni successive indicano la fonte di ogni numero.

Il criterio 2 richiede una nota. Su X, entrambi i metodi di ricerca (per ID CVE e per nome del prodotto più sintomo) non hanno restituito alcun post pertinente prima della CVE. Quindi X da solo non può mostrare la differenza. La differenza viene dal tracker delle issue del progetto e dal forum, luoghi pubblici che puoi monitorare per nome del componente. Per il criterio 6 indichiamo un «esito formalmente positivo» perché un anticipo di 1 giorno e uno di 30 giorni hanno un valore molto diverso. Una sezione successiva analizza quel dato nel dettaglio.

Il caso principale: dalla prima riga di log dell'attacco al KEV

La CVE è CVE-2026-110447. Secondo l'advisory di sicurezza di Collabora, riguarda solo un'app opzionale di Nextcloud, «Collabora Online - Built-in CODE Server». Questa app esegue una copia del document server all'interno del server Nextcloud. I server Collabora Online standalone non sono interessati, e l'avviso sul forum di Nextcloud aggiunge che sono sicuri anche i pacchetti Docker e delle distribuzioni Linux. La correzione è la versione 26.4.303, e l'advisory precisa che bisogna aggiornare o rimuovere l'app (disattivarla non basta). Il record NVD indica che la vulnerabilità è stata «exploited in the wild in September and October 2026».

Abbiamo raccolto ogni punto temporale che i registri pubblici riportano al secondo, usando API grezze e non riepiloghi. L'API delle issue di GitHub fornisce l'orario created_at dell'issue e di ogni commento. Il forum di Nextcloud gira su Discourse (documentazione API), quindi aggiungendo .json all'URL di un topic si ottiene l'orario di ogni post. Gli orari in cui l'ID è stato riservato e pubblicato provengono dall'API alla base del record CVE.org. L'orario di ogni modifica ai campi NVD proviene dall'API della cronologia delle modifiche delle CVE di NVD. L'orario del KEV è dateReleased nel JSON del KEV della CISA, e tutti gli orari nella tabella sono in UTC.

In questa tabella meritano un'occhiata più attenta due «70 minuti» e uno «0,7 secondi». La versione 26.4.303 è uscita alle 13:43 dell'11 settembre. Settanta minuti dopo, il primo amministratore colpito ha aperto un'issue dicendo che i sistemi erano compromessi dal giorno prima.

Pensiamo che in quel momento nessuna delle due parti sapesse dell'altra. Le note di rilascio non contenevano riferimenti alla sicurezza, e l'amministratore ha aggiornato solo dopo che qualcuno nell'issue gliel'ha chiesto. Il secondo intervallo di 70 minuti si è verificato il 14 ottobre. CVE.org ha pubblicato l'ID alle 02:27, e il primo post su X con l'ID è arrivato 69,8 minuti dopo.

Gli 0,7 secondi si trovano nell'API di CVE.org. Il valore dateReserved è 02:27:41.637 e il valore datePublished è 02:27:42.315. Quindi per 33 giorni la vulnerabilità non ha avuto nemmeno un ID riservato. Qualunque processo basato sugli ID CVE non aveva nulla da confrontare in quei 33 giorni. È questo il problema di fondo per ogni team il cui flusso di intake parte da un ID.

Abbiamo anche trovato un punto in cui una fonte secondaria non coincide con il record grezzo. L'advisory del 16 ottobre di Censys afferma che i log di chi ha fatto la segnalazione mostrano la prima richiesta malevola il 16 settembre. Ma il corpo dell'issue mostra righe di log del 10 settembre alle 19:51 e dell'11 settembre alle 09:56 (fuso orario +0200).

L'issue stessa è stata aperta l'11 settembre, quindi non può citare come prima richiesta una riga di log del 16 settembre. Usiamo il corpo dell'issue preso dall'API di GitHub, perché in una finestra di 33 giorni una data sbagliata in un riepilogo è un errore di 6 giorni. Riprendiamo dallo stesso advisory i dati sull'esposizione: 19.454 host e 103.350 proprietà web avevano l'app installata. Censys precisa che la vulnerabilità non è confermata per tutti e che entrambi i conteggi includono la build ARM64 della stessa app (1.001 host).

Perché per 33 giorni non c'è stata una CVE

Il KEV ha tre requisiti vincolanti, che la CISA elenca nella sua pagina dei criteri. La vulnerabilità deve avere un ID CVE. Devono esserci prove affidabili di sfruttamento attivo. Devono esserci indicazioni chiare per la correzione. Questa vulnerabilità soddisfaceva il secondo e il terzo requisito già l'11 settembre, perché l'issue conteneva le segnalazioni di tre amministratori e la correzione era disponibile. Il primo requisito l'ha bloccata, e così i 32,5 giorni senza ID hanno portato il totale a 42 giorni.

Il post sul blog del 14 ottobre di Collabora mette fianco a fianco due fatti. Quest'anno l'azienda ha ricevuto un numero molto elevato di segnalazioni di sicurezza prodotte con l'aiuto dell'AI. E il tempo per ottenere una CVE tramite GitHub è passato da circa un giorno a molte settimane. Il post non afferma che il primo fatto abbia causato il secondo. Dice che Collabora sta facendo domanda per diventare CVE Numbering Authority (CNA) per ridurre l'attesa.

Il record CVE.org mostra che MITRE è stato l'ente assegnante finale e che la riserva e la pubblicazione sono avvenute nello stesso secondo. Sembra più un intervento di MITRE come ente assegnante di ultima istanza che una normale coda. Non abbiamo trovato dichiarazioni su questo caso, quindi non ipotizziamo la causa.

Questo caso non è insolito. A ottobre la società di sicurezza Second Security ha pubblicato uno studio intitolato The Patchless Window. Lo studio ha ricondotto 18.594 CVE open source, da gennaio ad agosto 2026, al primo commit pubblico che correggeva ciascuna di esse. Il tempo mediano tra correzione pubblica e CVE pubblica era di 5,1 giorni a gennaio e di 39,2 giorni ad agosto. Il divario di Collabora è stato di 32,5 giorni, meno della mediana di agosto. Quindi per i componenti open source lo schema «prima la correzione, l'ID un mese dopo» sta diventando la norma.

Il report del 15 ottobre di BleepingComputer ha citato questo studio, e noi abbiamo verificato i numeri sul sito dello studio stesso. Anche The Hacker News ha riportato il caso. Per un team che si abbona a servizi di vulnerability intelligence basati sugli ID CVE, il significato è semplice. In media, il primo alert arriva ora più di un mese dopo che la correzione è diventata pubblica. Durante quel mese la correzione esiste, ma nessuno ti dice che è una correzione di sicurezza.

C'è un altro elemento di contesto. Dal 15 aprile 2026 il NIST non arricchisce più ogni CVE. Dà priorità alle voci del KEV, al software usato dal governo federale e al «critical software». Il NIST motiva la scelta con un aumento del 263% delle CVE inviate dal 2020 al 2025. Il 26 ottobre l'API di NVD mostrava ancora questo record come Deferred (solo il punteggio CVSS 4.0 dell'ente assegnante e l'SSVC della CISA). L'obiettivo del NIST è arricchire le voci del KEV entro un giorno lavorativo, mentre dall'inserimento nel KEV erano già passati più di due giorni.

Per te, questo significa che molti campi NVD possono essere vuoti prima del KEV e per un po' di tempo dopo. Se ti aspetti che un punteggio NVD porti una vulnerabilità in cima alla coda, quel piano può fallire proprio in questo periodo. Il testo della descrizione era presente dalla prima ora. I campi strutturati sono arrivati dopo, e i test seguenti misurano quanto dopo.

Test 1: cosa mostravano le piattaforme social prima della CVE

Se qualcuno avesse monitorato questo componente su X, lo avrebbe visto prima? Il 26 ottobre, dalle 10:24 alle 10:26 SGT, abbiamo eseguito tre ricerche con l'API di scraping per la ricerca su X (Twitter) (twitter/search). Ogni ricerca usava una finestra temporale dal 1° settembre al 14 ottobre. La prima ricerca usava il nome dell'app richdocumentscode. La seconda usava il nome del prodotto più parole che indicano un sintomo (nextcloud (hacked OR webshell OR compromised OR backdoor)). La terza usava solo nextcloud collabora.

I risultati concordavano. Le prime due ricerche hanno restituito 3 e 5 post, tutti del 14 ottobre o successivi, quindi zero prima della CVE. La terza ricerca ha restituito 16 post precedenti alla CVE, e nessuno parlava di una vulnerabilità o di un'intrusione. Riguardavano il personale federale svizzero e gli strumenti per l'ufficio open source, la sovranità digitale europea e l'hosting gestito di Nextcloud. Abbiamo anche notato che tutte e tre le richieste contenevano until:2026-10-14, ma le risposte includevano 3, 5 e 6 post del 14 ottobre o successivi. Il limite superiore dell'intervallo di date («before a specific date» nella guida alla ricerca avanzata di X) non era rigido, quindi abbiamo filtrato di nuovo in base al valore posted_at di ogni post.

Su Reddit, l'API di scraping per la ricerca su Reddit (reddit/search) copre sempre l'ultimo mese. La nostra ricerca del 26 ottobre copriva il periodo dal 26 settembre, che include i 18 giorni precedenti alla CVE. Alle 10:42 SGT, una ricerca di richdocumentscode ordinata dal più recente ha restituito 14 post. Tutti e 14 riguardavano questa vulnerabilità, ma nessuno era precedente alla CVE. Il primo era un repost di notizie di sicurezza delle 20:04 del 14 ottobre, 17,6 ore dopo la CVE.

Il post più utile su Reddit è arrivato il 22 ottobre. Un amministratore su r/NextCloud ha descritto come il suo server fosse stato compromesso tramite l'app Collabora integrata, e il post aveva 52 commenti. Tredici secondi dopo, lo stesso autore l'ha pubblicato anche su r/Malware. Per Hacker News abbiamo usato l'API di ricerca Algolia di HN, e richdocumentscode ha restituito zero risultati. Per nextcloud collabora dopo il 1° settembre, il primo elemento correlato è stato un link post del 15 ottobre (22:06 UTC, 2 punti, 0 commenti).

Abbiamo ordinato il primo elemento correlato di ogni piattaforma in base allo scarto dalla pubblicazione della CVE. L'issue su GitHub è arrivata 32,5 giorni prima e il forum di Nextcloud 10,7 giorni prima. X è arrivato 0,05 giorni dopo, Reddit 0,73 giorni dopo e Hacker News 1,8 giorni dopo. Su YouTube, l'API di scraping per la ricerca su YouTube (youtube/search, 10 risultati su 10 con l'ID) ha mostrato il primo elemento 2,5 giorni dopo, e su LinkedIn l'API di scraping per la ricerca su LinkedIn (linkedin/search, 8 su 10) 4,0 giorni dopo. L'API di scraping per la ricerca su Weibo (weibo/search) ha restituito 9 post su un'altra vulnerabilità (PHP2Shell) e 1 digest che citava Collabora in una riga. L'API di scraping per la ricerca su Threads (threads/search) ha restituito 25 post relativi soltanto alle ultime 19 ore, quindi non poteva mostrare un primo avvistamento.

Puoi seguire la logica di questa tabella passo dopo passo. Primo: ogni segnale pubblico precedente alla CVE si trovava in uno spazio del progetto, cioè il tracker delle issue e il forum degli utenti del vendor. Secondo: a scrivere lì erano amministratori colpiti e maintainer, e i loro post contenevano log e numeri di versione verificabili. Terzo: i primi post sui social sono arrivati dopo la CVE, da account di notizie di sicurezza che leggono i record CVE, non i tracker delle issue. Quindi il monitoraggio principale deve concentrarsi sulle issue e sui forum del progetto, usando il nome del componente. Le piattaforme social amplificano in un secondo momento e aggiungono le segnalazioni delle vittime, ma in questo caso non hanno funzionato da sistema di allerta precoce.

Questa conclusione ha un limite. Qui le vittime erano piccole organizzazioni con installazioni self-hosted, che chiedono aiuto nei tracker delle issue dei progetti. Se le vittime sono grandi aziende, è più probabile che il primo segnale compaia nel canale di supporto a pagamento di un vendor. I dati pubblici non possono vedere quel canale. Quindi lo schema vale soprattutto per i componenti open source che i piccoli team gestiscono in autonomia.

Test 2: dopo la CVE, il volume dei post segue il KEV

Alle 10:26 SGT abbiamo cercato una volta su X CVE-2026-110447 con limit 200, in ordine dal più recente. La risposta conteneva 106 post, quindi non ha raggiunto il limite. Abbiamo diviso i post in tre periodi. Prima della CVE c'erano 0 post, e nei 9,7 giorni tra la CVE e il KEV ce n'erano 26. Nei 2,3 giorni dopo il KEV ce n'erano 80, di cui 49 solo il 24 ottobre. I post delle prime 48 ore dopo il KEV erano il 71,7% del totale.

La forma di questo grafico mostra chiaramente una cosa: su X il KEV è l'amplificatore, non il segnale. La vulnerabilità è stata sfruttata a settembre, e la descrizione della CVE diceva «exploited in the wild» già il 14 ottobre. I grandi account di notizie di sicurezza ne hanno parlato quello stesso giorno. Ma la vera ondata di repost è arrivata solo dopo l'avviso KEV della CISA. Molti account di notizie di sicurezza e bot usano l'aggiornamento quotidiano del KEV come input, e molte aziende aprono ticket solo per le voci del KEV.

Per il monitoraggio, questo significa che in questo caso un alert del tipo «il volume dei post su X per un ID schizza in alto» sarebbe scattato dopo il KEV. Il volume dei post ti dice di cosa si parla adesso. Non ti dice chi è già stato attaccato. Se la tua pipeline usa il volume sui social come trigger, misura l'attenzione, e l'attenzione è arrivata per ultima.

Anche la distribuzione delle lingue è utile. Dei 106 post, 68 erano in inglese, 18 in giapponese, 5 in francese, 4 in spagnolo, 3 in coreano e 1 in cinese. Per un team statunitense conta soprattutto la quota giapponese, perché un post in giapponese è stato l'unica segnalazione di compromissione di prima mano su X prima del KEV. Un monitoraggio che conserva solo i post in inglese l'avrebbe perso. Se filtri per lingua, mantieni le lingue di tutti i paesi in cui i tuoi utenti usano il software.

Test 3: il 93,4% è rumore, ed ecco com'è fatto

Abbiamo suddiviso i 106 post in 6 classi con una regola scritta in anticipo. Per chiarezza sui limiti: i 106 post sono stati etichettati una sola volta, secondo la regola, e nessun secondo valutatore li ha verificati in modo indipendente. Quindi il 93,4% è il risultato di un unico passaggio di etichettatura basato su regole, e il suo margine di errore non è noto. Prima di usarlo in un report formale, chiedi a un'altra persona di etichettare di nuovo i 106 post con la stessa regola e riporta il grado di accordo tra i due passaggi. Un «segnale» aggiunge un fatto che non è presente nel record CVE né nell'advisory del vendor. Il «rumore» comprende tre classi: repost di un advisory o di una notizia; bot basati su template e digest quotidiani; promozioni o contenuti non pertinenti.

Il risultato: 80 repost, 12 bot e digest e 7 post promozionali o non pertinenti, per un totale di 99 post (93,4%). Quattro dei 7 post di segnale provenivano da istituzioni con dati propri: CERT.LV (Lettonia), CSIRT (Italia), Censys e CISA. Due riportavano fatti nuovi segnalati da persone che avevano verificato i record. Un post mostrava che il campo SSVC contraddiceva la descrizione, e un altro che NVD aveva un punteggio CVSS 4.0 ma nessun punteggio 3.x. L'ultimo era di un amministratore giapponese (23 ottobre, 08:29 UTC) sul cui server era stato installato software di mining attraverso questa vulnerabilità la settimana prima.

Solo 4 di questi 7 post sono arrivati prima del KEV. Quindi un team che avesse letto ogni post con l'ID prima del KEV avrebbe letto 26 post per trovarne 4 utili. Dopo il KEV il rapporto è peggiorato: 80 post e 3 utili. Il costo della lettura cresce con il KEV, il valore no.

Alcuni dei 7 post promozionali e non pertinenti sono tipi che rivedrai con altre vulnerabilità. Inseriscili nelle tue regole sul rumore. C'erano post che usavano il titolo della notizia per promuovere un token crypto e pubblicità di prodotti del tipo «collega un bot AI a un URL e ricevi alert». C'erano post di «bug bounty tips» che spiegano come trovare e testare sistemi non aggiornati: li abbiamo rimossi e non li riportiamo. Un commento generico del tipo «ogni settimana sembra che il cielo stia crollando» corrispondeva solo perché conteneva l'ID.

Il rumore non c'è solo su X. Nel thread di 7 post sul forum di Nextcloud, i post 3 e 6 venivano dallo stesso account appena creato. Entrambi rimandavano a una pagina esterna con un «autotest gratuito di 30 secondi». Il post 7 era una nota del community lead, che segnalava che i due link erano quasi identici e che il team tiene d'occhio lo spam. Su Weibo, 8 dei 10 risultati erano lo stesso testo su PHP2Shell pubblicato da 8 account nell'arco di 2 secondi, uno schema tipico delle farm di account. Su Threads, 6 dei 25 risultati per «Nextcloud Collabora» erano post in italiano che usavano il verbo «collabora» nel senso comune di «lavora insieme».

Test 4: i campi di rischio in formato leggibile automaticamente sono arrivati più tardi del testo

Molte pipeline di gestione delle vulnerabilità non leggono il testo della descrizione, ma i campi strutturati. Una fonte sono i tre punti decisionali SSVC che la CISA scrive nei record CVE tramite il suo progetto Vulnrichment: exploitation, automatable e technical impact. L'altra è il punteggio EPSS giornaliero di FIRST, che stima la probabilità di attività di sfruttamento osservata nei 30 giorni successivi. La direttiva BOD 26-04 usa lo stato KEV, automatable, technical impact e l'esposizione per fissare le scadenze federali, e tre di questi valori li fornisce la CISA tramite Vulnrichment.

Con l'API della cronologia delle modifiche di NVD abbiamo recuperato ogni modifica ai dati SSVC di questo record. Con l'API di EPSS abbiamo ottenuto la serie storica. La descrizione della CVE riportava «exploited in the wild» dalle 03:17 del 14 ottobre. I dati SSVC sono cambiati come mostra la tabella.

Quindi, per 9,7 giorni la descrizione diceva che la vulnerabilità era sfruttata, mentre i campi strutturati prima erano vuoti e poi, per 9 giorni, indicavano «non sfruttata». Sono passati a «sfruttata» solo 47 minuti dopo il KEV. EPSS è rimasto all'1,2% per quei 10 giorni (circa il 68° percentile in quel momento) e ha raggiunto il 12,3% solo il secondo giorno dopo il KEV. Una regola come «apri un ticket quando SSVC è active o EPSS supera il 10%» sarebbe scattata da 1 a 2 giorni dopo il KEV, cioè 11 giorni dopo il testo della descrizione.

Un utente di X ha notato questa discrepanza. Alle 21:03 UTC del 23 ottobre ha pubblicato un aggiornamento: il KEV aveva aggiunto la vulnerabilità circa 6 minuti dopo il suo primo post sulla discrepanza, e ora SSVC indicava active. Il post invitava chi aveva ancora il vecchio valore nella propria pipeline a scaricare di nuovo i dati, e ricordava la scadenza federale del 26 ottobre. Tra i 106 post, è stato uno dei pochi con un valore diretto per una pipeline.

Questo non significa che SSVC ed EPSS non servano. Le FAQ di EPSS precisano che EPSS non è un punteggio di rischio completo, e SSVC è il giudizio di un analista che richiede prove. La nostra osservazione è più circoscritta: finché le prove esistevano solo nell'issue tracker di un progetto, nessuno dei due campi le ha recepite. Usa i campi strutturati per stabilire le priorità, non come criterio di esclusione. Aggiungi una regola testuale separata per frasi come «exploited in the wild» nella descrizione.

Test 5: 24 voci KEV recenti e l'anticipo di X

Un solo caso non basta. Abbiamo preso tutte le 30 voci aggiunte al KEV dal 26 settembre al 23 ottobre. Sei avevano ID vecchi, dal 2015 al 2025 (per esempio ProFTPD e BIND del 2015). Per le altre 24 abbiamo cercato su X una volta per ID con twitter/search dalle 10:28 alle 10:41 SGT, con un limite di 200. Come orario KEV abbiamo usato la prima annotazione KEV nella cronologia delle modifiche di NVD. Quell'annotazione arriva da qualche minuto a qualche ora dopo la pubblicazione della CISA, quindi è un limite superiore che rende l'anticipo di X leggermente più grande del reale. Questo è diverso dal caso principale, che usa dateReleased nel JSON del KEV della CISA (19:30 del 23 ottobre). L'annotazione KEV di NVD per la stessa CVE è arrivata alle 20:17, 47 minuti dopo. Le versioni più vecchie del catalogo non indicano un orario di pubblicazione per singola voce, quindi l'analisi trasversale usa l'annotazione NVD per tutte e 24, e il caso principale vi compare con 9,7 giorni sullo stesso criterio.

Il risultato: 23 su 24 (95,8%) avevano almeno un post su X con l'ID prima del KEV, il che soddisfa formalmente il criterio 6. Ma l'anticipo mediano, calcolato sui valori non arrotondati, era di circa 1,16 giorni (il 12° e il 13° valore sono 1,12 e 1,19 giorni), e solo 13 su 24 avevano un anticipo superiore a 1 giorno. Soprattutto, per 17 CVE il primo post su X è arrivato entro 0,3 giorni dalla pubblicazione su NVD. Il motivo è l'intervallo tra NVD e KEV. Per 12 delle 24, il KEV è arrivato lo stesso giorno di NVD o il giorno dopo, soprattutto per zero-day confermati dal vendor (Citrix NetScaler, Fortinet, Ivanti). X sembra in anticipo solo quando quell'intervallo è lungo (Atlassian 10 giorni, Ahsay 10 giorni, il nostro caso principale 9,7 giorni), e quell'anticipo deriva quasi interamente dalla CVE stessa.

Ordinando l'intervallo tra NVD e KEV per giorni di calendario, il quadro è più chiaro. L'intervallo era di 0 giorni per 9 CVE, 1 giorno per 3 e 2 giorni per 2. Era di 5, 6 e 9 giorni per una CVE ciascuno, 10 giorni per 3 e 27 giorni per 4. La mediana era di 1,5 giorni.

Le voci KEV di questo mese si dividono quindi in due gruppi. Nel primo, il vendor conferma uno zero-day, e CVE e KEV arrivano quasi insieme. Nel secondo, la CVE era pubblica da tempo e le prove di sfruttamento sono arrivate dopo.

Nel primo gruppo, X ti aiuta a individuare più rapidamente un advisory urgente del vendor, con qualche ora di anticipo. Nel secondo gruppo, l'anticipo di X dipende dal fatto che qualcuno abbia notato la CVE dopo la pubblicazione. Il caso Plex mostra che può non parlarne nessuno per tre settimane. Inoltre, 6 CVE avevano post su X con l'ID prima che NVD le aggiungesse, di solito perché l'advisory del vendor aveva reso noto l'ID per primo. Quando costruisci una timeline, quindi, non considerare l'orario di ricezione su NVD come il momento in cui l'ID è diventato pubblico.

L'eccezione sono le 4 CVE di Plex Media Server. NVD le ha pubblicate il 23 settembre, ma il primo post su X con questi ID è arrivato il 18 ottobre: 24,9 giorni dopo e solo 2,2 giorni prima del KEV. La prossima sezione esamina questo caso. Valgono altre due note. Per CVE-2026-88771 e CVE-2026-102764 la ricerca ha restituito 200 post, raggiungendo il limite, quindi i nostri orari di primo avvistamento per queste CVE sono limiti inferiori. Inoltre la ricerca di X restituisce un campione ordinato per pertinenza, non tutti i post.

Il risultato su SSVC è più semplice. Nessuna delle 30 voci aveva exploitation: active prima del KEV, quindi in questo campione il valore «active» di SSVC rispecchia il KEV. Per le 12 CVE con dati EPSS del giorno prima del KEV, tutti e 12 i punteggi erano sotto il 10%. In questo campione nessuno dei due campi ha fornito un segnale prima dell'inserimento nel catalogo.

Tre casi di confronto: NetScaler, Plex2Shell, PHP2Shell

Per capire se esiste uno schema ricorrente, abbiamo confrontato tre eventi dello stesso periodo. Per ciascuno abbiamo cercato su X una volta e abbiamo messo in fila gli orari delle fonti primarie, con la pubblicazione della CVE come giorno 0.

NetScaler: X è arrivato prima, ma i primi contenuti erano voci non verificate. Alle 10:54 SGT abbiamo cercato NetScaler dal 26 al 28 settembre e ottenuto 176 post. Il primo era delle 15:07 UTC del 26 settembre. Un account molto seguito scriveva che uno zero-day sconosciuto di NetScaler, sfruttato attivamente, aveva costretto alcune istituzioni a spegnere i dispositivi. NVD ha ricevuto CVE-2026-88771 alle 17:16 del 27 settembre, e a quel punto su X c'erano già 77 post.

Diversi dei primi post dicevano che la voce era nata nelle discussioni tra amministratori di sistema su Reddit. La CISA ha aggiunto la vulnerabilità verso le 20:16 di quel giorno.

In un avviso separato, la CISA ha chiesto alle organizzazioni di verificare eventuali compromissioni prima di applicare la patch. Citrix ha pubblicato il suo bollettino di sicurezza lo stesso giorno. È lo schema tipico di un grande vendor, uno zero-day e un dispositivo perimetrale. Le vittime sono grandi organizzazioni e la notizia circola prima tra gli addetti ai lavori come «c'è qualcosa che non va». Poi il vendor, la CVE e il KEV arrivano nell'arco di un giorno. X è arrivato con 26 ore di anticipo, ma quei contenuti erano voci non verificate: sufficienti per avviare un playbook «controlla i log», non per trarre conclusioni.

Plex2Shell: il produttore l'aveva segnalato per tempo, ma nessuno se n'è accorto. Plex ha pubblicato un avviso sul forum alle 18:30 UTC del 1° settembre. Vi si leggeva che la versione 1.43.3 correggeva diversi problemi di sicurezza e che erano state richieste le CVE. Oggi l'avviso conta 86.684 visualizzazioni. Eppure una ricerca su X per plex "security update" dal 1° al 22 settembre ha restituito appena 1 post.

Le CVE (come CVE-2026-96652) sono uscite il 23 settembre. L'avviso dell'ACN (l'Agenzia per la Cybersicurezza Nazionale) mostra punteggi modesti per ciascuna CVE, come 4,3 e 6,5 (CVSS 3.1). Per questo pochi ci hanno fatto caso.

La svolta è arrivata il 16 ottobre, quando un ricercatore ha pubblicato un'analisi completa di come le 4 vulnerabilità si concatenano. Il 17 ottobre l'honeypot di un altro ricercatore ha registrato attività di sfruttamento (il suo blog). Il primo post su X con «Plex2Shell» è arrivato alle 15:59 del 18 ottobre, e la CISA ha aggiunto le CVE il 20 ottobre. Lo schema: il rischio combinato di vulnerabilità con punteggio basso è emerso solo dopo un'analisi pubblica, e il primo segnale pubblico era l'avviso dello stesso vendor. Il tuo monitoraggio deve intercettare frasi come «important security update, details to follow». La segnalazione di una vittima su Reddit (r/unRAID, 109 commenti) è apparsa il 21 ottobre, dopo il KEV.

PHP2Shell: quella che ha ricevuto più attenzione su X, ma non è ancora nel KEV. Il 20 ottobre il team di PHP ha annunciato le correzioni per due vulnerabilità critiche. Il primo post su X con CVE-2026-109618 è arrivato alle 18:56 UTC del 20 ottobre, circa 19 ore prima della correzione e della CVE (13:48 UTC del 21 ottobre, secondo CVE.org). La nostra unica ricerca contava già 68 post prima della fine dell'embargo, alle 14:00 del 21 ottobre. La threat intelligence di AWS ha scritto in un post sul blog che la sua rete di honeypot aveva rilevato tentativi di sfruttamento il 17 ottobre, 4 giorni prima della divulgazione. L'agenzia UE CERT-EU ha registrato l'evento nel suo bollettino.

Ma quando abbiamo letto il catalogo KEV il 26 ottobre, era ancora alla versione 2026.10.23 e non includeva questi ID. La nostra ricerca alle 10:52 SGT ha restituito tutti i 200 post per il periodo dal 20 al 23 ottobre, e anche qui il limite superiore di data non è stato rispettato rigorosamente. Questo caso mostra che l'attenzione sui social e l'inserimento nel KEV non sono collegati. Il KEV richiede prove affidabili di sfruttamento in the wild, e i tentativi contro gli honeypot possono non bastare. Per una vulnerabilità come PHP2Shell non aspettare il KEV: pianifica la correzione in base alla tua esposizione.

Mettendo a confronto i quattro casi, la conclusione non è che «i social non servono». Il primo segnale pubblico compare dove parlano le prime vittime. Le piccole organizzazioni self-hosted si rivolgono agli issue tracker dei progetti e ai forum degli utenti. Gli addetti ai lavori delle grandi organizzazioni si confrontano sui social. I vendor lanciano avvisi discreti nei forum e nelle release note, e i ricercatori pubblicano su blog e repository. Un monitoraggio per ID CVE copre solo ciò che arriva dopo tutto questo.

Dal segnale all'intervento: un processo da eseguire una volta al giorno

La tappa 1 consiste nel monitorare le fonti. La tua lista non è un elenco di ID CVE, ma dei nomi dei componenti che usi, come richdocumentscode, Plex Media Server o NetScaler. Ogni componente ha tre tipi di fonti. La prima è l'issue tracker del progetto con le release (GitHub offre un'API gratuita per nuove issue e release). La seconda è il forum del vendor o la sua pagina degli avvisi di sicurezza (molti forum girano su Discourse, che restituisce JSON), e la terza è la ricerca per parole chiave su alcuni social. Il JSON del KEV e la descrizione della CVE servono per la conferma e per le scadenze, non come punto di partenza.

In questo caso, chi avesse letto ogni giorno l'issue tracker di richdocumentscode avrebbe visto «Hack» nel titolo di una issue l'11 settembre, un mese prima di qualsiasi monitoraggio per ID. Il costo di questa lettura è una chiamata API gratuita per componente al giorno. Il valore sta nei 32,5 giorni di anticipo.

La tappa 2 consiste nel conservare le prove. Salva ogni risposta grezza senza modifiche, con i parametri della richiesta, l'orario UTC e un hash del file. I motivi sono due. Primo, in seguito devi poter rispondere alla domanda «quando lo sapevamo?», sia nel triage forense richiesto dalla BOD 26-04 sia nei report sugli incidenti. Secondo, i contenuti delle piattaforme cambiano: i post vengono cancellati, i commenti modificati e i riassunti contengono errori. Abbiamo scoperto l'incongruenza nella data di Censys solo perché siamo tornati al testo salvato della issue.

La tappa 3 consiste nell'abbinare gli asset. Confronta il tuo inventario per nome del componente, non per ID CVE, perché ad agosto la mediana della Patchless Window era di 39,2 giorni senza ID. L'abbinamento deve includere il tipo di deployment. Questa vulnerabilità riguarda solo l'app CODE integrata, mentre Collabora standalone è sicuro. Un abbinamento basato su «usiamo Collabora?» genera molti falsi allarmi. Peggio ancora, tra questi può nascondere l'unico server davvero colpito.

La tappa 4 consiste nel rimuovere il rumore. Etichetta ogni elemento con le 6 classi del Test 3. Repost, bot, promozioni e post con suggerimenti d'attacco restano fuori dalla coda degli interventi, ma rimangono nell'archivio per verifiche successive. In questo test è stato rimosso il 93,4% di una ricerca su X per ID e il 100% dei risultati per nome di prodotto precedenti alla CVE. Le tue regole devono coprire anche le collisioni di parole tra lingue (l'italiano «collabora»), le farm di account (8 account, 2 secondi) e i link di «autotest gratuito» nei forum.

La tappa 5 consiste nell'intervenire. Il bollettino di Collabora indica di aggiornare alla 26.4.303 o di rimuovere l'app, perché disattivarla non basta. Se usi Nextcloud 29 o precedente, ormai a fine vita, aggiorna Nextcloud o rimuovi l'app.

Il post 4 del forum di Nextcloud suggeriva una verifica pratica: dopo l'aggiornamento, il controllo di integrità di Nextcloud segnalava un «file extra» nella cartella dell'app. Il CSIRT Italia ha citato l'installazione di web shell e il furto di credenziali. Per qualsiasi istanza esposta dopo il 10 settembre suggeriamo quindi tre azioni in più: esegui il controllo di integrità, esamina i log di accesso e cambia le password leggibili dal server web.

Descriviamo solo queste azioni difensive, non l'aspetto delle richieste di attacco. Il controllo di integrità è importante perché una patch non rimuove i file che un attaccante ha già inserito. Anche un server aggiornato può avere ancora una backdoor. Per questo la voce KEV chiede un triage forense oltre alla correzione.

La tappa 6 consiste nel chiudere il caso. Ogni caso deve rispondere a quattro domande: chi l'ha gestito, quando, sulla base di quali prove (un riferimento alla risposta grezza in archivio) e cosa ha fatto. Dopo che il KEV ha aggiunto la vulnerabilità, confronta la sua scadenza con il tuo orario di chiusura. La tabella qui sotto mostra i campi minimi del record che suggeriamo, e li abbiamo usati tutti in questo test.

Il costo: 50 componenti per un mese

Alle 10:13 SGT del 26 ottobre abbiamo letto il catalogo delle funzionalità; il riferimento è la pagina dei prezzi. twitter/search, reddit/search, youtube/search, linkedin/search e threads/search costano ciascuno 0,000556 $ per richiesta. weibo/search costa 0,000806 $ per richiesta. Si paga per richiesta, non per risultato. Abbiamo anche eseguito 3 ricerche EveryInfra con profondità quick (0,000694 $ ciascuna) su web e forum per trovare post precedenti alla CVE; tutte e 3 hanno restituito 0 risultati.

Prendiamo un piccolo team con 50 componenti esposti su internet, con una ricerca su X e una su Reddit per componente al giorno. Sono 100 richieste × 0,000556 $ = 0,0556 $ al giorno, ovvero 1,668 $ in 30 giorni. L'API delle issue di GitHub, i forum Discourse, NVD, CVE.org, KEV ed EPSS sono API pubbliche gratuite, quindi non rientrano in questo costo.

I risultati vuoti e le richieste non riuscite non vengono addebitati. Delle nostre 60 richieste, 6 hanno raggiunto il limite di frequenza delle richieste (status 429), 1 aveva un parametro errato (status 422) e 1 è tornata vuota. Nessuna di queste 8 è stata addebitata. Ci sono state addebitate 52 richieste (0,029576 $), e l'immagine di copertina e un'illustrazione sono costate altri 0,06 $.

Conviene eseguire il ciclo ogni ora? Con gli stessi 50 componenti, un ciclo orario significa 2.400 richieste al giorno, ovvero 1,3344 $ al giorno e circa 40,03 $ al mese. È 24 volte il costo giornaliero e consente di rilevare un segnale con meno di un giorno di anticipo. In questo caso il primo segnale è arrivato 32,5 giorni prima della CVE, quindi a quella scala la differenza tra frequenza giornaliera e oraria non conta. Un monitoraggio orario ha senso per gli zero-day sui dispositivi perimetrali come NetScaler, dove CVE e KEV arrivano nell'arco di un giorno. Quella lista di solito è corta: tienila separata e mantieni la lista completa su base giornaliera.

Ottieni gli stessi dati con il codice o con un client AI

Una richiesta curl che cerca su X per ID (la chiave è un segnaposto):

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer <API Key>" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"CVE-2026-110447","sort":"latest","limit":200}}'

Abbiamo verificato ogni campo della risposta usato in questo articolo rispetto ai response_fields di twitter/search nel catalogo.

Per Reddit, usa reddit/search con i parametri keyword e sort (newest, relevance e altri). I campi che userai di più sono community, comment_count e posted_at. L'intervallo di tempo è sempre l'ultimo mese. Se ti servono più di 30 giorni di storico, archivia i risultati man mano.

Per eseguire le stesse ricerche da Claude Code, ottieni una chiave dalla guida rapida e aggiungi il server MCP remoto:

claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --header 'Authorization: Bearer ${EVERYINFRA_API_KEY}'

A quel punto basta un'istruzione: «Usa everyinfra_call_api per cercare su X richdocumentscode e CVE-2026-110447, e separa i post tra quelli precedenti e quelli successivi al 2026-10-14 02:27 UTC». Poi puoi chiedere di elencare gli account istituzionali separati da quelli personali. La risposta usa gli stessi campi posted_at e author_username della tabella sopra.

Ecco gli errori e gli esiti di addebito che abbiamo osservato in questo test. Quando abbiamo impostato il sort di Reddit su oldest, valore che non esiste, la risposta è stata 422 invalid_value. L'errore elencava tutti i valori ammessi e riportava «Nothing was charged». Quando altre richieste sulla stessa chiave di test hanno esaurito il limite di 10 al minuto, la risposta è stata 429 rate_limited con un valore retry_after. Anche questa non è stata addebitata, e tutti i nuovi tentativi dopo retry_after più 10 secondi sono andati a buon fine.

Un risultato vuoto sincrono restituisce 200 con count 0 e billing.reason impostato su empty_result_refunded, e non viene addebitato. Per la riconciliazione riga per riga, consulta rimborsi per le richieste non riuscite e riconciliazione. Quando una ricerca su X restituisce il numero massimo di risultati, i post più vecchi potrebbero essere tagliati e la risposta non segnala alcun errore. Confronta tu stesso count con il limite.

Novità degli ultimi 60 giorni e ricerche correlate

23 ottobre 2026: la CISA ha aggiunto CVE-2026-110447 con una scadenza di tre giorni e triage forense. Vedi l'avviso della CISA. Per te, il campo forensicTriage: Yes in una voce KEV merita una regola a sé. Significa «dopo la patch, verifica se sei stato compromesso».

21 ottobre 2026: PHP2Shell è stata resa pubblica e AWS ha dichiarato che lo sfruttamento era iniziato 4 giorni prima. Vedi i casi di confronto sopra. Per te, quando indaghi, conta a ritroso dal primo sfruttamento noto. Non contare in avanti dalla data del bollettino.

20 ottobre 2026: la CISA ha aggiunto sei vulnerabilità in un'unica volta, e quattro erano Plex2Shell. Per te, le vulnerabilità con punteggio basso possono finire nel KEV quando si concatenano. Un filtro sui singoli punteggi CVSS non le intercetta.

14 ottobre 2026: Collabora ha attribuito il ritardo alla coda delle richieste di CVE e ha chiesto di diventare CNA. Per te, gli ID arriveranno più in fretta quando i progetti open source diventeranno CNA. Fino ad allora, un monitoraggio per ID può arrivare con un mese di ritardo.

Ottobre 2026: Second Security ha pubblicato lo studio Patchless Window. Ad agosto, il tempo mediano tra una correzione pubblica e una CVE pubblica era di 39,2 giorni. Per te, conviene monitorare i componenti open source tramite commit, release e issue, senza aspettare l'ID.

25 settembre 2026: un paper su arXiv ha proposto GPM, una metrica di priorità basata su stelle, fork e utenti dei repository di exploit su GitHub (arXiv 2609.31004). Secondo il paper, GPM è stata integrata nella versione 5 di EPSS. Per te, l'attività nei repository pubblici fa ora parte del punteggio formale. Ma il nostro segnale era la segnalazione di una vittima in un issue tracker, non codice di exploit, quindi questa metrica non lo copre.

19 agosto 2026: uno studio ha confrontato un knowledge graph sulle minacce già in produzione con 10.000 post social legati alle minacce (rivista Information). Il grafo conteneva già il 96% delle vulnerabilità su cui intervenire citate nei post e le segnalava almeno con la stessa rapidità. I social media erano in vantaggio solo nell'allerta precoce sullo sfruttamento attivo. Per te, lo studio concorda con il nostro risultato: il valore dei dati social sta in poche segnalazioni di vittime e in alcune voci, non nella copertura delle CVE.

Agosto 2026: lo studio STINER ha usato gli alert su X per un quadro delle minacce in Europa (arXiv 2608.14418). Ha rilevato che gli attacchi in paesi diversi hanno una visibilità molto diversa su X. Per i lettori, lingua e area geografica sono variabili da considerare sempre nel monitoraggio dei social: in questo caso, un post in giapponese è stato l'unica segnalazione diretta su X prima del KEV. Come contesto metodologico, un paper di USENIX Security del 2015 aveva già provato a usare i post di Twitter per prevedere exploit reali.

Limiti di questo articolo

Primo, c'è un solo caso principale e abbiamo eseguito una sola ricerca per ciascun caso di confronto. Non abbiamo un gruppo di controllo di vulnerabilità non sfruttate, quindi non possiamo calcolare un tasso di falsi allarmi. Non possiamo nemmeno affermare che ogni issue del tipo «ci hanno hackerato» indichi una vulnerabilità reale. Qui il segnale della issue era credibile perché conteneva log, più persone avevano visto la stessa cosa e un maintainer aveva risposto entro 3 giorni. Altre issue potrebbero non avere tutte e tre queste caratteristiche.

Secondo, la ricerca su X restituisce un campione ordinato per pertinenza. La nostra ricerca per ID ha restituito 106 post senza raggiungere il limite, ma non possiamo dimostrare che su X non esistano post precedenti. Il limite di data until non è stato rispettato rigorosamente in nessuna delle nostre 4 richieste che lo usavano, quindi abbiamo filtrato su posted_at. La ricerca su Reddit copre solo l'ultimo mese, quindi non abbiamo potuto verificare Reddit per il periodo dal 10 al 25 settembre. Una ricerca web generica su reddit.com prima del 14 ottobre ha restituito solo vecchie domande di configurazione, senza segnalazioni di compromissioni.

Terzo, il rumore è stato etichettato una sola volta con una regola scritta in anticipo, senza un secondo etichettatore. Il confine tra «segnale» e «repost» richiede un certo margine di giudizio. Per esempio, abbiamo contato come repost un post che riscriveva il bollettino sotto forma di checklist, mentre un'altra persona potrebbe considerarlo un segnale.

Quarto, le osservazioni su SSVC ed EPSS valgono per una sola situazione: la descrizione dice già che la vulnerabilità è sfruttata. Non estenderle a «questi campi sono sempre lenti». EPSS stima una probabilità, e il suo scopo non è ripetere il KEV.

FAQ

Cosa significa quando la CISA aggiunge una vulnerabilità al KEV?

Significa che la CISA dispone di un ID CVE, di prove affidabili di sfruttamento in the wild e di indicazioni chiare per la correzione. In base alla BOD 26-04, le agenzie federali devono correggerla entro la scadenza indicata nella voce; in questo caso, il termine era di tre giorni ed era richiesto anche il triage forense. Il KEV arriva sempre dopo la CVE. Qui è arrivato 9,7 giorni dopo la CVE e 42,2 giorni dopo la prima segnalazione pubblica. (Dal suggerimento di ricerca «cisa kev meaning».)

EPSS o CISA KEV: quale usare per stabilire le priorità?

Rispondono a domande diverse. Il KEV dice che lo sfruttamento è stato confermato, mentre EPSS stima la probabilità di uno sfruttamento osservato nei 30 giorni successivi. In questo caso, EPSS è rimasto all'1,2% nei 10 giorni prima del KEV. Per le 12 CVE del KEV con dati nel nostro campione, tutti i punteggi EPSS del giorno prima del KEV erano sotto il 10%. Usali entrambi per ordinare le priorità e aggiungi una regola testuale per «exploited in the wild». (Dal suggerimento di ricerca «epss vs cisa kev».)

Come si corregge la vulnerabilità di Collabora in Nextcloud?

Aggiorna l'app «Collabora Online - Built-in CODE Server» alla 26.4.303 oppure rimuovila, perché disattivarla non basta. Se usi Nextcloud 29 o precedente, aggiorna Nextcloud o rimuovi l'app. I server Collabora standalone non sono interessati. Se la tua istanza era esposta, esegui anche il controllo di integrità, esamina i log e cambia le credenziali. (Dal suggerimento di ricerca «nextcloud collabora vulnerability fix».)

Letture correlate

• Pagine delle piattaforme: API di scraping per X (Twitter), API di scraping per Reddit, API di scraping per Weibo
• Pagine delle funzionalità: Ricerca su X, Ricerca su Reddit, Ricerca su YouTube, Ricerca su LinkedIn, Ricerca su Threads, Ricerca su Weibo
• Della stessa serie: L'intelligence sulle vulnerabilità come prodotto, Segnali social del pump-and-dump, I dati social come campione di ricerca

Riferimenti

1. CollaboraOnline/richdocumentscode, issue GitHub #354 «Security issue - Hack», 11 settembre 2026, https://github.com/CollaboraOnline/richdocumentscode/issues/354
2. CollaboraOnline/richdocumentscode, release 26.4.303, 11 settembre 2026, https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303
3. GitHub, endpoint dell'API REST per le issue, consultati il 26 ottobre 2026, https://docs.github.com/en/rest/issues/issues
4. Forum della community di Nextcloud, «To Collabora Built-in User: Update ASAP», 3 ottobre 2026, https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516
5. Discourse, documentazione API, consultata il 26 ottobre 2026, https://docs.discourse.org/
6. CVE Program, record CVE-2026-110447, 14 ottobre 2026, https://www.cve.org/CVERecord?id=CVE-2026-110447
7. CVE Services API, metadati del record CVE-2026-110447, consultati il 26 ottobre 2026, https://cveawg.mitre.org/api/cve/CVE-2026-110447
8. NIST NVD, dettaglio di CVE-2026-110447, pubblicato il 14 ottobre 2026, modificato il 24 ottobre 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-110447
9. NIST NVD, CVE Change History API, consultata il 26 ottobre 2026, https://nvd.nist.gov/developers/vulnerability-change-history
10. Collabora Online, bollettino di sicurezza GHSA-g3vx-3m76-fghh, 14 ottobre 2026, https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
11. Collabora Online, «Stay Safe: Upgrade Everything Regularly», 14 ottobre 2026, https://www.collaboraonline.com/blog/stay-safe-upgrade-everything-regularly/
12. Censys, «Oct 16 Advisory: Collabora Online Built-in CODE Server OS Command Injection», 16 ottobre 2026, https://censys.com/advisory/cve-2026-110447/
13. CISA, Known Exploited Vulnerabilities Catalog, consultato il 26 ottobre 2026, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
14. CISA, feed JSON del KEV (versione 2026.10.23), consultato il 26 ottobre 2026, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
15. CISA, «Reducing the Significant Risk of Known Exploited Vulnerabilities» (criteri KEV), consultato il 26 ottobre 2026, https://www.cisa.gov/known-exploited-vulnerabilities
16. Second Security, «The Patchless Window», ottobre 2026, https://thepatchlesswindow.com/
17. BleepingComputer, «Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers», 15 ottobre 2026, https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/
18. NIST, «NIST Updates NVD Operations to Address Record CVE Growth», 15 aprile 2026, https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
19. Hacker News, API di ricerca Algolia, consultata il 26 ottobre 2026, https://hn.algolia.com/api
20. Hacker News, post con link «Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers», 15 ottobre 2026, https://news.ycombinator.com/item?id=50111052
21. Reddit r/NextCloud, segnalazione di un amministratore «Nextcloud compromised via the built-in Collabora app», 22 ottobre 2026, https://www.reddit.com/r/NextCloud/comments/1xcsjlx/nextcloud_compromised_via_the_builtin_collabora/
22. cisagov, repository Vulnrichment, consultato il 26 ottobre 2026, https://github.com/cisagov/vulnrichment
23. FIRST, EPSS Frequently Asked Questions, consultato il 26 ottobre 2026, https://www.first.org/epss/faq
24. CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, 10 giugno 2026, https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
25. FIRST, EPSS «Get the Data» (inclusa l'API), consultato il 26 ottobre 2026, https://www.first.org/epss/data
26. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC), consultato il 26 ottobre 2026, https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
27. CISA, «Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway», 27 settembre 2026 (aggiornato il 9 ottobre), https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway
28. Citrix, bollettino di sicurezza CTX697096, 27 settembre 2026, https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096
29. NIST NVD, dettaglio di CVE-2026-88771, 27 settembre 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-88771
30. Forum di Plex, «Important Security Update for Plex Media Server v1.43.2 and earlier», 1° settembre 2026, https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
31. Agenzia per la Cybersicurezza Nazionale (ACN), «Plex Media Server: rilevato sfruttamento in rete delle catena di attacco Plex2Shell», ottobre 2026, https://www.acn.gov.it/portale/w/plex-media-server-rilevato-sfruttamento-in-rete-delle-catena-di-attacco-plex2shell
32. boredhackerblog, «Plex vulnerabilities being exploited in the wild to drop a cryptominer», 17 ottobre 2026, https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
33. CISA, «CISA Adds Six Known Exploited Vulnerabilities to Catalog», 20 ottobre 2026, https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog
34. NIST NVD, dettaglio di CVE-2026-96652, 23 settembre 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-96652
35. AWS Security Blog, «Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot», 21 ottobre 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
36. CERT-EU, Security Advisory 2026-018 «Critical Vulnerabilities in PHP», 20 ottobre 2026, https://cert.europa.eu/publications/security-advisories/2026-018
37. NIST NVD, dettaglio di CVE-2026-109618, 21 ottobre 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-109618
38. CISA, «CISA Adds One Known Exploited Vulnerability to Catalog» (CVE-2026-110447), 23 ottobre 2026, https://www.cisa.gov/news-events/alerts/2026/10/23/cisa-adds-one-known-exploited-vulnerability-catalog-0
39. Akhoundali et al., «GitHub Engagement Signals for CVE Prioritization: The GitHub Popularity Metric (GPM)», arXiv 2609.31004, 25 settembre 2026, https://arxiv.org/abs/2609.31004
40. «Time-Series and Social-Media Threat Analytics over a Deployed Cyber-Threat Knowledge Graph», Information 17(8):794, 19 agosto 2026, https://www.mdpi.com/2078-2489/17/8/794
41. Ech-Chammakhy et al., «STINER: Automated Extraction of Strategic Cyber Threat Intelligence from X», arXiv 2608.14418, 14 agosto 2026, https://arxiv.org/abs/2608.14418
42. Sabottke, Suciu, Dumitraș, «Vulnerability Disclosure in the Age of Social Media: Exploiting Twitter for Predicting Real-World Exploits», USENIX Security 2015, https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sabottke
43. X Help Center, «How to use advanced search», consultato il 26 ottobre 2026, https://help.x.com/en/using-x/x-advanced-search
44. NIST NVD, documentazione dell'API CVE, consultata il 26 ottobre 2026, https://nvd.nist.gov/developers/vulnerabilities
45. The Hacker News, «Hackers Backdoor Nextcloud Servers Through Critical Flaw in Collabora’s Built-in CODE App», ottobre 2026, https://thehackernews.com/2026/10/hackers-backdoor-nextcloud-servers.html