Атака JavaScript-червя на Википедию: урок для разработчиков

[hannadev]

5 марта 2026 года Wikimedia Foundation столкнулась с серьёзным киберинцидентом, когда самораспространяющийся JavaScript-червь атаковал проекты организации. За 23 минуты активности вредоносный код изменил около 3996 страниц и заразил пользовательские скрипты 85 редакторов. Инцидент вскрыл критические проблемы в безопасности пользовательского кода и показал, как быстро может распространяться вредонос при наличии правильных условий.

Эта история важна не только для администраторов Википедии, но и для всех разработчиков, которые работают с JavaScript и управляют контентом, загружаемым пользователями. Давайте разберёмся, что произошло, как работала атака и какие выводы нужно сделать, чтобы защитить свои проекты.

Как началась атака

Всё началось с невинной, казалось бы, проверки безопасности. Сотрудник Wikimedia Foundation проводил ревизию пользовательских скриптов и во время этого процесса случайно активировал вредоносный файл, который хранился в русскоязычном разделе Википедии с марта 2024 года. Этот файл с названием User:Ololoshka562/test.js был давно забыт и мирно ждал своего часа.

Когда скрипт был загружен в браузер авторизованного редактора, он сразу же начал свою чёрную работу. Вредоносный код попытался внедрить вредоносный загрузчик сразу в два места: в пользовательский файл common.js авторизованного участника и в глобальный файл MediaWiki:Common.js, который применяется ко всем редакторам проекта.

Технический механизм был прост, но эффективен:

• Вредоносный скрипт автоматически запускался при открытии любой страницы редактором
• Код пытался модифицировать JavaScript-настройки пользователя в его файле common.js
• Если у аккаунта были права администратора или модератора, скрипт также менял глобальный скрипт сайта
• Любой редактор, случайно открывший заражённую страницу, невольно становился переносчиком вируса

Самораспространение как оружие

Почему этот червь был так опасен? Потому что он был спроектирован для самостоятельного распространения через систему пользовательских скриптов. Это не была простая вредоносная вставка на одной странице - это была целая цепочка инфекции.

Когда вредоносный код попадал на компьютер редактора, он не просто выполнял одно действие и затем прекращал работу. Вместо этого он создавал новые точки заражения. Червь вписывал себя в пользовательские скрипты других людей, создавая экспоненциальный рост инфекции.

Помимо попыток заражения пользовательских и глобальных скриптов, червь также портил содержимое страниц. На некоторых страницах появлялась фраза «Закрываем проект», а также скрытый загрузчик, который мог загружать дополнительный вредоносный код с внешних серверов.

Вот как выглядела цепочка распространения:

Этап	Действие
1	Скрипт активируется в браузере авторизованного пользователя
2	Код внедряется в пользовательский common.js
3	Глобальный MediaWiki:Common.js модифицируется (если есть права)
4	Любой, кто откроет заражённый скрипт, получит инфекцию
5	Червь начинает портить случайные страницы
6	Вредоносный код распространяется экспоненциально

Почему стандартные защиты не сработали

Железобетонный вопрос: а почему администраторы Википедии не поймали этот скрипт раньше? Скрипт ведь загрузили ещё в 2024 году, а сработал он лишь через полтора года!

Причин несколько, и все они показательны для безопасности любого проекта. Во-первых, вредоносный код был скрыт в обычном пользовательском скрипте среди тысяч других. Найти его в ручную невозможно. Во-вторых, скрипт был не активирован - он спокойно лежал в архиве истории правок, ничем не выделяясь.

В-третьих, и это самое главное, система Википедии доверяла пользовательским скриптам. Администраторы и опытные редакторы могут загружать JavaScript-код, который выполняется на клиенте. Это даёт огромную гибкость, но создаёт гигантскую дыру в безопасности, если внутри этого доверия оказывается вредоносный код.

Основные проблемы, которые вскрыла атака:

