A metà ottobre 2026 sono state pubblicate, nel giro di pochi giorni, diverse vulnerabilità critiche in componenti che fanno funzionare gran parte del web: Node.js, PHP, NGINX e il kernel Linux. Alcune consentono di eseguire codice su un server senza alcuna autenticazione. Per un'applicazione in produzione tutto dipende allora dal tempo necessario per applicare la correzione ovunque.
Una settimana di allerte, ottobre 2026
- 14 ott.NGINXCorruzione di memoriaCinque vulnerabilità corrette, una delle quali nel supporto di HTTP/3.
- 20 ott.HTTP/3Denial of serviceUna sola connessione può esaurire la memoria di un server: 7 implementazioni su 10 testate erano vulnerabili.
- 21 ott.Node.jsEsecuzione di codiceDieci vulnerabilità corrette, tra cui un'esecuzione di codice da remoto. Node.js 20 non riceve più correzioni.
- 21 ott.PHP «PHP2Shell»Esecuzione di codiceEsecuzione di codice senza autenticazione, dimostrata su WordPress, Drupal e Magento. PHP fa funzionare il 69% dei siti web con linguaggio lato server noto.
- 21 ott.Linux KSMBDEsecuzione di codiceDue vulnerabilità valutate 9,0 su 10, pubblicate prima di qualsiasi correzione.
- 21 ott.LiteLLMFurto di chiaviUna versione manomessa di questa libreria di IA è stata pubblicata per rubare chiavi API.
La finestra tra patch e attacco si è chiusa
Qualche anno fa gli attaccanti impiegavano settimane per sfruttare una falla nota. Oggi bastano pochi giorni, e a volte lo sfruttamento inizia prima che esista una correzione.
Tempo medio di sfruttamento di una vulnerabilità rispetto alla sua patch
63 giorni dopo la patch nel 2018–2019, cinque giorni nel 2023. Nel 2025 lo sfruttamento precede in media la patch di circa una settimana, secondo una stima.
| Periodo | Tempo medio |
|---|---|
| 2018–2019 | 63 giorni |
| 2020 – inizio 2021 | 44 giorni |
| 2021–2022 | 32 giorni |
| 2023 | 5 giorni |
| 2025 (stima) | 7 giorni prima |
Nel terzo trimestre 2026 Rapid7 ha misurato in media tre giorni tra la pubblicazione di una vulnerabilità grave e il suo sfruttamento. Un ciclo di aggiornamento mensile lascia quindi diverse settimane di esposizione.
L'IA accelera la scoperta delle vulnerabilità
Modelli capaci di leggere il codice trovano ormai vulnerabilità su larga scala. Anthropic ha segnalato oltre 6’000 vulnerabilità in progetti open source, secondo il suo 
CVD dashboard, e la falla di Node.js corretta il 21 ottobre è stata trovata dal team Codex Security di OpenAI. Gli attaccanti usano gli stessi strumenti.
L'effetto dell'IA sulle vulnerabilità nel 2026
Vulnerabilità pubblicate al mese
gennaio 20265’045agosto 202610’740Vulnerabilità sfruttate al mese
media 202510,5gennaio–agosto 202618Quota di falle che consentono l'esecuzione di codice da remoto
Trovate con l'IA50%Altre falle26%Le falle diventano anche pubbliche prima: la documentazione del kernel Linux 
Security bugs chiede ormai di trattare come pubblica ogni falla trovata con l'IA, perché spesso più ricercatori la scoprono lo stesso giorno. Solo una piccola parte delle falle pubblicate viene davvero sfruttata; conta quindi riconoscere in fretta quella importante.
Le applicazioni che integrano l'IA aggiungono rischi propri, come la prompt injection 
LLM01 Prompt Injection o una catena di fornitura compromessa LLM03 Supply Chain. Richiedono la stessa manutenzione del resto dell'applicazione.
Correggere in fretta, e ovunque
Una correzione è un solo aggiornamento. Il lavoro consiste nell'assicurarsi che raggiunga ogni luogo in cui il software è in esecuzione, senza rompere nulla.
Le buone pratiche davanti a una vulnerabilità critica
- 1.Fare l'inventarioTutto ciò che è in esecuzione, compreso ciò che l'interfaccia di amministrazione non mostra: servizi avviati al di fuori di essa, servizi fermi, software installato direttamente sul server.
- 2.Stabilire le prioritàPrima ciò che è esposto a Internet e ciò che una falla permette di raggiungere senza autenticazione.
- 3.Correggere a parteUna correzione preparata a partire dalla versione in produzione, senza i lavori in corso. La stessa modifica confluisce poi nella versione in sviluppo.
- 4.Includere anche le copieAmbienti di test e di staging, backup, copie di riserva. Un servizio fermo viene corretto prima di essere riavviato.
- 5.Verificare ciò che gira davveroLa versione realmente eseguita, non quella dichiarata nella configurazione, poi lo stato del servizio dopo ogni modifica.
- 6.Tenere tracciaOgni azione e il suo risultato vengono annotati, per poter riprendere, spiegare e tornare indietro.
Proteggere un'applicazione prima della correzione
Quando una falla viene pubblicata prima della sua correzione, più livelli di protezione lasciano il tempo di correggere con calma.
Quattro livelli di protezione intorno all'applicazione
Esporre il meno possibile
Solo i servizi che devono essere pubblici sono raggiungibili; l'amministrazione passa da un accesso privato.
Aggiornare automaticamente
Aggiornamenti di sicurezza del sistema, proposte di aggiornamento delle dipendenze e controllo regolare delle versioni in servizio.
Filtrare il traffico
Un firewall applicativo blocca gli attacchi noti in attesa della correzione.
Limitare i danni
Diritti minimi, file in sola lettura e rilevamento dei comportamenti anomali.
La vostra applicazione
Quando non esiste ancora una correzione, come per le falle del kernel Linux di questa settimana, la competenza fa la differenza: verificare se il servizio vulnerabile è attivo e raggiungibile, poi disattivarlo o chiuderne l'accesso nel frattempo.
Manutenzione per reagire in fretta
Un'applicazione aggiornata, su versioni mantenute, si corregge in poche ore. Un'applicazione rimasta a lungo senza manutenzione richiede prima una migrazione, a volte rischiosa, prima ancora di poter ricevere la correzione. È il caso delle applicazioni ancora su Node.js 20, giunto a fine vita secondo il calendario 
Node.js Release, o su PHP 7, anch'esso non più mantenuto.
Checklist per le vostre applicazioni
- Inventario. Sapete dove gira ciascuna applicazione, compresi ambienti di test, servizi fermi e backup?
- Versioni. Conoscete le versioni realmente in esecuzione e la data di fine supporto?
- Monitoraggio. Chi riceve gli avvisi di sicurezza delle vostre tecnologie, e chi decide il seguito?
- Rilascio. Potete mettere in produzione una correzione da sola, senza i lavori in corso?
- Verifica. Dopo un aggiornamento, controllate la versione attiva e lo stato del servizio?
- Piano B. Sapete isolare un servizio vulnerabile quando non esiste ancora una correzione?
- Funzioni di IA. I vostri assistenti hanno solo gli accessi necessari, e le loro chiavi si possono rinnovare rapidamente?
Manutenzione e hosting
Garantiamo la manutenzione e l'hosting delle applicazioni che sviluppiamo e possiamo riprendere quelle realizzate da altri team. Se volete sapere a che punto è la vostra applicazione rispetto a questi rischi, scriveteci: cominciamo da un inventario.
Fonti e riferimenti
18 fontiNode.js · NGINX · FoxIO · PHP · Help Net Security · +10
- Node.jsAggiornamenti di sicurezza del 21 ottobre 2026nodejs.org
- Node.jsCalendario delle versioni e fine vita di Node.js 20github.com
- NGINXAvvisi di sicurezza, comprese le correzioni del 14 ottobre 2026nginx.org
- FoxIOAttacchi di amplificazione QPACK contro HTTP/3, 20 ottobre 2026, dieci implementazioni testatefoxio.io
- PHPAvviso di sicurezza del 21 ottobre 2026 (CVE-2026-109618 e CVE-2026-109619)php.net
- Help Net SecurityScanner PHP2Shell di Searchlight Cyber, 22 ottobre 2026helpnetsecurity.com
- W3TechsQuota di PHP tra i siti con linguaggio lato server noto, 25 ottobre 2026w3techs.com
- Zero Day InitiativeAvvisi in arrivo, tra cui ZDI-CAN-33549 e ZDI-CAN-33774 (Linux, 21 ottobre 2026)zerodayinitiative.com
- ScyScanFalle KSMBD pubblicate prima di qualsiasi correzione del kernel, 22 ottobre 2026scyscan.com
- Kernel LinuxSegnalare le falle di sicurezza, comprese quelle trovate con l'IAdocs.kernel.org
- Google Threat IntelligenceTempi di sfruttamento 2018–2023, vulnerabilità sfruttate monitorate da Mandiantcloud.google.com
- MandiantM-Trends 2026, indagini su incidenti svolte nel 2025, stima del tempo di sfruttamentocloud.google.com
- Rapid7Minacce del terzo trimestre 2026, 43 vulnerabilità gravi sfruttate per la prima voltarapid7.com
- Google Threat Intelligence GroupScoperta e sfruttamento delle vulnerabilità nell'era dell'IA, gennaio 2025 – agosto 2026cloud.google.com
- AnthropicCruscotto delle vulnerabilità segnalate, dati al 2 ottobre 2026red.anthropic.com
- OWASPPrompt injection (LLM01:2025)genai.owasp.org
- OWASPCatena di fornitura (LLM03:2025)genai.owasp.org
- Help Net SecurityAttacco alla catena di fornitura di LiteLLM, 22 ottobre 2026helpnetsecurity.com
vibe coding
Swiss Made Software