Το συμβάν με το JavaScript worm στο Meta‑Wiki στις 5 Μαρτίου 2026 ήταν ένα σοβαρό περιστατικό ασφαλείας που προήλθε από δοκιμές του ίδιου του Wikimedia Foundation και ανέδειξε τις αδυναμίες του οικοσυστήματος των user scripts στα wiki. Παρότι οι επιπτώσεις περιορίστηκαν σε βανδαλισμούς και προσωρινό «πάγωμα» επεξεργασιών, το γεγονός έδειξε πόσο εύθραυστο είναι το όριο εμπιστοσύνης όταν εκτελείται αυθαίρετος κώδικας μέσα στα προνόμια των χρηστών.
Πώς ξεκίνησε το περιστατικό
Σύμφωνα με την επίσημη ανακοίνωση του Wikimedia Foundation και την κάλυψη του Wikipedia Signpost, το περιστατικό συνέβη ενώ μέλη του προσωπικού του WMF έκαναν security review σε user‑authored code σε διάφορα projects. Κατά τη διάρκεια αυτής της διαδικασίας ενεργοποιήθηκε κατά λάθος «κοιμώμενος» κακόβουλος κώδικας JavaScript, ο οποίος μέχρι τότε ήταν αποθηκευμένος ως user script και δεν εκτελούνταν.
To WMF αναφέρει επίσημα ότι ο κώδικας ήταν ενεργός για περίπου 23 λεπτά, προκαλώντας διαγραφές και βανδαλισμούς σε σελίδες του Meta‑Wiki, του κεντρικού wiki συντονισμού του κινήματος. Για να αποτραπεί η περαιτέρω διάδοση, όλα τα projects τέθηκαν σε read‑only για περίπου δύο ώρες και η φόρτωση user JavaScript απενεργοποιήθηκε προσωρινά.
Τι έκανε ακριβώς το worm
Αναλύσεις ασφαλείας και το ειδικό Special report του Signpost δείχνουν ότι το script λειτούργησε ως self‑propagating worm μέσα στο οικοσύστημα MediaWiki. Το βασικό του μοτίβο ήταν να εκτελείται στον browser του χρήστη, να τροποποιεί την προσωπική σελίδα User:Όνομα/common.js ώστε να ξαναφορτωθεί σε κάθε προβολή σελίδας, και –αν ο χρήστης είχε αρκετά δικαιώματα– να επιχειρεί να τροποποιήσει και το MediaWiki:Common.js, το παγκόσμιο script που φορτώνεται για όλους.
Παράλληλα, ο κώδικας χρησιμοποιούσε λειτουργίες όπως το Special:Random για να επιλέγει τυχαίες σελίδες και να τις βανδαλίζει: προσθέτοντας μια υπερμεγέθη εικόνα (π.χ. φωτογραφία πουλιών) και κρυφό JavaScript loader που φόρτωνε εξωτερικό κώδικα από domain εκτός Wikimedia. Σύμφωνα με ανεξάρτητη ανάλυση, τροποποιήθηκαν περίπου 3.996 σελίδες και αντικαταστάθηκαν τα common.js 85 χρηστών μέσα στο παράθυρο των 23 λεπτών.
Επιπλέον, το script περιείχε λογική για χρήση της σελίδας Special:Nuke ώστε να διαγράφει μαζικά σελίδες (μόνο εφόσον ο λογαριασμός είχε admin δικαιώματα) και τεχνικές για να κρύβει τα links προς σελίδες τύπου common.js, δυσκολεύοντας την επαναφορά μέσω του συνηθισμένου interface. Σε επίπεδο συμπεριφοράς, αυτό που είδαν οι χρήστες στο Meta ήταν πολλαπλοί λογαριασμοί με προνόμια να δημοσιεύουν το μήνυμα «Закрываем проект» («κλείνουμε το project») και να διαγράφουν/αδειάζουν σελίδες μαζικά.
Άμεση αντίδραση και αποκατάσταση
Από περίπου 16:00 έως 17:00 UTC στις 5 Μαρτίου 2026 όλα τα Wikimedia projects (συμπεριλαμβανομένης της αγγλικής Wikipedia) τέθηκαν σε read‑only mode, ώστε να σταματήσει άμεσα η εξάπλωση. Ταυτόχρονα, προσωπικό SRE της Foundation επανέφερε χειροκίνητα επεξεργασίες στο Meta και δούλεψε για να εντοπίσει και να εξουδετερώσει τον κακόβουλο κώδικα.
Το Wikimedia Foundation δήλωσε ότι όλες οι κακόβουλες επεξεργασίες αναιρέθηκαν χωρίς να χρειαστεί γενικό rollback της βάσης (άρα δεν χάθηκαν «καλές» επεξεργασίες) και ότι δεν υπάρχει ένδειξη διαρροής προσωπικών δεδομένων ή στοχευμένης εξωτερικής επίθεσης. Ο υπεύθυνος της ομάδας Product Safety and Integrity διευκρίνισε σε δημόσιο κανάλι ότι δεν υπάρχουν στοιχεία για «τρίτο φορέα» που να επιτίθεται ενεργά στο Wikimedia, αλλά για εσωτερικό λάθος κατά τη διάρκεια δοκιμών.
Γιατί υπήρχε ο κακόβουλος κώδικας και πώς ενεργοποιήθηκε
Ρεπορτάζ κυβερνοασφάλειας αποκάλυψαν ότι ο κώδικας δεν γράφτηκε εκείνη τη μέρα, αλλά βρισκόταν ανενεργός επί περίπου δύο χρόνια σε σελίδα χρήστη στη ρωσική Wikipedia, στο User:Ololoshka562/test.js. Ο script αυτός φαίνεται να είχε αρχικά φτιαχτεί για «χαβαλέ» ή για διαμάχη μεταξύ μικρότερων wiki, με βανδαλιστική λογική αλλά χωρίς πρόσβαση στο backend ή σε προσωπικά δεδομένα.
Κατά τη διάρκεια του security review, ένας μηχανικός ασφαλείας του WMF φόρτωσε τον συγκεκριμένο κώδικα στο Meta για να τον εξετάσει, αλλά τον εκτέλεσε ουσιαστικά με πολύ υψηλά προνόμια, επιτρέποντας στο worm να «κολλήσει» λογαριασμούς με δικαιώματα interface/admin. Το Special report του Signpost παρομοιάζει τον κώδικα με «χειροβομβίδα ξεχασμένη σε χωράφι καλαμποκιού»: από μόνη της δεν αποτελεί οργανωμένη επίθεση, αλλά γίνεται επικίνδυνη όταν κάποιος με πολύ υψηλά δικαιώματα την πάρει και την ενεργοποιήσει σε παραγωγικό περιβάλλον.
Διαρθρωτικά προβλήματα που ανέδειξε
Το περιστατικό δεν είναι μόνο «ένα λάθος μηχανικού», αλλά φανερώνει δομικά προβλήματα στο πώς δουλεύει το οικοσύστημα MediaWiki και ειδικά τα user scripts. Πρώτον, η αρχιτεκτονική επιτρέπει σε οποιονδήποτε χρήστη να αποθηκεύει αυθαίρετο JavaScript που θα εκτελεστεί στον browser όποιου φορτώνει τη σελίδα, με τα δικά του session δικαιώματα – κάτι που δημιουργεί πολύ ισχυρό trust boundary μεταξύ περιεχομένου και κώδικα.
Δεύτερον, δεν υπάρχει πλήρες, απομονωμένο test environment για scripts που εξαρτώνται από την πραγματική δομή ενός wiki (modules, templates, gadgets), με αποτέλεσμα αρκετές δοκιμές να γίνονται «σε παραγωγή» ή πολύ κοντά σε αυτή. Αυτό θυμίζει την γενικότερη κατάσταση των templates και modules, όπου πολύπλοκες εξαρτήσεις και έλλειψη versioned περιβάλλοντος δοκιμών οδηγούν κατά καιρούς σε απρόβλεπτες βλάβες· εδώ όμως το πρόβλημα μεταφέρθηκε σε επίπεδο JavaScript με δυνατότητα μαζικού βανδαλισμού.
Τρίτον, η μακροχρόνια παρουσία ενός τόσο προφανώς κακόβουλου script σε user page χωρίς εντοπισμό δείχνει ότι δεν υπάρχει συστηματική αναζήτηση «ύποπτων» μοτίβων κώδικα σε ολόκληρο το σύμπαν των wiki – ειδικά σε γλώσσες και projects όπου η τεχνική παρακολούθηση είναι πιο περιορισμένη.
Μέτρα ασφαλείας και επόμενα βήματα
Το Wikimedia Foundation έχει ήδη δηλώσει ότι «αναπτύσσει επιπλέον security mitigations για user JavaScript σε συνεργασία με την κοινότητα» ώστε να καταστεί τέτοιο περιστατικό πολύ δυσκολότερο στο μέλλον. Αν και το πλήρες post‑incident report δεν είχε δημοσιευθεί αμέσως μετά το συμβάν, τεχνικά ενημερωτικά και Tech News αναφέρουν ότι ενισχύονται οι απαιτήσεις δύο παραγόντων (2FA) για λογαριασμούς με υψηλά προνόμια (π.χ. checkusers, interface admins, suppressors), με απομάκρυνση χρηστών από αυτά τα groups αν δεν ενεργοποιήσουν 2FA σε συγκεκριμένο χρονοδιάγραμμα.
Παράλληλα, η ομάδα Product Safety and Integrity είχε ήδη ξεκινήσει –και θα συνεχίσει– systematic review user‑authored code σε πολλαπλά projects, κάτι που πιθανότατα θα συνοδευτεί από πιο αυστηρές πρακτικές έγκρισης για scripts που επηρεάζουν πολλούς χρήστες (π.χ. site‑wide gadgets). Τέλος, η ίδια η διαφάνεια της κάλυψης (Signpost, εξωτερικά τεχνικά sites, αναρτήσεις σε λίστες και στο Meta) αποτελεί μέρος της «θεραπείας»: η κοινότητα έχει ξεκάθαρη εικόνα του τι έγινε, ώστε να μπορεί να πιέσει για θεσμικές αλλαγές και όχι μόνο για τεχνικά patches.
Επιπτώσεις για την κοινότητα και την αντίληψη ασφάλειας
Τις ώρες της διακοπής, αρκετοί χρήστες σε Discord και Telegram φοβήθηκαν ότι πρόκειται για κρατικό cyber‑attack ή συντονισμένη προσπάθεια λογοκρισίας, ειδικά βάσει του ρωσικού μηνύματος «Закрываем проект» και του διεθνούς πολιτικού κλίματος. Η διαβεβαίωση ότι δεν υπήρχε ένδειξη εξωτερικού επιτιθέμενου, αλλά εσωτερικό λάθος, έφερε ανακούφιση, αλλά ταυτόχρονα ενίσχυσε το αίσθημα ότι η εσωτερική ασφάλεια των εργαλείων του ίδιου του κινήματος χρειάζεται αναβάθμιση.
Το περιστατικό αποτελεί παράδειγμα του πόσο στενά συνδέονται τεχνική υποδομή και εμπιστοσύνη του κοινού: αν ένα worm μπορεί, έστω για λίγα λεπτά, να κάνει μαζικό βανδαλισμό με χρήση κανονικών λογαριασμών, τότε ο «μέσος αναγνώστης» δύσκολα ξεχωρίζει αν πρόκειται για trolling, κράτος ή οργανωμένη επίθεση. Η σχετικά γρήγορη αντίδραση (read‑only, αναιρέσεις, διαφάνεια) λειτούργησε ως απόδειξη ανθεκτικότητας, αλλά ταυτόχρονα ανέδειξε ένα «παραλίγο» σενάριο όπου τα πράγματα θα μπορούσαν να είναι πολύ χειρότερα.
Πρακτικές συστάσεις για συντάκτες και διαχειριστές
Για τους απλούς συντάκτες, η βασική συνέπεια είναι ότι πρέπει να αντιμετωπίζουν το προσωπικό τους common.js σαν κρίσιμο κομμάτι ασφαλείας: να γνωρίζουν τι ακριβώς τρέχει, να αποφεύγουν copy‑paste κώδικα από άγνωστες σελίδες, και να περιορίζονται κατά προτίμηση σε καλά τεκμηριωμένα, ευρέως χρησιμοποιούμενα scripts ή gadgets. Είναι καλή πρακτική, μετά από τέτοια περιστατικά, να ανοίγουν και να ελέγχουν το User:Όνομα/common.js για απρόσμενες αλλαγές και να σβήνουν ό,τι δεν αναγνωρίζουν.
Για λογαριασμούς με προνόμια (admins, interface admins, checkusers κ.λπ.), η απαίτηση για 2FA δεν είναι τυπική υποχρέωση αλλά κρίσιμη ασπίδα: στην πράξη, ένας «μολυσμένος» browser με admin session μπορεί να προκαλέσει τεράστια ζημιά σε λίγα λεπτά, όπως έδειξε το worm. Ειδικά όσοι έχουν πρόσβαση σε σελίδες όπως MediaWiki:Common.js πρέπει να αποφεύγουν να εκτελούν άγνωστο κώδικα σε παραγωγικά wiki και, όπου είναι δυνατόν, να χρησιμοποιούν test wikis ή sandbox accounts χωρίς προνόμια για αρχική εξέταση ύποπτων scripts.
Τέλος, για θεσμικούς φορείς του κινήματος (user groups, chapters), το περιστατικό είναι ένα καμπανάκι ότι η τεχνική ικανότητα και ασφάλεια δεν είναι «θέμα των devs», αλλά κρίσιμος παράγοντας αξιοπιστίας του συνόλου. Η συμμετοχή σε συζητήσεις στο Meta, σε RFCs για περιορισμούς στα user scripts και σε πρωτοβουλίες για εκπαίδευση γύρω από ασφαλείς πρακτικές μπορεί να βοηθήσει ώστε το επόμενο λάθος να μη βρει το κίνημα τόσο εκτεθειμένο.
