OpenAI ha presentato un modello che in pochi giorni ha trovato 81 falle gravi in Firefox e ricostruito 948 attacchi al kernel Linux. Il record in sé conta poco. Conta l’economia che ne deriva: trovare le falle costa sempre meno, ripararle richiede ancora tempo umano. Plugin, temi e server non aggiornati diventano bersagli molto più facili. Più di 1.000 server GitLab sono stati attaccati proprio così.
Se lavorate in proprio, con un sito vetrina o un portfolio, la conseguenza è concreta. Il sito “finito” e lasciato lì non è più un oggetto inerte: è una superficie esposta che nessuno sta guardando.
Il caso tipico: il sito dimenticato
Immaginate un sito costruito qualche anno fa. Funziona, porta qualche contatto, quindi nessuno lo tocca. Dentro ci sono plugin che non vedono un aggiornamento da mesi, un tema abbandonato dallo sviluppatore, l’account di un collaboratore che non lavora più con voi e un pannello di amministrazione raggiungibile da chiunque.
Negli incidenti recenti raccontati dalle cronache di sicurezza, l’ingresso è quasi sempre banale. Nelle centinaia di supermercati francesi finiti in sbrinamento forzato, il costruttore ha spiegato che molti controllori avevano firmware obsoleto o a fine vita. Nei sistemi idrici del Minnesota erano state colpite apparecchiature esposte su internet. Nel caso di Binance c’entrano un installer scaricato da un risultato di ricerca e un token di deploy su un portatile. Niente di sofisticato: accessi dimenticati e software vecchio.
Anche quando il bug è serio, i tempi sono contro di voi. Il 21 ottobre PHP ha rilasciato le correzioni per due vulnerabilità di esecuzione remota di codice, valutate 9,2 (CVE-2026-109618 e CVE-2026-109619). In certe condizioni non richiedono alcun login. CISA le ha dichiarate sfruttate attivamente già il 26 ottobre, e Cloudflare ha contato migliaia di tentativi prima dell’annuncio e milioni dopo. Se il vostro sito gira su PHP, controllate la versione installata.
Il controllo trimestrale in 4 punti
Bastano un’ora e un promemoria ricorrente ogni tre mesi.
- Aggiornamenti. Verificate core del CMS, plugin, temi e versione di PHP sul server. Se un componente non riceve più patch dallo sviluppatore, trattatelo come un problema da risolvere subito.
- Utenti inutilizzati. Elencate tutti gli account con accesso al sito, all’hosting e al dominio. Eliminate quelli di ex collaboratori e fornitori che hanno concluso il lavoro, e verificate che chi resta abbia solo i permessi che gli servono.
- Accessi esposti. Controllate cosa è raggiungibile da fuori: pannello di amministrazione, accesso al database, servizi di test. Cambiate le password predefinite o deboli, attivate l’autenticazione a due fattori e controllate le autorizzazioni concesse a strumenti di terze parti: anche un’integrazione con permessi eccessivi può diventare la porta d’ingresso.
- Backup provato. Un backup che non avete mai ripristinato è solo un’ipotesi. Fate una prova di ripristino su un ambiente separato e annotate quanto tempo serve davvero.
Cosa spegnere se non serve più
Ciò che non è attivo non si attacca. Rimuovete i plugin inutilizzati, senza fermarvi alla disattivazione dal pannello. Eliminate temi di prova, ambienti di staging dimenticati, script di terze parti non più necessari (Polymarket ha sospeso le operazioni dopo che codice malevolo era stato servito da uno script di monitoraggio esterno) e sottodomini orfani. Se un sito o una landing page di una vecchia campagna non ha più uno scopo, la scelta più sicura è archiviarla e metterla offline.
Il filo comune
In quasi tutti i casi citati l’ingresso è noioso, e il danno dipende da quanto accesso c’era attorno. Un controllo ripetuto e metodico costa poco rispetto a un sito compromesso, e restringe lo spazio in cui possono lavorare i nuovi strumenti di ricerca delle falle.
