Взлом сайтов через UpdraftPlus: как проверить свой WordPress

Что произошло 17–23 октября 2026 года

UpdraftPlus — один из самых популярных плагинов резервного копирования для WordPress: более 3 миллионов активных установок. У его разработчика TeamUpdraft есть ещё несколько связанных сервисов: облачное хранилище UpdraftVault, клонирование сайтов UpdraftClone и панель UpdraftCentral, из которой можно управлять многими сайтами сразу — обновлять их, запускать бэкапы, ставить плагины. Именно эта панель стала каналом атаки.

Хронология событий

• 17–18 октября. TeamUpdraft обнаружил несанкционированный доступ к сайту teamupdraft.com. По заявлению компании, злоумышленник, вероятно, получил доступ к базе клиентов. В ней были имена, email, адреса для счетов, история заказов, хеши паролей, настройки двухфакторной аутентификации и ключи подключения UpdraftCentral, UpdraftVault и UpdraftClone. Данные платёжных карт там не хранились.
• 18 октября, днём. По данным Patchstack, на сайтах появились первые установленные бэкдоры. Команды приходили через UpdraftCentral и были подписаны настоящими ключами, поэтому сайты выполняли их как легитимные.
• 19 октября. Словацкая компания Nethemba заметила атаку на трёх собственных сайтах и опубликовала технический разбор. Patchstack в тот же день предупредил, что обновления плагина, которое остановило бы атаку, пока нет. Вечером TeamUpdraft выпустил UpdraftPlus 1.26.12 / 2.26.12, а затем 1.26.13 / 2.26.13.
• 20–21 октября. TeamUpdraft сообщил, что доступ закрыт, к расследованию привлечены внешняя компания по кибербезопасности и полиция, а доказательств того, что злоумышленник до сих пор имеет доступ к системам компании, нет. При этом Nethemba зафиксировала новые команды 21 октября — на сайты, которые ещё не обновились и не удалили ключи.
• 23 октября. Разработчик уточнил время отсечения ключей: версия 1.26.13 отключает все подключения UpdraftCentral, созданные до 13:07 по британскому времени 18 октября. Расследование продолжается.

Почему важна именно версия 1.26.13

Промежуточная версия 1.26.12 / 2.26.12 из-за ошибки ключи не удаляла — Nethemba советует её не использовать. Исправление — в 1.26.13 (бесплатная) и 2.26.13 (Premium). WordPress.org разослал обновление автоматически, но если автообновления плагинов у вас отключены или сайт давно никто не открывал, версия могла остаться старой.

Это не уязвимость в коде, а украденные ключи

Большинство новостей о взломах WordPress касаются ошибки в коде плагина: кто-то находит «дыру», разработчик её закрывает, все обновляются. Здесь механизм другой, и поэтому привычный рефлекс «обновил — и спокоен» не работает.

UpdraftCentral — это удалённое управление. Когда вы подключаете сайт к панели, на сайте сохраняется ключ. Любая команда, подписанная этим ключом, считается командой владельца: установить плагин, активировать его, обновить, запустить бэкап. Patchstack прямо пишет, что это не уязвимость в UpdraftPlus и для этого инцидента нет CVE, потому что никакой код не взламывали. Злоумышленник просто получил настоящие ключи и воспользовался доверенным каналом так, как им пользуется владелец.

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

А как же июньская уязвимость?

В июне 2026 года в том же канале удалённого управления закрыли настоящую уязвимость — CVE-2026-10795 (исправлена в UpdraftPlus 1.26.5 / 2.26.5). В конце сентября фиксировали попытки использовать её на необновлённых сайтах. Это отдельная история, но она показывает: если ваш UpdraftPlus годами не обновлялся, у сайта могут быть проблемы независимо от октябрьского инцидента.

Под угрозой ли ваш сайт

Прежде чем паниковать, определите, к какой группе относится ваш сайт. По официальному заявлению TeamUpdraft, сами файлы плагина UpdraftPlus и загрузки с WordPress.org скомпрометированы не были, а бэкапы в ваших собственных хранилищах (Google Drive, Dropbox, FTP и т. д.) не пострадали.

Скорее всего, всё в порядке

• Вы пользуетесь бесплатным UpdraftPlus и никогда не регистрировали аккаунт на teamupdraft.com — разработчик пишет, что таким пользователям ничего делать не нужно.
• Вы используете собственную (self-hosted) установку UpdraftCentral на своём сервере — её инцидент не касается.

Нужна проверка

