Wikipedia bucata da un worm JavaScript: 4.000 pagine infettate in 23 minuti

Vulnerabilità plugin WordPress 2026: patch o aspetti lo 0day?

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.

Il worm che dormiva da due anni

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.

L'anatomia di un attacco elegante

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:

1. Lo script malevolo, una volta attivato, modificava il common.js globale — lo script condiviso che viene caricato da tutti gli utenti
2. Chiunque visitasse una pagina con lo script infetto eseguiva il worm nel proprio browser, che usava la sessione autenticata per modificare altre pagine
3. Se l'utente infetto aveva privilegi elevati (admin, steward), il worm poteva modificare script globali su altri progetti Wikimedia, moltiplicando la propagazione

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.

23 minuti, 4.000 pagine: i numeri del disastro

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:

• 3.996 pagine modificate o vandalizzate
• 85 utenti con il proprio common.js sovrascritto
• Pagine cancellate su Meta-Wiki (poi ripristinate)
• Wikipedia messa in modalità read-only per circa 2 ore
• Tutto il JavaScript utente disabilitato per gran parte della giornata

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.

Il modello di fiducia di Wikipedia è un colabrodo

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.

Cosa dovrebbe cambiare (ma probabilmente non cambierà)

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.

Fonti

Fonti: BleepingComputer, SecureBlink, MalwareTips Forum, PhoneWorld