Начнём с признания: мы это проверяли на практике. Специалисты securitylab провели серию экспериментов с официальным каталогом плагинов WordPress и нашли в нём дыру, которую сам WordPress закрыл только сейчас. Речь про разницу между приёмом нового плагина и его последующими обновлениями. Свежую версию с уязвимостью можно было спокойно доставить на сотни тысяч сайтов через обновление, потому что обновления, в отличие от первой публикации, толком никто не проверял. Хорошая новость: с этого месяца ситуация меняется. Плохая: до сих пор так работали и мы в эксперименте, и настоящие злоумышленники.
Что мы проверяли и что нашли
Логика атаки на каталог плагинов простая и оттого коварная. При первой публикации плагин проходит ручную модерацию: живой человек смотрит код и решает, пускать его в каталог или нет. А вот дальше плагин живёт своей жизнью и выкатывает обновления, и именно на этом этапе контроль резко слабел. Мы решили проверить, насколько.
Мы собрали десять простых плагинов, честно провели их через первую модерацию и опубликовали в официальном каталоге, где они стали доступны всем. А затем выпустили для каждого обновление, в которое намеренно заложили явную, легко заметную уязвимость. Итог оказался показательным: все десять обновлений приняли без единого вопроса. Ни один опасный фрагмент не вызвал реакции модерации, потому что обновления, по сути, уходили в раздачу автоматически.
Как мы это делали. Это был контролируемый эксперимент, а не атака. Все десять плагинов были тестовыми, код в обновлениях носил формальный характер и не мог навредить ни одному сайту: он лишь обозначал уязвимость, но не эксплуатировал её. Сразу после проверки мы немедленно закрыли все плагины. Наша цель была не навредить, а показать разрыв в процессе, о котором давно стоило говорить вслух.
Почему это работало
Причина в том, что защита стояла не там, где нужно. Всё внимание модерации уходило на момент приёма нового плагина, а обновления считались чем-то второстепенным, мол, автор уже проверен, чего его перепроверять. Но именно так и действуют настоящие атакующие. Схема отработана годами: опубликовать чистый, полезный плагин, дождаться, пока им начнут пользоваться тысячи сайтов, а потом тихо подсунуть вредонос в обычном на вид обновлении. Пользователь видит привычное «доступна новая версия», нажимает «обновить», и своими руками ставит себе бэкдор.
Мы уже разбирали ровно ту же болезнь на другом примере: атаку автономных агентов на репозиторий RubyGems, где тысячи вредоносных пакетов заливались в доверенный источник. Каталог плагинов WordPress — это такой же источник, которому по умолчанию доверяют миллионы сайтов. А доверие, которое никто не перепроверяет, рано или поздно превращается в канал доставки вредоноса.
Что теперь изменил WordPress
И вот главная новость: WordPress ввёл автоматическую проверку безопасности для каждого релиза, и, что важно, не только для новых плагинов, но и для всех обновлений. Именно того, чего не хватало. Теперь любая новая версия перед тем, как разойтись по сайтам, попадает в короткое окно выдержки, во время которого её изучают.
| Как устроена новая проверка | Детали |
|---|---|
| Что проверяют | каждый релиз — и новые плагины, и все последующие обновления |
| Окно проверки | около 6 часов до раздачи (раньше было 24) |
| Чем анализируют | несколько ИИ-моделей вместе со сканером Jetpack Scan |
| Результат | сводная оценка риска по найденным проблемам |
| При высоком риске | версия автоматически блокируется и не уходит на сайты |
| Уведомление | разработчик получает письмо с результатами проверки |
Оценка меряет именно уровень риска, а не намерение: случайная уязвимость и намеренная закладка получают схожий балл, и это правильно, ведь сайту всё равно, по злому умыслу его сломают или по недосмотру. Если версия набирает высокий балл, её блокируют автоматически, не дожидаясь, пока кто-то из команды освободится и посмотрит вручную. Система уже сработала в бою: 28 июля в обновление плагина с примерно 20 000 активных установок закрался бэкдор. Автоматическая проверка поймала его прямо в окне выдержки, поставила высокий балл, и заражённая версия так и не ушла на сайты. Плагин закрыли через 26 минут после уведомления команды.
Почему это критично именно сейчас
Раньше сделать убедительный вредоносный плагин было делом небыстрым: нужно писать код, разбираться в API WordPress, маскировать закладку. Это отсекало случайных людей. Теперь порог рухнул. С приходом вайбкодинга (разработки, где код за человека пишет ИИ по описанию на обычном языке) любой желающий может за 20–30 минут собрать рабочий плагин, который с высокой вероятностью прошёл бы модерацию каталога. Не нужно быть программистом, достаточно уметь описать задачу словами.
Это меняет масштаб угрозы. Одно дело, когда вредоносные плагины клепает горстка технически подкованных злоумышленников. Другое — когда это может сделать кто угодно, быстро и дёшево, а сгенерированный ИИ код к тому же выглядит чисто и не вызывает подозрений. Ровно поэтому ручной проверки на приёме давно перестало хватать: человек физически не успевает вычитывать поток обновлений, а автоматика с несколькими моделями успевает. По сути, WordPress ответил на угрозу от ИИ таким же ИИ, и это разумный ход.
Что делать владельцам сайтов и разработчикам
Новая проверка WordPress — большой шаг, но она закрывает только официальный канал. За остальное по-прежнему отвечаете вы.
- Не обновляйтесь вслепую. Автообновление всего подряд удобно, но именно оно превращает подмену версии в мгновенную компрометацию. Для критичных сайтов имеет смысл ставить обновления с небольшой задержкой и следить за тем, что меняется.
- Сократите число плагинов. Каждый сторонний плагин — это чужой код с полными правами на вашем сайте. Чем их меньше, тем меньше поверхность атаки. Навести здесь порядок помогает аудит защищённости сайта.
- Ставьте плагины только из проверенных источников и никогда из «нуллед»-сборок и сомнительных архивов, где проверки нет вообще.
- Проверяйте то, что для вас критично, руками. Если на плагине держится бизнес, его код стоит прогнать через аудит исходного кода, а сам сайт — через пентест CMS. Подозрительную находку разберёт анализ вредоносного ПО.
- Разработчикам плагинов и всем, кто строит цепочку сборки, стоит встроить проверки безопасности в свой конвейер заранее — это задача DevSecOps, а не разовая уборка перед релизом.
Вывод
Наш эксперимент и свежий шаг WordPress говорят об одном и том же с разных сторон. Мы показали, что канал обновлений годами оставался слабым звеном, через которое уязвимость доезжала до сайтов без всякой проверки. WordPress наконец закрыл эту дверь автоматическим ревью каждого релиза. Появление вайбкодинга сделало это не роскошью, а необходимостью: раз плагин с закладкой теперь собирается за полчаса кем угодно, то и проверять надо всё и постоянно, а не только новичков на входе. Владельцам сайтов вывод простой: официальный каталог стал безопаснее, но слепое доверие к любому обновлению — по-прежнему плохая идея. Если хотите понять, где именно уязвим ваш сайт на WordPress, начните с пентеста CMS и аудита кода — пока это не сделал кто-то другой. О том, как ИИ в целом переписывает правила и в нападении, и в обороне, мы писали в разборах массовой атаки на PaperCut и нагрузки на SOC.