• У вас есть аккаунт TeamUpdraft — Premium-лицензия, UpdraftVault, UpdraftClone или просто регистрация.
• Вы когда-то подключали сайт к облачному UpdraftCentral или привязывали плагин к аккаунту TeamUpdraft. Галочка «Add this website to UpdraftCentral» при привязке была включена по умолчанию, поэтому ключ мог появиться без вашего осознанного решения.
• Сайт обслуживает агентство или фрилансер, которые управляют многими сайтами из одной панели. В этом случае спросите их напрямую.

21 октября TeamUpdraft отдельно призвал Premium-пользователей проверить сайты на необычную активность, даже если они никогда не пользовались UpdraftCentral. Так что если сомневаетесь, к какой группе относитесь, — проверяйте. Это занимает 15–20 минут.

Что делали злоумышленники на взломанных сайтах

Понимание механики атаки помогает проверять осмысленно, а не просто щёлкать по меню. По данным Patchstack и Nethemba, сценарий был таким.

Установка «служебного» плагина

Сайту приходила подписанная команда загрузить и активировать плагин. Patchstack насчитал 99 разных названий таких плагинов и предупреждает, что будут появляться новые. Чаще всего встречалось название «Site Health Cache» — оно выглядит как что-то системное, и владелец не спешит такое удалять. Другие примеры папок: load-stack-35c, boost-kit, src-lab, fast2engine, site-health-364f. Описания тоже «технические»: «Small maintenance toolkit: keeps option storage tidy», «Improves cron tasks efficiency», «Maintenance helper». Авторы вымышленные — PixelBinder, Harbor Stack Labs, CommonGantry, WPBridge, MetaLayer.

Скрытый вход в админку

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

Учётная запись «редактора» с правами администратора

В самом распространённом варианте создавался пользователь с ролью «Редактор», но с дополнительными правами управлять настройками и устанавливать плагины. В списке пользователей он выглядит безобидно, хотя фактически может всё то же, что администратор. Имена — два слова и две цифры, например data-ops43 или media-staff96, email на домене example.org, отображаемое имя «Site Tools». Такой аккаунт остаётся на сайте даже после удаления плагина.

Почему некоторые сайты «падали»

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

Шаг 1. Обновите UpdraftPlus и удалите ключи UpdraftCentral

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

• Откройте «Плагины» и убедитесь, что у UpdraftPlus версия 1.26.13 (или 2.26.13 для Premium) либо новее. Если видите 1.26.12 — обновите обязательно.
• Перейдите в «Настройки → UpdraftPlus Backups → Advanced Tools → UpdraftCentral» и удалите все ключи подключения. Просто убрать сайт из панели UpdraftCentral недостаточно — ключ должен исчезнуть на самом сайте.
• Если у вас есть доступ к WP-CLI, проверка занимает секунду: команда wp option get updraft_central_localkeys. Любой результат, кроме пустого, означает, что ключ на сайте есть. Удалить его можно командой wp option delete updraft_central_localkeys.
• Nethemba также советует удалить ключи Migrator (updraft_migrator_localkeys), если вы сейчас не переносите сайт.

Даже если обновление уже отозвало старые ключи, ручная проверка не лишняя: по данным Nethemba, ключи, созданные в промежутке между временем отсечения и выпуском исправления 18 октября, могли остаться.

Шаг 2. Проверьте плагины, включая must-use

Бэкдор — это плагин, поэтому ищем лишние плагины. Делайте это внимательно, а не по названию, потому что названия меняются.

• В разделе «Плагины» просмотрите весь список, включая неактивные, и вкладку «Обязательные» (Must-Use), если она есть. Всё, что вы не устанавливали или не можете объяснить, — под подозрением.
• Особенно внимательно к названиям вроде «Site Health Cache», «… Toolkit», «Maintenance helper», к папкам по шаблону «слово-слово-три символа» или «название-число», к неизвестным авторам.
• Сравните список в админке с содержимым папки wp-content/plugins через файловый менеджер хостинга или FTP. Один из вариантов бэкдора прятал себя из списка в админке, но на диске его видно.
• Загляните в папку wp-content/upgrade: там могут оставаться распакованные плагины даже после неудачной попытки установки.
• Если есть доступ к серверу, Patchstack советует искать строку «Small maintenance toolkit: keeps option storage tidy» в файлах плагинов — это более надёжный признак, чем название.

