Недавно самораспространяющийся JavaScript-червь поразил Википедию. За 23 минуты он вандализировал почти 4000 страниц и скомпрометировал 85 аккаунтов. Это реальный случай, который показывает уязвимости в системах с пользовательским кодом.

Разработчики увидят здесь ключевые уроки по безопасности. Мы разберем, как червь работал, и обсудим меры защиты. Такие инциденты помогают избежать ошибок в своих проектах и сделать код надежнее.

Как червь проник и распространился

5 марта 2026 года во время рутинной проверки безопасности сотрудник Wikimedia случайно запустил спящий вредоносный скрипт. Этот код загрузили на русскую Википедию еще в марте 2024 года, и он пролежал незамеченным два года. Скрипт активировался в браузере с повышенными правами, что позволило ему внедриться в глобальный JavaScript-файл.

Далее червь использовал двухуровневую стратегию распространения. Он копировал себя в личные common.js файлов пользователей и в общий MediaWiki:Common.js. Через команды выбирал случайные страницы, вставлял огромные изображения и скрытые JS-загрузчики. Если аккаунт имел админские права, скрипт удалял статьи и внедрял XSS-нагрузки с внешними доменами.

Пользователи заметили проблему на форуме Village Pump. Там обсуждали поток автоматизированных правок с вандализмом и скрытыми скриптами. Это привело к быстрому реагированию: все проекты перевели в режим только чтение.

Этапы распространения

• Активация: Запуск dormant скрипта с привилегиями редактирования глобального JS.
• Инъекция: Копирование в common.js пользователей и MediaWiki:Common.js.
• Вандализм: Случайный выбор страниц, вставка изображений и loaders.
• Эскалация: Удаление контента при админских правах, XSS с внешними ссылками.

Урон и реакция Wikimedia

В результате за 23 минуты пострадали 3996 страниц. Черви заменил personal JS-файлы 85 пользователей, удалил несколько статей. Внедренные скрипты ссылались на внешний домен, что могло привести к дальнейшим атакам. Редакторы сигнализировали о проблеме, что ускорило containment.

Wikimedia ввела read-only режим на два часа, отключила user JavaScript на день. Инженеры отреверсили глобальные изменения, удалили инъекции и откатили common.js для многих пользователей. Изменения suppressed, чтобы скрыть из истории правок. Редактирование восстановили после очистки.

Анализ показал, что это не zero-day уязвимость. Черви просто ждал привилегированного запуска - паттерн как в троянизированных серверах или вредоносных расширениях VS Code.

Ключевой урок: Dormant код опасен, если его могут запустить с правами.

Уязвимости в системах с пользовательским JS

Системы вроде Википедии позволяют загружать user scripts для кастомизации. Это удобно, но открывает дверь для worm’ов. Злоумышленник может спрятать код в test.js, который выглядит безобидно. При выполнении в браузере он использует сессию пользователя для распространения.

Проблема в отсутствии sandboxing для user JS. Скрипты выполняются в контексте сайта с доступом к API. В Википедии это привело к редактированию тысяч страниц без дополнительной аутентификации. Аналогично в других платформах: форумы, CMS с плагинами.

Нюанс: Черви не обходит auth - он крадет сессию. Если аккаунт trusted, ущерб максимален.

Риски пользовательских скриптов

1. Dormant угрозы: Код лежит годами, активируется случайно.
2. Авто-распространение: Инъекция в global файлы поражает всех.
3. Privilege escalation: Админские права усиливают вандализм.
4. XSS payloads: Ссылки на external домены для дальнейших атак.

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

Чтобы избежать подобного, внедряйте Content Security Policy (CSP). Оно блокирует inline скрипты и external loaders. В JS-проектах используйте strict mode и sanitization для user-generated content. Проверяйте все uploads на наличие eval, document.write.

Изолируйте user code в iframe с sandbox. Ограничивайте доступ к DOM и API через Proxy или shadow DOM. Мониторьте правки на аномалии: частые bulk edits, подозрительные домены. Регулярно аудитируйте старые скрипты, как в случае с test.js от 2024 года.

Для фронтенда: валидируйте все вставки в DOM. Backend: rate limiting на edits, quarantine подозрительных аккаунтов. Такие меры спасут от self-propagating угроз.

Важно: Тестируйте в изолированной среде, не на проде.

Что скрывает механизм ожидания

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

Дальше стоит копать в автоматизированный аудит. Такие worms эволюционируют, используя новые API вроде Service Workers. Разработчики, подумайте, как ваши системы выдержат подобное через пару лет.