Зараження WordPress може проявлятися по-різному: сайт перенаправляє відвідувачів на сторонні сторінки, показує рекламу або попередження браузера, надсилає спам, повільно працює чи взагалі перестає відкриватися. Іноді шкідливий код не видно на сторінках, але він створює прихованих користувачів, змінює файли або використовує сайт для розсилок.
Очищення не варто зводити до видалення одного підозрілого фрагмента. Якщо не знайти первинну точку входу та не закрити вразливість, зараження може повторитися. Перед будь-якими змінами зробіть резервну копію файлів і бази даних. Водночас пам’ятайте: копія інфікованого сайту може містити шкідливий код, тому її потрібно зберегти окремо й не використовувати без перевірки.
Якщо немає впевненості, які файли можна видаляти, краще звернутися до фахівця з послугою Видалення вірусів із сайту WordPress. Некоректне очищення може пошкодити сайт або призвести до втрати даних.
Пошук змінених файлів
Перший етап — визначити масштаб зараження. Окремий підозрілий файл не завжди є єдиною проблемою: зловмисник міг залишити декілька резервних копій шкідливого коду, створити прихований скрипт або змінити налаштування WordPress.
- Перевірте дату зміни файлів і зверніть увагу на ті, що з’явилися або були змінені безпосередньо перед виникненням проблеми.
- Порівняйте файли ядра WordPress із чистою версією тієї самої редакції. Особливо уважно перевірте
index.php,wp-config.php, файли в каталозіwp-adminіwp-includes. - Огляньте каталог
wp-content/uploads. PHP-файли в ньому часто є підозрілими, оскільки цей каталог зазвичай призначений для медіа. - Перевірте приховані файли, зокрема
.htaccess, а також конфігурації, що можуть виконувати перенаправлення або блокувати доступ. - Проаналізуйте журнали хостингу: помилки вебсервера, авторизації в адмінпанелі, FTP/SSH і запити до незвичних файлів.
Не видаляйте файли лише через незрозумілу назву або незвичний код. WordPress, тема чи плагін можуть містити складні конструкції, які виглядають підозріло для неспеціаліста. Надійніше порівнювати їх із дистрибутивом, отриманим з офіційного джерела, або доручити перевірку спеціалісту.
Очищення ядра, тем і плагінів
Найбезпечніший підхід до ядра WordPress — не редагувати кожен файл вручну, а замінити його чистою копією тієї самої версії. Перед цим потрібно переконатися, що резервна копія збережена, а файл wp-config.php та каталог із завантаженнями не будуть випадково перезаписані.
- Тимчасово обмежте доступ до сайту або переведіть його в режим технічного обслуговування, якщо це можливо без втрати доступу до діагностики.
- Замініть файли ядра на чисті файли з офіційного дистрибутива WordPress.
- Видаліть невикористовувані теми та плагіни, особливо отримані з неперевірених джерел.
- Активні компоненти встановіть заново з офіційних репозиторіїв або сайтів розробників.
- Перевірте код активної теми, дочірньої теми та файли, які можуть підключатися через налаштування або власні вставки.
Не варто просто оновлювати заражений плагін поверх старої версії: шкідливий код може залишитися в іншому файлі або в базі даних. Також оновлення не замінює перевірку користувачів, ключів доступу та серверних налаштувань.
Якщо після очищення сайт не запускається, з’явилися помилки 500, білий екран або проблеми з функціональністю, не видаляйте файли навмання. Спочатку перевірте журнали помилок і за потреби відновіть робочу копію на окремому середовищі для порівняння.
Перевірка бази даних
Шкідливий код може зберігатися не лише у файлах. У базі даних часто перевіряють записи з налаштуваннями, текстами віджетів, користувацькими полями та вмістом публікацій. Небезпечні фрагменти можуть бути вставлені в заголовок сайту, поля JavaScript, меню, віджети або описи плагінів.
- Зробіть окрему резервну копію бази даних перед редагуванням.
- Перевірте таблиці налаштувань і записи, де можуть міститися HTML, JavaScript або закодовані рядки.
- Огляньте список користувачів WordPress і видаліть невідомі облікові записи після підтвердження, що вони не належать власнику сайту чи команді.
- Перевірте заплановані завдання, підозрілі опції та незвичні зміни в контенті.
- Порівняйте важливі налаштування з відомою чистою копією, якщо вона доступна.
Редагування бази даних без розуміння структури WordPress небезпечне. Одна помилка в SQL-запиті може пошкодити контент, налаштування або зв’язки між таблицями. Масову заміну шкідливих фрагментів потрібно виконувати лише після резервного копіювання та з урахуванням кодування даних, зокрема серіалізованих значень.
Закриття вразливості
Після очищення потрібно встановити причину зараження. Найчастіші варіанти — застарілий плагін або тема, слабкий пароль, скомпрометований FTP чи хостинг-акаунт, небезпечні права доступу, вразливість у власному коді або використання неліцензійного компонента.
- Оновіть WordPress, теми, плагіни та версію PHP до сумісних актуальних версій.
- Змініть паролі адміністратора, хостингу, FTP/SSH, бази даних і поштових скриньок, пов’язаних із сайтом.
- Завершіть активні сесії користувачів і перевірте права адміністраторів.
- Видаліть непотрібні облікові записи, ключі доступу, старі архіви та тестові файли з сервера.
- Перевірте права на файли й каталоги та забороніть виконання скриптів у каталогах для завантажень, якщо це підтримує конфігурація сервера.
- Увімкніть двофакторну автентифікацію, захист адмінпанелі та регулярне сканування.
Якщо зловмисник мав доступ до хостингу, одного скидання пароля WordPress недостатньо. Потрібно перевірити панель керування сервером, SSH-ключі, FTP-користувачів, cron-завдання та журнали входів. Частину серверних змін може виконати лише хостинг-провайдер або системний адміністратор.
Моніторинг після очищення
Очищення потрібно вважати завершеним не в момент, коли сайт знову відкривається, а після контрольного періоду без повторних ознак зараження. Працездатність сайту сама по собі не доводить, що всі шкідливі файли видалені.
- Регулярно перевіряйте файли на несанкціоновані зміни.
- Контролюйте нових користувачів, невідомі плагіни, перенаправлення та зміни в контенті.
- Переглядайте журнали сервера й повідомлення систем безпеки.
- Налаштуйте резервне копіювання за розкладом і зберігайте декілька копій у місцях, недоступних із самого сайту.
- Періодично перевіряйте відновлення з резервної копії, оскільки пошкоджений або неповний архів не допоможе під час аварії.
Звернутися до спеціаліста варто, якщо зараження повторюється, сайт внесений до чорних списків, немає доступу до хостингу чи бази даних, пошкоджені файли ядра або незрозуміло, які дані можна вважати чистими. У таких ситуаціях спроби швидкого ручного очищення можуть ускладнити подальшу діагностику та збільшити ризик втрати даних.