Если вы не уверены, какие плагины на сайте действительно нужны, а какие остались «из прошлого», полезно сверить список с нашей подборкой необходимых плагинов для бизнес-сайта. Чем меньше лишнего, тем проще заметить чужое.

Шаг 3. Проверьте пользователей и их права

Даже если плагин уже удалён, созданная им учётная запись может остаться. Поэтому вторая обязательная проверка — пользователи.

• Откройте «Пользователи» и просмотрите всех, а не только администраторов. Подозрительные признаки: имена вроде data-ops43, email на example.org или example.com, отображаемое имя «Site Tools», «System Team», «Web Tech».
• Не доверяйте роли в списке. Опасный аккаунт может иметь роль «Редактор», но с дополнительными правами. Если у вас есть плагин управления ролями или доступ к WP-CLI, проверьте, у кого из не-администраторов есть права manage_options или install_plugins.
• Проверьте дату регистрации пользователей: всё, что появилось с 18 октября и чего вы не создавали, — повод разбираться.
• В базе данных бэкдоры оставляли служебные опции с окончаниями _sync_token, _uid, _installed, _ver, а также sh_cache_ver. Это уже работа для разработчика, но знать о них стоит.

Шаг 4. Просмотрите логи доступа

Логи показывают, успели ли воспользоваться бэкдором. Их можно скачать в панели хостинга (раздел «Логи» или «Статистика») или попросить у поддержки.

• Ищите GET-запросы с длинным 32-символьным токеном в строке параметров, вроде ?_a1b2c3=…32 символа….
• Ответ 302 на такой запрос означает вероятный успешный вход. Ответ 500 — что на сайте стоит «сломанный» вариант бэкдора.
• Команды приходили, в частности, с IP 43.250.53.42 и 2a09:bac5:4e21:2e3c::49b:9, а более поздние попытки — с других адресов. Блокировка IP не защищает: злоумышленник меняет инфраструктуру. Но для поиска в логах эти адреса полезны.
• POST-запросы на главную страницу с параметром udrpc_message — это команды UpdraftCentral. Если вы сами панелью не пользовались, а такие запросы есть, — это сигнал.

Что делать, если нашли бэкдор

Здесь самое важное — не навредить себе ещё больше. Несколько советов из разборов Patchstack и Nethemba звучат неочевидно, поэтому обратите на них внимание.

Порядок действий

• Сначала удалите ключ UpdraftCentral, чтобы злоумышленник не установил бэкдор заново. Nethemba фиксировала, как атакующий удалял «сломанный» бэкдор и ставил новый.
• Не «чините» плагин, который вызывает ошибку 500. Исправление ошибки как раз и включает бэкдор. Его нужно удалить.
• Не удаляйте бэкдор через админку. Удаление через WordPress запускает его файл uninstall.php, который убирает следы. Правильно — деактивировать плагин и переместить его папку за пределы сайта через файловый менеджер или FTP, чтобы сохранить как доказательство.
• Удалите созданные бэкдором учётные записи и служебные опции в базе.
• Смените пароли всех администраторов и завершите все активные сессии. Включите двухфакторную аутентификацию.

Когда сайт считать полностью скомпрометированным

Если в логах есть успешные запросы с токеном (ответ 302) или на сайте нашёлся аккаунт бэкдора, исходите из того, что злоумышленник был внутри как администратор. За это время он мог изменить файлы темы, добавить код в базу, создать другие учётные записи. В таком случае разработчики советуют восстановить сайт из резервной копии, сделанной до 17 октября, сверить файлы с чистой установкой WordPress и заново проверить всех пользователей. Здесь как раз видно, зачем хранить несколько резервных копий за разные даты: если у вас только одна, самая свежая копия, она может уже содержать бэкдор.

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

Если у вас есть аккаунт TeamUpdraft, UpdraftVault или UpdraftClone

Помимо проверки сайтов, есть несколько действий именно с аккаунтом. Их советует TeamUpdraft в официальном заявлении.

• Смените пароль от teamupdraft.com, вводя адрес сайта вручную, а не переходя по ссылке из письма. Смените этот же пароль везде, где вы использовали его повторно.
• Сбросьте двухфакторную аутентификацию в разделе My Account, если вы ею пользуетесь, — настройки 2FA тоже были в базе.
• Будьте осторожны с письмами «от TeamUpdraft». Компания пишет, что никогда не просит пароль или ключи. После утечки базы фишинговые рассылки — типичный следующий шаг.
• UpdraftVault: все сайты отключили от хранилища, поэтому бэкапы туда не поступают, пока вы не подключитесь заново (Настройки → UpdraftPlus → Settings → UpdraftVault → «Already got space?» → новый пароль). После этого запустите ручной бэкап и убедитесь, что он дошёл.
• UpdraftClone: старые клиентские ключи больше не работают, новые берутся в My Account → UpdraftClone Key Management.
• Для Premium Nethemba также советует удалить сохранённый в настройках плагина пароль от аккаунта и заменить ключи доступа к удалённым хранилищам, если сайт был доступен через UpdraftCentral.

