Злам сайтів через 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, напишіть нам — подивимося, що з вашим сайтом, і скажемо, що робити далі.