6 marzo 2026 · 5 min lettura
Intelligenza Artificialeduck.ai promette chat AI senza tracciamento: nessun log, nessun IP, accordi con Anthropic e OpenAI. Ma DuckDuckGo ha già tradito questa fiducia una volta.
Self-HostingLa cloud sovranità europea è sovereignty washing: i datacenter sono in UE, le chiavi restano a Seattle. Gaia-X è fallito, NIS2 stringe. Il homelab risponde.
Self-HostingIscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
900k siti WordPress esposti a RCE critico, 500k a file read su wp-config.php. Se ospiti WordPress in homelab o su VPS, ecco cosa fare nei prossimi 30 minuti.
Un pezzo di JavaScript dormiente da due anni, nascosto nella Wikipedia russa, si è svegliato e in 23 minuti ha infettato quasi 4.000 pagine. Il bello? A risvegliarlo è stato lo stesso staff di Wikimedia, durante una revisione di sicurezza. Non è un film: è successo ieri.
Il 5 marzo 2026, gli ingegneri della Wikimedia Foundation stavano facendo quello che qualsiasi team di sicurezza serio dovrebbe fare: una revisione del codice caricato dagli utenti sulla piattaforma. Peccato che nel farlo abbiano inavvertitamente attivato un codice malevolo che sonnecchiava indisturbato dal marzo 2024, piazzato nello script User:Ololoshka562/test.js sulla Wikipedia in lingua russa.
Da quel momento è partito il caos. Il worm, una volta sveglio, ha fatto esattamente quello per cui era stato progettato: auto-propagarsi. Ha modificato gli script globali common.js di Wikipedia, trasformando ogni editor che caricava una pagina infetta in un vettore inconsapevole dell'infezione. In pratica, il browser di ogni utente autenticato diventava un soldatino che eseguiva ordini, modificando altre pagine e infettando altri script.
Il meccanismo è tanto semplice quanto devastante. Wikipedia consente agli utenti registrati di caricare script JavaScript personalizzati che girano nel browser con i pieni privilegi della sessione autenticata. Un editor scrive codice, lo carica, e quel codice può fare praticamente tutto ciò che l'utente può fare manualmente: modificare pagine, cancellare contenuti, alterare altri script.
Il worm sfruttava questa architettura con una catena di attacco a tre passaggi:
Il payload finale? Un collegamento a un dominio esterno — basemetrika.ru — che orchestrava le modifiche automatiche e il vandalismo visuale. Lo script caricato da quel server eseguiva edits in massa, cancellando e alterando contenuti su Meta-Wiki.
Il worm è rimasto attivo per soli 23 minuti prima che il team di sicurezza riuscisse a bloccarlo. Eppure, in quel lasso di tempo ridicolmente breve:
Wikimedia ha rassicurato che nessun dato personale è stato compromesso e che tutti i contenuti cancellati sono stati ripristinati. Ma il problema non è il danno di ieri — è il principio.
Parliamoci chiaro: Wikipedia si regge su un modello di sicurezza che ha vent'anni e si vede. L'idea che chiunque possa caricare JavaScript arbitrario che gira con i privilegi dell'utente nel browser è, nel 2026, una follia. È come lasciare le chiavi dell'auto nel cruscotto con un cartello "per favore non rubatela".
Il concetto di user scripts nasce da un'epoca in cui la community era piccola, i contributori si conoscevano e la fiducia reciproca era il collante della piattaforma. Ma Wikipedia oggi ha oltre 60 milioni di pagine in 300 lingue. Non è più un progetto comunitario di nicchia — è un'infrastruttura critica dell'informazione globale, consultata miliardi di volte al mese. Eppure il suo modello di sicurezza per il codice eseguibile è rimasto fermo all'era pre-smartphone.
E l'ironia suprema? Lo staff di sicurezza ha attivato il worm durante la propria revisione. Se non fossero stati loro a svegliarlo, quel codice sarebbe ancora lì, dormiente, in attesa del momento giusto. Quanti altri script malevoli sonnecchiano nelle pieghe di Wikipedia in questo momento? Nessuno lo sa, e questo è il punto.
La soluzione tecnica esiste ed è ovvia: sandboxing degli script utente, revisione obbligatoria del codice prima dell'attivazione, Content Security Policy rigorosa che impedisca il caricamento di script da domini esterni, scansione automatica del codice caricato. Roba che qualsiasi piattaforma web moderna implementa di default.
Ma Wikipedia non è una piattaforma qualsiasi. È governata da una community che storicamente resiste a qualsiasi forma di centralizzazione del controllo. Proporre di limitare gli user scripts equivale a toccare un nervo scoperto: la libertà assoluta di personalizzazione è un dogma, e chi lo mette in discussione viene trattato come un eretico.
Eppure, l'alternativa è continuare a giocare alla roulette russa. Ieri è andata bene: vandalismo, nessun dato rubato, tutto ripristinato in poche ore. Ma la prossima volta il worm potrebbe non limitarsi al vandalismo. Potrebbe esfiltrare sessioni, iniettare contenuti falsi in modo sottile, o compromettere gli account degli amministratori per settimane prima che qualcuno se ne accorga.
Wikipedia è il sito più consultato al mondo dopo Google, eppure tratta la sicurezza del codice eseguibile come un progetto hobby del 2003. Questo incidente non è un'anomalia — è la conseguenza inevitabile di un modello che confonde la fiducia con l'ingenuità. Finché chiunque potrà caricare JavaScript arbitrario su una piattaforma usata da miliardi di persone, non è questione di SE succederà di nuovo, ma di QUANDO. E la prossima volta potrebbe non bastare il tasto "ripristina".
Fonti: BleepingComputer, SecureBlink, MalwareTips Forum, PhoneWorld