Отдельный пункт, о котором часто забывают: проверьте, делаются ли сейчас бэкапы вообще. После отключения UpdraftVault многие сайты тихо остались без резервных копий. Для владельца бизнеса это хуже самого инцидента, потому что у следующей проблемы уже не будет «точки возврата». Контроль бэкапов, обновлений и доступов — часть регулярного ведения сайта с контролем обновлений и резервных копий.

Как не зависеть от одной панели в будущем

Эта история не значит, что UpdraftPlus — плохой плагин или что от удалённого управления нужно отказаться навсегда. Она показывает другое: любой сервис, у которого есть «ключи от всех дверей», становится привлекательной целью. Вот что стоит учесть.

• Не подключайте то, чем не пользуетесь. Если вам нужны только бэкапы, удалённое управление не нужно. Проверяйте галочки по умолчанию при привязке аккаунтов.
• Не спешите подключаться снова. Patchstack советует не восстанавливать подключение UpdraftCentral, пока разработчик не объяснит причину, а если удалённое управление необходимо, создавать ключ под пользователем без права устанавливать плагины.
• Храните бэкапы за несколько дат и в нескольких местах. Одна копия в одном хранилище — это не стратегия.
• Обновляйте плагины регулярно, но помните, что обновление закрывает уязвимости, а не убирает последствия взлома.
• Базовая защита никуда не девается: сложные пароли, 2FA, минимум администраторов, удаление неиспользуемых плагинов. Подробнее — в нашем базовом гайде по безопасности WordPress.
• Дополнительный рубеж для технических команд. Nethemba предлагает mu-плагин, который блокирует команды UpdraftCentral (отвечает 403 на запросы с udrpc_message), или запрет записи в wp-content/plugins со стороны PHP. Такие изменения лучше делать вместе с разработчиком — это типичная доработка сайта на WordPress под требования безопасности.

Типичные ошибки после новостей о взломе UpdraftPlus

Мы видим одни и те же ошибки каждый раз, когда выходит подобная новость. Вот те, которых стоит избежать в этот раз.

• Обновить плагин и считать проблему решённой — обновление не удаляет уже установленные бэкдоры и аккаунты.
• Убрать сайт из панели UpdraftCentral и не удалить ключ на самом сайте.
• Остановиться на версии 1.26.12, которая из-за ошибки ключи не удаляла.
• Искать бэкдор только по названию «Site Health Cache» — названий как минимум 99.
• Проверять только администраторов и пропустить «редактора» с правами администратора.
• Доверять списку плагинов в админке и не заглянуть в папку wp-content/plugins.
• Удалить подозрительный плагин через админку и этим уничтожить следы.
• Исправлять ошибку 500 в «сломанном» плагине вместо его удаления.
• Восстановиться из самого свежего бэкапа, сделанного уже после 18 октября.
• Не сменить пароль от аккаунта TeamUpdraft и повторно используемый пароль на других сервисах.
• Не заметить, что после отключения UpdraftVault бэкапы больше не делаются.
• Заблокировать один IP-адрес и считать сайт защищённым.
• Сразу снова подключить сайт к UpdraftCentral «как было».
• Ответить на письмо «от TeamUpdraft» с просьбой подтвердить пароль или ключ.

Чек-лист: проверка WordPress после инцидента UpdraftPlus

Пройдитесь по пунктам для каждого сайта с UpdraftPlus. Если сайтов несколько, удобно скопировать список в таблицу.

