О безопасности WordPress обычно говорят внутри самого WordPress: обновить плагины, удалить старых админов, прогнать сканер. Все по делу. Но иногда злоумышленник заходит этажом выше — через панель, которая управляет сервером, бэкапами и сразу несколькими сайтами.
Тогда смена пароля в wp-admin мало что решает. Новый SSH-ключ уже лежит на сервере, скрытый плагин не виден в обычном списке, а в базе мог появиться еще один администратор. Вот и весь фокус.
История FlyWP хорошо это показывает. Не будем делать из нее статью про одну компанию. Куда полезнее посмотреть на свои доступы: кто держит мастер-ключи от сайта и что случится, если один из них утечет?
Что точно известно про августовский взлом
FlyWP обнаружила инцидент 6 августа 2026 года. Он затронул более 700 клиентских серверов. 29 августа компания выпустила официальный отчет об инциденте с известными на тот момент деталями.
Атакующий использовал админскую учетку бывшего сотрудника. Человек уже ушел, а аккаунт остался активным и по-прежнему мог отправлять SSH-ключи на серверы клиентов. То есть ломать пароль конкретного WordPress было незачем. Достаточно добавить свой ключ и войти прямо на сервер.
Причем способ кражи данных от этой учетки пока неизвестен. Фишинг? Повторно использованный пароль? Украденная сессия? Все это лишь версии. Подтвержден другой провал: старый привилегированный доступ не закрыли после ухода сотрудника.
Следы были вполне конкретные. На серверах нашли чужие SSH-ключи, новых администраторов WordPress, скрытые плагины и PHP-файлы для удаленного запуска команд. Еще был поисковый клоакинг: робот поисковика видел не то же самое, что обычный посетитель. Не громкая замена главной страницы, а тихий набор способов остаться внутри.
Украденный бэкап — отдельная история
В отчете есть второй путь, и смешивать его с SSH-доступом не стоит. В отдельной маркетинговой инфраструктуре хранились учетные данные Cloudflare R2 с правом чтения бэкапа рабочей базы. Их получили атакующие, после чего копию базы скачали.
Секреты внутри копии были зашифрованы, а ключи для расшифровки лежали отдельно. FlyWP не нашла признаков того, что эти данные удалось расшифровать. Это хорошая часть истории. Но скачанный бэкап все равно остается утечкой, а не безобидным архивом.
Короче, фраза «нет доказательств расшифровки» не значит «ничего делать не надо». Доступы, которые могли попасть в копию, меняют. Системы, куда они вели, проверяют. И да, маркетинговому сайту обычно ни к чему широкий доступ к рабочим бэкапам.
Панель хостинга — это связка ключей
Для владельца небольшого интернет-магазина хостинг часто выглядит как место, где лежат файлы и раз в год приходит счет. На деле панель может создавать сайты, открывать вход без пароля, управлять копиями и добавлять SSH-ключи. Поэтому нормальный WordPress-хостинг с управлением должен учитывать доступы выше wp-admin, а не только обновлять движок.
Удалили разработчика из WordPress? Хорошо, но это лишь одна дверь. Его аккаунт мог остаться у хостера, в DNS, CDN, облаке, общем хранилище паролей или на самом сервере.
Когда сотрудник, агентство или фрилансер заканчивает работу, в тот же день стоит пройтись по короткому списку:
- панель хостинга, облачные кабинеты, DNS и CDN;
- SSH-ключи, серверные юзеры, SFTP и токены деплоя;
- администраторы WordPress, активные сессии и Application Passwords;
- хранилище бэкапов, общие пароли и временные ссылки для входа;
- API, SMTP и платежные доступы, если человек их видел.
Мы уже разбирали ошибки с админскими учетками внутри WordPress. Здесь мысль шире: доступ надо отозвать везде, куда он тянется. И сначла понять, куда именно.
После SSH обычной проверки мало
Чистая страница плагинов ничего не доказывает, если у атакующего был SSH. Он мог править PHP напрямую, положить загрузчик в mu-plugins, добавить задание cron или изменить конфиг за пределами сайта. Удалите одного чужого админа — скрипт создаст следующего. Неприятно, но вполне реально.
Поэтому не начинайте с лихорадочного удаления всего подозрительного. Сначала снимок состояния и триаж: сохраняем файлы, базу, доступные логи и временные метки. Потом строим карту заражения. Какие ключи появились? Где лежат файлы удаленных команд? Есть ли скрытые плагины, редиректы, клоакинг и другие сайты на том же сервере?
Рабочая последовательность выглядит так:
- Проверить серверных пользователей, SSH-ключи и все записи в
authorized_keys. - Проверить админов WordPress, сессии, Application Passwords и подозрительные записи в базе.
- Заменить ядро WordPress чистой копией той же версии, а плагины из каталога установить заново из надежных пакетов.
- Вручную пройти темы, премиум-плагины и все, что нельзя безопасно заменить готовой чистой копией.
- Проверить бэкапы: дату, содержимое и реальное восстановление сайта, заказов и почты.
- После чистой замены сменить SSH, базу, WordPress, API, SMTP и платежные доступы.
Именно поэтому очистка взломанного WordPress — не кнопка «удалить малварь». Если стереть видимые файлы до карты заражения, легко потерять следы и оставить первоначальный вход открытым. А если под одной панелью пять сайтов, проверять только тот, где первым всплыл спам, — плохая экономия.
Бэкап тоже может быть заражен
Архив полезен, когда известна его дата и проверено содержимое. Копия, сделанная после проникновения, честно сохранит скрытый плагин, PHP-бэкдор, чужого админа и вредную запись в базе. Восстановите ее вслепую — и вернете взлом собственными руками.
Даже чистая старая копия не спасет, если на сервере остался чужой SSH-ключ. Поэтому сначала сверяют таймлайн, потом проверяют архив в отдельной среде, а после восстановления тестируют магазин целиком: заказы, оплату, письма и вход администратора. Просто распаковать файлы недостаточно.
Об этом же наш материал почему бэкап еще не план восстановления. Копия без проверки — надежда, а не процесс.
Что спросить у хостера сегодня
Не надо бросать управляемый хостинг и вечером учить Linux. Если честно для малого бизнеса это часто сделает ситуацию только хуже. Но три вопроса задать можно.
Кто сейчас имеет доступ к панели и SSH? Как закрываются учетки людей, которые ушли из команды? Может ли маркетинговая или тестовая система читать рабочие бэкапы?
Если ответ звучит как «ну, вроде только наши», попросите провести аудит доступов. Запишите владельца каждого аккаунта и способ его отключения. Скучная работа. Зато при следующей смене разработчика никто не будет гадать, чей ключ торчит в сервере.
WordPress-пароль — одна дверь. Панель, SSH, облако и хранилище копий — другие, причем иногда они открывают сразу весь дом. После такого инцидента сохраняют состояние, проверяют все доступные атакующему уровни, заменяют зараженные компоненты чистыми, разбирают базу и бэкапы, а учетные данные меняют уже после очистки. Иначе второй заход почти приглашен.