Якщо ви читаєте це, бо вже помітили у себе щось дивне – незнайомого адміністратора у списку користувачів, лист про зміну пароля, якого ви не запитували, підроблені записи в блозі або відвертий дефейс, – почну не з теорії, а з короткої відповіді. У переважній більшості нещодавно зафіксованих випадків причина найчастіше одна: сайт вчасно не оновився, і через уразливість у самому WordPress хтось отримав доступ до сервера (виконувати код на сервері).
Порядок дій при цьому майже завжди один і той самий, і він важливіший, ніж здається: спочатку закрити саму вразливість (оновити ядро до виправленої версії), лише потім змінювати паролі та прибирати сліди. Якщо зробити навпаки – очистити сайт, залишивши «двері» відкритими, – вас зламають знову того ж дня, буквально за лічені хвилини.
Нижче я розберу, чому так відбувається і що робити крок за кроком. А ось тим, хто завітав заздалегідь, ще до будь-якого злому, скажу головне відразу: оновлюйте WordPress без затримок і перевіряйте, чи оновлення справді встановилося. Цього одного достатньо, щоб не потрапити в більшість подібних історій, які я розбираю далі. Решта – деталі та підстраховка. І так, на жаль, мені теж днями довелося зіткнутися з цією проблемою.
Що насправді відбувається під час такого злому
Схема майже завжди однакова і складається з двох етапів, які люди плутають між собою. Спочатку – вхід: у коді WordPress знаходять уразливість, яка дозволяє виконати довільну команду на сервері взагалі без пароля, просто надіславши спеціально сформований запит. Це називається RCE (віддалене виконання коду), і це найсерйозніший клас проблем, який тільки може бути. Потім – закріплення: отримавши одноразову можливість щось виконати, зловмисник залишає собі постійний доступ, щоб повертатися, коли захоче, навіть після того, як початкову вразливість закриють.
Свіжий і дуже наочний приклад – історія, яку назвали wp2shell. Технічно це поєднання двох помилок у ядрі WordPress: плутанина з маршрутами в REST API (через службову адресу /wp-json/batch/v1) та SQL-ін’єкція. Окремо кожна з них має обмеження, але разом вони дають зломщику можливість виконання коду на стандартній установці – без жодного плагіна, без входу, без будь-яких особливих налаштувань. Розробники випустили виправлення 17 липня 2026 року та увімкнули примусове автооновлення, а через кілька днів обидві уразливості потрапили до урядового каталогу активно експлуатованих – тобто їх масово використовували в реальних атаках. Публічні експлойти на той момент уже були опубліковані на GitHub, тож поріг входу для зловмисника становив не «команда хакерів», а «скрипт і список сайтів».
Ось як виглядає матриця версій – за нею найпростіше зрозуміти, чи стосується це особисто вас:
| Версія WordPress | Вразлива | Виправлено у |
|---|---|---|
| до 6.8 | не уражені цією вразливістю | – |
| 6.8.0 – 6.8.5 | частково (лише SQL-ін’єкція) | 6.8.6 |
| 6.9.0 – 6.9.4 | так, повністю | 6.9.5 |
| 7.0.0 – 7.0.1 | так, повністю | 7.0.2 |
З того боку, де розташований хостинг, момент появи такої уразливості виглядає дуже характерно. З логів видно, як протягом лічених годин після публікації починається перебір: один і той самий запит до /wp-json/batch/v1 надходить на сотні сайтів поспіль, без розбору, що там за проект. Атака не націлена на вас особисто – вона просто прочісує все, що відповідає, і залишає закладку там, де спрацювало. Тому «та кому мій маленький сайт потрібен» тут не працює зовсім: ніхто й не вибирав ваш сайт, його знайшов автомат.
«У мене ж увімкнені автооновлення!!»
Це найпоширеніше заперечення, і в ньому криється найнеприємніша деталь усієї історії. Так, за таких критичних вразливостей WordPress вмикає примусове оновлення й намагається охопити всіх. Але «намагається» – це не те саме, що «дотягнувся». Примусове оновлення тихо не спрацьовує в кількох цілком звичайних ситуаціях: якщо оновлення вимкнені безпосередньо в wp-config.php (а це часто роблять розробники, «щоб нічого не зламалося»), якщо сайт розгорнуто з системи контролю версій, якщо на файли встановлено занадто суворі права доступу і WordPress фізично не може себе перезаписати, і, на диво, якщо у сайту зовсім невеликий трафік, тому що механізм оновлення прив’язаний до відвідувань.
Саме тут найчастіше виникає плутанина. Користувач бачить у налаштуваннях галочку «автоматичні оновлення увімкнено» і вважає питання вирішеним. А сайт тим часом тижнями залишається на вразливій версії, тому що оновлення з однієї з наведених вище причин не відбулося, і ніхто про це не дізнався – адже помилка є «мовчазною». Перевірка займає тридцять секунд: відкрийте консоль, розділ «Оновлення» і подивіться номер версії на власні очі. Якщо у вас є доступ до терміналу на хостингу, а ще точніше – до команди, яка безпосередньо показує встановлену версію (про роботу через SSH у нас є окремий розбір). Не «мало б оновитися», а «бачу потрібний номер».
Окремо про хмарні брандмауери на кшталт Cloudflare. Вони в таких випадках дійсно застосовують правила, які блокують шкідливі запити на підльоті, іноді в ту ж мить. Це корисно, але це не латка. Правило брандмауера можна обійти, воно може не охоплювати всі вектори, і воно нічого не говорить про те, що сталося з сайтом до того, як правило з’явилося. Покладатися на WAF замість оновлення – це приблизно те саме, що не лагодити замок, а поставити біля дверей охоронця, який впізнає грабіжників в обличчя за старими фотографіями.
Стаття довга. Пропонуємо зробити паузу та ознайомитися з найкращими українськими хостинг-провайдерами з нашого рейтингу. На кожного з них є детальний аналіз: як проводилося тестування, як справи з аптаймом, швидкістю та підтримкою, які сильні та слабкі сторони. Загляньте в огляди тих, хто вас цікавить, прочитайте відгуки клієнтів.
Як виглядає сама закладка
Далі починається друга частина – те, заради чого все й затівалося. Одноразове виконання коду мало що дає: перезавантажили сайт – і доступ зник. Тому зловмисник насамперед встановлює бекдор – файл, який постійно перебуватиме на сайті й пропускатиме господаря назад.
Улюблене місце для такого файлу – папка mu-plugins (must-use plugins). Це плагіни, які WordPress завантажує автоматично при кожному запиті, їх не видно у звичайному списку плагінів в адмінці й неможливо вимкнути кнопкою. Для бекдору це ідеальне місце: працює завжди, не кидається в очі. Сам файл зазвичай маскується під щось системне – якийсь «auto-updates» або «cache-loader», щоб при побіжному погляді не викликати підозр.
Всередині такі бекдори найчастіше влаштовані хитріше, ніж просто «шматок шкідливого коду». Справжніх команд у файлі немає – нерідко подібні бекдори взагалі не містять основного шкідливого коду, а завантажують його. Сенс у тому, що вміст можна змінювати на стороні зловмисника, не зачіпаючи ваш сайт: сьогодні файл розсилає спам, завтра краде дані з форми, післязавтра намагається дістатися до сусідніх сайтів – а на вашому диску весь цей час лежить один і той самий, на вигляд нешкідливий, файл. Часто такий шел ще й захищений паролем та додає заголовок, щоб сторінка не потрапила у пошукову видачу. Акуратна робота, нічого не скажеш.
Що з цього випливає на практиці: шукати злом за «дивним кодом у темі» – заняття майже марне. Коду команд там може не бути взагалі.
Як уникнути цього: профілактика без ілюзій
Про оновлення я вже говорив, повторюватися не буду – це фундамент, і без нього решта не має сенсу. Поговоримо краще про те, що зазвичай залишається за кадром.
Перше – резервні копії, і тут є пастка, в яку потрапляють постійно. Бек-ап рятує від втрати даних, але сам по собі не захищає від злому, а іноді й шкодить. Якщо копію зроблено вже після того, як встановили закладку, у ній містяться і сайт, і бекдор, і зловмисний адміністратор. Відновилися з такої копії – і переінфікували себе одним натисканням. Звучить безглуздо, але саме так люди вдруге повертають на сайт те, що щойно вичистили. Тому копій має бути кілька, за різні дати, і треба розуміти, яка з них завідомо чиста. Тему резервного копіювання ми розглядали детально – що бекап насправді вміє, а чого не вміє.
Друге – про сусідів по обліковому запису. На віртуальному хостингу в одному обліковому записі нерідко розміщується кілька сайтів, і якщо зламали один, дістатися до решти зазвичай неважко – вони лежать поруч у файловій системі, під тим самим користувачем. Провайдери саме для цього й забезпечують ізоляцію облікових записів один від одного (той самий CloudLinux), але всередині одного облікового запису ця ізоляція не працює – вона стосується сусідів по серверу, а не ваших власних сайтів між собою. Тож якщо у вашому обліковому записі п’ять сайтів, а оновлено лише один, – вважайте, що вразливі всі п’ять.
По-третє, і про це говорять найрідше, – вибір самого хостингу. Нормальний провайдер не сидить склавши руки, коли з’являється діра такого калібру: він впроваджує правила на своєму брандмауері, а іноді й сам ініціює оновлення для всіх клієнтів, щоб захистити тих, до кого автооновлення не дійшло. Це не те, що видно в тарифі, але саме це відрізняє хостинг, з яким ви переживете поганий день, від хостингу, де ви дізнаєтеся про злом від Google. Як ми взагалі оцінюємо провайдерів і чому не можна вірити цифрам на вітрині – розписано в нашій методології рейтингу.
Якщо вже зламали: що робити по порядку
Тепер найважливіше: що робити, якщо біда вже сталася. Тут критичним є саме порядок, тому що більшість людей роблять усе правильно, але не в тій послідовності, і тому програють гонку.
Оновлення WP
Почніть з дверей, а не з прибирання. Насамперед переконайтеся, що WordPress оновлено до виправленої версії з таблиці вище. Поки вразливість відкрита, будь-яке очищення не має сенсу: ви видаляєте фейкового адміністратора, а через п’ять хвилин скрипт заходить знову і створює нового. Я багато разів бачив, як людина по колу видаляє одних і тих самих користувачів і не розуміє, чому вони повертаються, – а вони повертаються тому, що вхід все ще відкритий. Спочатку патч.
Зміна паролів
Далі – змініть усі секрети (УСІ!!!), а не лише свій пароль. Оскільки зловмисник мав можливість виконати код, він міг прочитати wp-config.php у повному обсязі, а там у відкритому тексті лежать дані доступу до бази даних і секретні ключі-«солі». Тому змінюємо: паролі всіх користувачів сайту (не тільки адміністраторів), солі в конфігурації через офіційний генератор – це заодно виведе з системи всі активні сесії, включаючи сесію зломщика, якщо вона десь залишилася, – пароль бази даних, пароль від панелі хостингу, усі FTP-доступи та будь-які API-ключі, які зберігалися в цьому WordPress.
Аналіз логів
Поки змінюєте доступи, загляньте в журнали – це той крок, який найчастіше пропускають, а даремно. Журнали веб-сервера access.log та error.log, а також журнали панелі хостингу, показують те, чого не видно в самому WordPress: коли саме сталося зараження, який URL для цього використовували, з яких IP надходили запити і – найважливіше на майбутнє – чи не тривають спроби експлуатації прямо зараз. Скажу чесно: вирішальні запити таких атак часто ховаються в тілі POST і в логах відображаються ускороченому вигляді, тож журнал не завжди дає повну картину. Але навіть часткова картина допомагає: якщо після виправлення ви бачите, що перебір уразливої адреси триває, – значить, дірку закрили вчасно і вас тепер просто безуспішно прощупують, а не зламують знову.
Перевірка файлів
Лише тепер шукаємо й видаляємо сам бекдор. Насамперед – папка mu-plugins: там не повинно бути нічого, крім ваших власних must-use плагінів, усе незнайоме – під підозрою. Загляньте в wp-config.php та у файл .htaccess: там іноді прописують рядок, який підключає шкідливий файл до кожного запиту (директива з назвою на кшталт auto_prepend_file); якщо її знайдете – перевірте, на який файл вона веде. Про те, як .htaccess взагалі керується обробка запитів, у нас є окрема стаття. Заодно перевірте папку завантажень: PHP-файлів у wp-content/uploads не повинно бути в принципі, будь-який такий файл – майже напевно шелл. До речі, багато хостингів за замовчуванням взагалі забороняють виконання PHP у папці завантажень – знають, чим це закінчується.
Окремо варто зазирнути в базу даних: чи не з’явилися адміністратори, яких ви не створювали, дивні записи в блозі, завдання в планувальнику WordPress, які могли б відтворити видалений бекдор. Чиста база – хороша ознака, але не гарантія: закладку могли заховати й у файлах.
Перевірка ядра системи
Коли бекдор видалено, варто перевірити цілісність самого ядра. У WordPress є механізм звіряння: він порівнює всі файли ядра та плагінів з офіційного каталогу з еталоном і показує будь-який змінений або зайвий файл. Якщо у вас є доступ до терміналу – це команди wp core verify-checksums та wp plugin verify-checksums. Якщо терміналу немає, є спосіб грубіший, але дієвий: завантажити з wordpress.org чистий архів саме вашої версії та замінити на сайті лише папки ядра (wp-admin та wp-includes), не зачіпаючи wp-content і wp-config.php. Це перезапише будь-який підмінений файл ядра оригіналом.
І останнє рішення, яке чесніше прийняти відразу. Якщо ви знайшли бекдор, вичистили його і перевірка цілісності нічого не повідомляє – у більшості випадків цього достатньо. Але якщо атака була масштабною, якщо ви бачили не одну закладку, а десяток підроблених облікових записів адміністраторів і купу сміттєвих записів, – гарантувати, що ви очистили все, на активному сайті неможливо. RCE надає занадто багато можливостей, щоб бути впевненим на сто відсотків. Най надійніший шлях у такому випадку – перекомпіляція: чиста інсталяція ядра та плагінів з офіційних джерел, а зі старого сайту переноситься лише перевірений контент бази та медіафайли. Це забирає більше часу, але це єдиний варіант, після якого можна спати спокійно. Тут усе залежить від того, наскільки сайт для вас важливий і наскільки глибоко в нього зазіхнули.
Короткий висновок
Практично всі злами такого роду – це не про геніальних хакерів і не про поганий хостинг. Це про пропущене оновлення та про автоапдейт, який мовчки не спрацював, про що власник дізнався занадто пізно. Двері відкриває вчасно не оновлений WordPress, а шелл у mu-plugins – це вже наслідок. Хороша новина в тому, що й захист, і лікування зводиться до однієї й тієї ж простої дії, яку чомусь роблять в останню чергу: перевірити на власні очі, яка версія встановлена, і підтримувати її в актуальному стані. Усе інше – це лише допоміжні заходи навколо цього.
Джерела
- WordPress – оновлення ядра (офіційна документація)
- WP-CLI – команда core verify-checksums (перевірка цілісності файлів)
- NVD – CVE-2026-63030 (плутанина маршрутів REST API batch)
- NVD – CVE-2026-60137 (SQL-ін’єкція в WP_Query)
- CISA – каталог активно експлуатованих вразливостей (KEV)
- VulnCheck – технічний аналіз ланцюжка wp2shell
FAQ щодо вразливостей
Як зрозуміти, що мій сайт на WordPress зламали?
Тривожні ознаки: незнайомий адміністратор у списку користувачів, лист про зміну пароля, якого ви не запитували, чужі записи в блозі, дефейс або перенаправлення на сторонні сайти. Часто зовні все виглядає нормально, а закладка тихо сидить у файлах. Най надійніший спосіб переконатися – перевірити версію WordPress і зазирнути в папку mu-plugins на наявність незнайомих файлів.
Що таке wp2shell простими словами?
Це поєднання двох помилок у ядрі WordPress, яке разом дає анонімній особі з Інтернету можливість виконати код на вашому сервері – без пароля, без входу, на стандартній установці навіть без плагінів. Уразливість було усунуто 17 липня 2026 року. Якщо у вас встановлено виправлену версію, через цю дірку до вас уже не зможуть проникнути.
Які версії WordPress вразливі, а в яких виправлення вже внесено?
Повністю вразливі гілки 6.9.0–6.9.4 та 7.0.0–7.0.1; виправлено у версіях 6.9.5 та 7.0.2 відповідно. Гілка 6.8.0–6.8.5 уражена частково (лише SQL-ін’єкцією) і виправлена у версії 6.8.6. Усі версії, старші за 6.8, не уражені цією проблемою.
У мене ввімкнено автооновлення – я в безпеці?
Не обов’язково. Примусове оновлення може не спрацювати непомітно, якщо оновлення вимкнені у файлі wp-config.php, якщо сайт розгорнуто з системи контролю версій, якщо на файли встановлено занадто суворі права доступу або якщо трафік сайту дуже малий. Помилка при цьому непомітна, тому перевіряти треба на власні очі: консоль, розділ «Оновлення», номер версії.
Що таке веб-шелл і бекдор?
Це файл, який зловмисник залишає на сайті після злому, щоб повернутися в будь-який момент – навіть після того, як початкову вразливість закриють. Часто він не містить шкідливого коду безпосередньо, а завантажує його з чужого сервера і виконує через eval. Через це вміст можна змінювати на стороні зломщика, не зачіпаючи ваш сайт.
Чому бекдор ховають саме в mu-plugins?
Папка mu-plugins (must-use plugins) завантажується WordPress автоматично при кожному запиті. Такі плагіни не видно у звичайному списку в адмінці й їх неможливо вимкнути за допомогою кнопки. Для бекдору це ідеальне місце: працює завжди і не кидається в очі, часто маскується під системний файл на кшталт auto-updates.
Що робити в першу чергу, якщо сайт уже зламали?
Спочатку закрити дірку – оновити WordPress до виправленої версії. Поки вхід відкритий, чистити марно: віддалений адміністратор повернеться за кілька хвилин. Тільки після виправлення змінюйте паролі та видаляйте закладку. Порядок тут важливіший за швидкість.
Які паролі та ключі слід змінити після злому?
Усі, а не лише свій. Оскільки зловмисник мав можливість виконувати код, він міг прочитати файл wp-config.php із даними доступу до бази даних та солями. Змінюйте паролі всіх користувачів, солі в конфігураційному файлі, пароль бази даних, пароль панелі хостингу, усі FTP-доступи та API-ключі. Зміна солей одночасно виведе з системи всі активні сесії.
Як знайти та видалити закладку?
Почніть з папки mu-plugins – там не повинно бути нічого, крім ваших файлів. Перевірте wp-config.php і .htaccess на наявність рядка auto_prepend_file, що веде до стороннього файлу, та папку wp-content/uploads – PHP-файлів там бути не повинно. Загляньте в базу даних: чи немає там сторонніх адміністраторів та завдань у планувальнику, які могли б відтворити бекдор.
Чи достатньо просто видалити бекдор, чи потрібно перекомпілювати сайт?
Якщо бекдор знайдено, видалено, а перевірка цілісності ядра не виявляє порушень, у більшості випадків цього достатньо. Але під час інтенсивної атаки – з десятком сторонніх адміністраторів і безліччю сміттєвих записів – гарантувати повну чистоту на активному сайті неможливо. Тоді надійніше перекомпілювати: чисте ядро та плагіни з офіційних джерел, а зі старого сайту – лише перевірений контент.
Чи врятує мене резервна копія?
Резервна копія захищає від втрати даних, але не від злому, а іноді й шкодить. Якщо копія зроблена вже після появи закладки, відновлення з неї поверне і бекдор, і фальшивого адміністратора. Зберігайте кілька копій за різні дати й знайте, яка з них завідомо чиста – тобто створена до моменту злому.