• Определено, есть ли аккаунт TeamUpdraft и подключался ли сайт к облачному UpdraftCentral.
• Вход в админку — напрямую, не через UpdraftCentral.
• UpdraftPlus обновлён до 1.26.13 / 2.26.13 или более новой версии.
• Ключи UpdraftCentral на сайте удалены (Advanced Tools → UpdraftCentral или wp option delete).
• Ключи Migrator удалены, если перенос сайта сейчас не выполняется.
• Просмотрены все плагины, включая неактивные и must-use.
• Список в админке сверен с папкой wp-content/plugins.
• Проверена папка wp-content/upgrade.
• Просмотрены все пользователи, а не только администраторы.
• Проверено, есть ли не-администраторы с правами manage_options или install_plugins.
• Проверены пользователи, созданные после 18 октября.
• Просмотрены логи доступа на запросы с 32-символьным токеном и ответы 302/500.
• Если найден бэкдор — он деактивирован и перемещён за пределы сайта, а не удалён через админку.
• Удалены аккаунты и опции, созданные бэкдором.
• При признаках успешного входа — сайт восстановлен из копии до 17 октября.
• Сменены пароли всех администраторов, завершены активные сессии.
• Включена двухфакторная аутентификация.
• Сменён пароль от teamupdraft.com и сброшена 2FA в аккаунте.
• Сменены повторно используемые пароли на других сервисах.
• UpdraftVault подключён заново, ручной бэкап прошёл успешно.
• Ключи доступа к удалённым хранилищам заменены, если сайт управлялся через UpdraftCentral.
• Повторное подключение к UpdraftCentral отложено или сделано с ограниченным пользователем.

Частые вопросы

Все ли сайты с UpdraftPlus взломаны?

Нет. Под угрозой были сайты с активным подключением к облачному UpdraftCentral. Пользователям бесплатного UpdraftPlus без аккаунта TeamUpdraft разработчик советует ничего не делать, а собственная (self-hosted) установка UpdraftCentral инцидентом не затронута.

Достаточно ли обновить UpdraftPlus до 1.26.13?

Нет. Обновление отзывает ключи, созданные до 13:07 по британскому времени 18 октября, и так закрывает канал атаки. Но оно не удаляет вредоносные плагины и учётные записи, которые уже успели появиться на сайте. Их нужно найти и убрать вручную.

Как понять, подключён ли мой сайт к UpdraftCentral?

Откройте «Настройки → UpdraftPlus Backups → Advanced Tools → UpdraftCentral». Если там есть ключи — подключение есть. Через WP-CLI это проверяет команда wp option get updraft_central_localkeys: любой непустой результат означает, что ключ на сайте есть.

Защищает ли двухфакторная аутентификация от этого бэкдора?

Нет. Бэкдор входит в админку, устанавливая cookie напрямую и минуя форму входа, поэтому 2FA, лимиты попыток и плагины защиты входа не срабатывают. Двухфакторная аутентификация нужна для защиты после очистки сайта, но не спасает от уже установленного бэкдора.

Можно ли просто удалить подозрительный плагин через админку?

Лучше нет. Удаление через WordPress запускает файл uninstall.php плагина, который может убрать следы атаки. Разработчики советуют деактивировать плагин и переместить его папку за пределы сайта через FTP или файловый менеджер, а затем отдельно удалить созданные им аккаунты и опции.

Пострадали ли мои бэкапы в Google Drive или Dropbox?

По заявлению TeamUpdraft, бэкапы в ваших собственных хранилищах не скомпрометированы. Но если сайт был доступен через UpdraftCentral, разработчик советует на всякий случай повторно авторизовать удалённое хранилище и сменить ключи доступа к нему.

Из какой резервной копии восстанавливать сайт?

Из копии, сделанной до 17 октября 2026 года. Копии после 18 октября могут уже содержать бэкдор или созданные им учётные записи. После восстановления всё равно обновите UpdraftPlus, удалите ключи UpdraftCentral и смените пароли.

Стоит ли отказаться от UpdraftPlus?

Сам плагин и его загрузки скомпрометированы не были, проблема — в украденных ключах удалённого управления. Отказываться от бэкапов точно не стоит. Разумнее отключить функции, которыми вы не пользуетесь, и не подключать сайт к UpdraftCentral повторно, пока разработчик не опубликует результаты расследования.

Резервные копии спасают, только если за ними следят

Ирония этой истории в том, что атака пришла через инструмент, который должен был защищать сайты, — плагин резервного копирования. Но вывод не в том, что бэкапы опасны. Вывод в том, что сайт — это живой механизм: плагины, ключи, аккаунты, сторонние сервисы. Каждый элемент требует внимания, и чем больше «удобных» подключений, тем важнее знать, какие из них действительно нужны.

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

Команда Webatom занимается созданием и поддержкой сайтов на WordPress под ключ с 2010 года. Если нужна помощь с проверкой или восстановлением сайта после инцидента с UpdraftPlus, напишите нам — посмотрим, что с вашим сайтом, и скажем, что делать дальше.