Кейс: як ми прибрали шкідливий редирект WordPress (LiteSpeed Cache)

Сайт заміського комплексу відпочинку на WordPress перенаправляв відвідувачів на сторонні сайти, зокрема з контентом для дорослих, але лише тих, хто заходив зі смартфона, через мобільний інтернет і вперше, без cookies. Власник і розробники бачили нормальний сайт, а Google Ads заблокував рекламний кабінет, і клієнт втратив гроші на рекламі. Причиною виявилася стара зламана (nulled) копія плагіна кешування LiteSpeed Cache з відомою вразливістю. Ми знайшли код у двох файлах із 32 000, вичистили сайт і закрили дірку, а згодом клієнт переїхав на нашу систему керування Atom.

Що бачив клієнт

Звичайний сайт: адмінка працює, сторінки відкриваються, у самого власника жодних редиректів. Водночас Google Ads заблокував рекламний кабінет. Реклама зупинилася, а бюджет, витрачений на кліки, які вели на шкідливий сайт, повернути не можна.

Найскладніше було відтворити проблему. З комп’ютера, з Wi-Fi, з телефона, на якому сайт уже відкривали, редиректу не було. Він спрацьовував лише за трьох умов одночасно:

• мобільний пристрій;
• мобільний інтернет, а не Wi-Fi;
• перший візит без cookies, тобто новий відвідувач.

Так шкідливий код ховається навмисно: власник сайту, адміністратор і розробник майже завжди заходять зі збережених сесій і з офісного Wi-Fi, тому нічого не бачать. А новий покупець із реклами на смартфоні якраз і потрапляє під редирект.

Як ми знайшли шкідливий код

Коли стало зрозуміло, кого саме перенаправляє сайт, ми перейшли від перевірки в браузері до перевірки сервера:

1. Визначили дату зламу. Зловмисники отримали доступ приблизно 20 квітня 2024 року.
2. Порівняли файли з бекапом. На старому сервері збереглася резервна копія за 15 квітня, тобто ще до зламу. Ми відкотили сайт на неї і порівняли всі 32 000 файлів зі зламаною версією.
3. Знайшли різницю в двох файлах. Шкідливий код був дописаний у functions.php теми сайту і на самий початок системного wp-includes/js/jquery/jquery-migrate.min.js. Цей скрипт WordPress підключає майже на кожній сторінці, тому код виконувався всюди.
4. Перевірили користувачів. В адмінці з’явився другий адміністратор wp-configuser, якого ніхто не створював.

Підказкою стала перевірка нещодавно змінених файлів. Але вона спрацювала лише тоді, коли ми вже розуміли, що шукаємо: на сайті з десятками тисяч файлів «щось змінилося» знаходить сотні збігів.

Звідки взявся злам

На сайті стояв LiteSpeed Cache, популярний плагін кешування з понад 5 мільйонами встановлень. Це не підозрілий плагін, а нормальний продукт. Проблема в тому, що на сайті стояла зламана копія (nulled), завантажена зі стороннього сайту, тож вона ніколи не оновлювалася.

У версіях LiteSpeed Cache до 5.7.0.1 була вразливість CVE-2023-40000. Вона дозволяла без авторизації вставити JavaScript у сторінки адмінки. Розробники виправили її в жовтні 2023 року, а навесні 2024-го почалася масова атака на сайти, які не оновилися: скрипт створював нового адміністратора (саме wp-configuser або wpsupp-user) і дописував шкідливий код у файли сайту. Про цю кампанію в травні 2024 року писали дослідники WPScan.

Тобто сайт зламали не через WordPress як такий і не через LiteSpeed Cache, а через те, що копія плагіна була піратською і застрягла на старій версії. Офіційна версія плагіна отримала виправлення ще за пів року до атаки.

Чому Google Ads блокує за таке

Google перевіряє не лише оголошення, а й сайт, на який вони ведуть. Сторінка, що перенаправляє відвідувачів на сторонні сайти через зламаний код, підпадає під правила Google Ads про зловживання рекламною мережею. Для власника сайту це виглядає несправедливо, адже він сам постраждав. Але для Google це сайт, який шкодить користувачам, і поки код на місці, реклама не працюватиме.

Те саме стосується пошуку: прихований редирект, який показує людям інше, ніж бачить Google, — це порушення правил Google щодо спаму, а зламані сайти Google позначає в звіті «Проблеми безпеки» в Search Console.

Що ми зробили

• Відновили сайт із чистого бекапу і перенесли його на новий сервер.
• Видалили шкідливий код і стороннього адміністратора.
• Прибрали nulled-плагіни. Під час перевірки ми знайшли ще 18 місць у плагінах, які могли слугувати бекдорами (прихованим входом для повторного зламу).
• Додали захист від повторного зламу і передали клієнту звіт про виконані роботи.

Чому клієнт переїхав з WordPress

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

Протягом місяця клієнт вирішив переїхати на нашу систему керування Atom: одна оплата за розробку, без сторонніх плагінів і без ліцензій, які треба продовжувати. Ми розробили новий сайт під ключ, результат є в портфоліо.

Станом на листопад 2026 року клієнт на постійному обслуговуванні. Зараз ми розробляємо для нього CRM-систему під ключ і готуємо сайт до старту SEO-просування.

Як перевірити, чи ваш сайт не зламаний

• Відкрийте сайт так, як новий покупець: зі смартфона, через мобільний інтернет, у режимі інкогніто. Перевірка з робочого комп’ютера нічого не покаже.
• Перегляньте список адміністраторів в адмінці. Незнайомий акаунт — точна ознака зламу.
• Перевірте звіт «Проблеми безпеки» в Google Search Console і статус сайту в Google Safe Browsing.
• Не ставте nulled-теми і плагіни. Їх не можна оновити, а частина вже містить бекдори з коробки.
• Тримайте бекапи поза основним сервером. У цьому кейсі саме копія на старому сервері дозволила точно знайти змінені файли.

Якщо реклама раптом відхилена через «зламаний сайт» або клієнти скаржаться на дивні переходи, напишіть нам. Розслідування і чистку ми робимо в межах обслуговування сайтів.