• Отсутствие автоматической проверки пользовательских скриптов на вредоносный код
• Слишком широкие права у авторизованных пользователей в отношении глобальных скриптов
• Отсутствие изоляции между пользовательскими и системными скриптами
• Историческая закрытость архива - старые, потенциально опасные файлы оставались доступными
• Отсутствие Content Security Policy или других ограничений на выполнение кода

Масштаб катастрофы и скорость реакции

Теперь к печальной статистике. За 23 минуты, пока червь был активен, он успел натворить немало бед. Примерно 3996 страниц получили вредоносные правки, а 85 пользователей обнаружили, что их личные файлы common.js были заражены и модифицированы.

Да, цифры впечатляют, но реакция была быстрой. Как только команда безопасности Wikimedia обнаружила проблему, они сразу:

• Временно ограничили редактирование на всех проектах
• Запустили массовый откат всех подозрительных правок
• Восстановили заражённые файлы common.js у всех пострадавших пользователей
• Удалили вредоносный код из глобальных скриптов
• Скрыли изменённые страницы из истории правок, чтобы предотвратить повторное распространение

Официально Wikimedia Foundation уточнила, что инцидент затронул только Meta-Wiki (служебный проект), а не саму Википедию. Также фонд не обнаружил признаков утечки персональных данных пользователей.

Что должны помнить разработчики

Даже если вы не администратор Википедии, этот инцидент содержит ценные уроки для любого проекта, работающего с JavaScript и пользовательским контентом.

Первый урок: не доверяй пользовательским скриптам просто так. Если вы позволяете пользователям загружать и выполнять код, предусмотрите многоуровневую проверку. Автоматическое сканирование на известные паттерны вредоноса, белые списки функций, которые разрешены, Content Security Policy - всё это необходимо.

Второй урок: старый код - это бомба замедленного действия. Архивные файлы и историческое содержимое нужно периодически проверять. В идеале - удалять заведомо ненужное. Если вы храните пользовательский код, убедитесь, что вы можете быстро найти и удалить опасный контент, даже если он лежит в истории.

Третий урок: разделяй пользовательский и системный код. В системе Википедии глобальные скрипты выполняются у всех, а пользовательские скрипты - только у того, кто их загрузил. Это разделение помогло локализовать проблему. Если бы червь смог модифицировать основной код сайта сразу, последствия были бы катастрофичнее.

Четвёртый урок: ограничивай права прогрессивно. Новые пользователи не должны иметь доступ ко всем возможностям. Права должны расширяться с опытом и репутацией. В нашем случае вредоносный скрипт смог распространяться потому, что сотрудник Wikimedia (человек с высокими правами) случайно его активировал.

Чек-лист для вашего проекта:

• Введите Content Security Policy с запретом на inline-скрипты и ограничением источников
• Используйте сабдомены для пользовательского контента (user-generated content не должен быть на основном домене)
• Реализуйте автоматическое сканирование загружаемого кода с помощью инструментов вроде ESLint или специализированных SAST-систем
• Ограничьте доступ к глобальным переменным и системным функциям из пользовательского кода
• Регулярно проверяйте архивы и историю на предмет потенциально опасного контента
• Логируйте все операции с привилегированным кодом, чтобы быстро обнаружить аномалии

Чему нас научил червь Википедии

Инцидент с JavaScript-червём на Википедии - это хороший пример того, как одна небольшая ошибка при управлении доступом и проверке кода может привести к масштабным последствиям. Вредоносный скрипт, загруженный полтора года назад, спокойно дремал в архиве, пока не нашёл нужный момент для пробуждения.

Самое интересное, что это не была хитроумная атака от злоумышленников. Это была внутренняя проверка безопасности, которая сама случайно активировала бомбу. Это показывает, что даже в организациях с высоким уровнем защиты возможны цепочки событий, которые приводят к проблемам.

Для каждого разработчика важный вывод: инцидент такого масштаба возможен на любом проекте, если не уделять достаточно внимания изоляции кода, проверке доступа и мониторингу. Начните с малого - добавьте CSP, включите сканирование зависимостей, научитесь быстро реагировать на аномалии. И помните: в безопасности нет мелочей, даже если это просто старый тестовый скрипт в архиве.