5 марта 2026 года Wikimedia Foundation столкнулась с самораспространяющимся JavaScript-червем. Этот инцидент затронул Meta-Wiki, где вредоносный код изменил тысячи страниц и пользовательские скрипты. Инженеры срочно откатили правки и ограничили редактирование.

Событие полезно изучить разработчикам: оно показывает риски пользовательского JavaScript в веб-приложениях. Мы разберем механизм атаки, уязвимости и меры защиты. Это поможет избежать похожих проблем в своих проектах.

Как запустился JavaScript-червь

Червь активировался случайно во время проверки пользовательского кода сотрудником Wikimedia. Вредоносный скрипт лежал на странице User:Ololoshka562/test.js в русской Википедии с марта 2024 года. Никто не удалил его два года, и это стало роковой ошибкой.

После запуска в браузере редактора скрипт внедрил загрузчик в персональный common.js пользователя. Если у аккаунта были повышенные права, он переписал глобальный MediaWiki:Common.js, который загружается для всех авторизованных пользователей. Цепная реакция пошла: каждый новый редактор подхватывал заражение автоматически. За 23 минуты пострадали около 3996 страниц, добавлялись скрытые загрузчики и даже фразы вроде «Закрываем проект».

Вот шаги распространения:

• Скрипт test.js выполняется в браузере редактора.
• Внедряет код в common.js пользователя для постоянного заражения.
• При наличии прав меняет глобальный MediaWiki:Common.js.
• Зараженный код запускается у всех, кто открывает вики-страницы.
• Параллельно редактирует случайные страницы с вредоносным загрузчиком.

Уязвимости, которые раскрыл инцидент

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

Проблема в отсутствии строгой модерации: скрипт пролежал два года. Нет автоматической проверки на вредоносность, и аккаунты с правами не мониторятся в реальном времени. Червь использовал инфраструктуру платформы для быстрого распространения, обходя серверную защиту. Это актуально для любых вики, форумов или CMS с пользовательским JS.

Ключевые уязвимости:

• Долгоживущий вредоносный код в пользовательских скриптах без ротации.
• Отсутствие sandboxing для JS - код выполняется с правами пользователя.
• Нет лимитов на правки глобальных файлов вроде MediaWiki:Common.js.
• Зависимость от браузерного выполнения без серверного контроля.

Меры защиты от подобных червей

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

Начните с серверной валидации: проверяйте JS на черные паттерны перед сохранением. Используйте CSP (Content Security Policy) для ограничения источников скриптов. Мониторьте правки в реальном времени и ротируйте подозрительные аккаунты. Тестируйте гаджеты в изолированной среде, не давая им доступ к глобальным файлам.

Рекомендации по защите:

• CSP с strict-dynamic - блокирует inline-скрипты.
• Автоматический аудит JS через инструменты вроде ESLint с безопасными правилами.
• Лимиты прав - глобальные скрипты только для проверенных админов.
• Логирование и алерты на массовые правки.
• Регулярная очистка старых пользовательских скриптов.

Уроки для разработчиков веб-приложений

Инцидент на Википедии - классика: спящий код ждал два года и сработал от одного клика. Остановили за 23 минуты, но ущерб мог быть огромным. Масштаб заражения 3996 страниц говорит о скорости таких угроз.

Осталось подумать о будущих рисках: как защитить от ИИ-генерируемого вредоносного JS или атак на цепочки поставок скриптов. В многопользовательских платформах доверие к контенту - слабое звено, и полагаться только на модерацию нельзя.