Коли сайти на WordPress зазнають зламів, власники бізнесу зазвичай припускають, що зловмисники знайшли вразливість у самому ядрі платформи. Статистика інцидентів кібербезпеки свідчить про інше. За даними міжнародного реєстру вразливостей CVE Mitre та звітів аналітиків, понад 90% успішних атак відбуваються через застарілі або недбало написані плагіни та теми. Сама платформа WordPress оновлюється автоматично, тоді як десятки сторонніх модулів місяцями залишаються без уваги адміністратора. Вразливий плагін перетворює корпоративний сайт або інтернет-магазин на інструмент розсилки спаму, встановлення прихованих майнерів або викрадення платіжних даних клієнтів. Нижче наведено інженерне керівництво з аудиту безпеки плагінів WordPress за допомогою сканера WPScan, розбору типів атак згідно зі стандартами OWASP та автоматизації перевірки в репозиторіях CI/CD перед деплоєм на продакшн.

Анатомія вразливостей сторонніх плагінів

Спільнота WordPress нараховує десятки тисяч безкоштовних і комерційних плагінів. Багато з них розробляються авторами без належного аудиту коду на безпеку. Згідно з класифікацією OWASP Top 10, найбільш поширеними векторами проникнення через плагіни є чотири класи атак:

SQL-ін'єкції (SQLi). Виникають, коли розробник підставляє параметри з форми або URL безпосередньо в запит до бази даних без екранування через метод $wpdb->prepare(). Зловмисник передає модифікований payload і отримує повний дамп таблиці користувачів разом із хешами паролів адміністраторів.
Неавторизований збережений XSS (Stored Cross-Site Scripting). Помилка обробки вхідних даних у формах зворотного зв'язку або відгуків. Шкідливий JavaScript-код записується в базу даних. Коли адміністратор відкриває панель управління для перегляду повідомлення, скрипт непомітно створює новий акаунт із правами суперкористувача.
Несанкціоноване підвищення привілеїв (Privilege Escalation). Помилки у функціях обробки AJAX або кінцевих точках REST API. Якщо розробник забув перевірити права поточного користувача через current_user_can() або пропустив валідацію nonce-токенів, будь-який відвідувач може надіслати запит і змінити налаштування сайту.
Довільне завантаження файлів (Arbitrary File Upload). Відсутність суворої перевірки розширення файлу в модулях імпорту чи завантаження аватарів дозволяє завантажити файл із розширенням .phtml або .php5, отримавши веб-шелл для повного контролю над сервером.

Як працює сканер WPScan

Для швидкого виявлення відомих дефектів безпеки в екосистемі WordPress інженери застосовують спеціалізований інструмент WPScan. Це сканер вразливостей з відкритим вихідним кодом, який підтримується командою фахівців та спирається на базу даних WordPress Vulnerability Database.

Сканер виконує зовнішнє або внутрішнє дослідження цільового вузла за наступним алгоритмом:

Визначає точну версію ядра WordPress за допомогою генератора метатегів, хешів файлів стилів та скриптів.
Сканує список встановлених плагінів шляхом опитування статичних файлів readme.txt, вивчення заголовків відповідей веб-сервера та аналізу вихідного коду HTML.
Звіряє назви та версії знайдених плагінів із базою розкритих CVE.
Формує структурований звіт із переліком знайдених вразливостей, їхніми ідентифікаторами CVE, посиланнями на експлойти та версіями плагінів, де проблему виправлено розробником.

Запуск перевірки через консоль та Docker

Для запуску сканування найзручніше використовувати офіційний Docker-образ WPScan. Це позбавляє необхідності налаштовувати оточення Ruby та залежності на сервері. Для повноцінного вивантаження інформації про вразливості потрібен безкоштовний API-токен із сайту розробників сканера.

Нижче наведено команду для агресивного виявлення встановлених плагінів зі збереженням результату у форматі JSON:

docker run --rm -it wpscanteam/wpscan \
  --url https://staging.example.com \
  --enumerate p \
  --plugins-detection aggressive \
  --api-token "YOUR_WPSCAN_API_TOKEN" \
  --format json \
  --output /tmp/wpscan_report.json

Параметр plugins-detection aggressive змушує сканер перевіряти наявність популярних плагінів за словником запитів, навіть якщо плагін не підключає власні скрипти на головній сторінці сайту. Це дозволяє знаходити приховані або відключені адміністратором плагіни, які все ще залишаються фізично присутніми у файловій системі сервера і можуть бути використані зловмисниками.

Автоматизація аудиту в CI/CD пайплайнах

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

Нижче наведено конфігурацію завдання для GitHub Actions, яке розгортає staging-версію, запускає сканування WPScan та передає звіт на валідацію власному скрипту контролю якості:

name: Security Audit WPScan

on:
  push:
    branches: [ main, staging ]
  schedule:
    - cron: '0 3 * * *'

jobs:
  wpscan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Run WPScan Docker
        run: |
          docker run --rm \
            -v ${{ github.workspace }}:/output \
            wpscanteam/wpscan \
            --url https://staging.example.com \
            --enumerate p \
            --plugins-detection aggressive \
            --api-token ${{ secrets.WPSCAN_API_TOKEN }} \
            --format json \
            --output /output/wpscan_results.json || true

      - name: Analyze Vulnerabilities with Python
        run: |
          python scripts/analyze_wpscan.py wpscan_results.json

Зверніть увагу на прапорець true після запуску Docker. Він дозволяє зберегти JSON-файл зі звітом навіть тоді, коли WPScan повертає ненульовий код виходу при виявленні небезпек.

Скрипт аналізу звітів за шкалою CVSS

Не всі знайдені зауваження є критичними. Щоб пайплайн не зупинявся через дрібні інформаційні попередження, розробники використовують фільтрацію за шкалою CVSS (Common Vulnerability Scoring System). Скрипт на Python перевіряє рівень загрози кожного плагіна і блокує деплой лише за наявності серйозних ризиків:

import json
import sys
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("WPScanValidator")

def evaluate_report(file_path: str, max_cvss_threshold: float = 7.0):
    with open(file_path, "r", encoding="utf-8") as f:
        data = json.load(f)

    plugins = data.get("plugins", {})
    critical_findings = []

    for slug, info in plugins.items():
        plugin_name = info.get("name", slug)
        vulnerabilities = info.get("vulnerabilities", [])

        for vuln in vulnerabilities:
            title = vuln.get("title", "Unknown issue")
            cvss = vuln.get("cvss", {})
            score = float(cvss.get("score", 0.0)) if cvss else 0.0

            logger.info("Found issue in %s: %s (CVSS: %.1f)", plugin_name, title, score)

            if score >= max_cvss_threshold:
                critical_findings.append({
                    "plugin": plugin_name,
                    "title": title,
                    "cvss": score,
                    "fixed_in": vuln.get("fixed_in", "No fix available"),
                })

    if critical_findings:
        logger.error("Security Gate Failed. Critical vulnerabilities found:")
        for item in critical_findings:
            logger.error("-> %s | CVSS: %.1f | Fixed in: %s", item["plugin"], item["cvss"], item["fixed_in"])
        sys.exit(1)

    logger.info("Security Gate Passed. No critical issues detected.")

if __name__ == "__main__":
    report_file = sys.argv[1] if len(sys.argv) > 1 else "wpscan_results.json"
    evaluate_report(report_file)

Якщо плагін містить уразливість із балом 7.0 і вище (рівень High або Critical), скрипт завершує роботу з кодом 1. Деплой на бойовий сервер негайно блокується, а розробники отримують сповіщення з точним номером версії, на яку слід оновитися. Про правила написання безпечних розширень читайте в офіційному посібнику WordPress Plugin Security.

Харднінг файлової системи та налаштувань сервера

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

Заборона модифікації файлів через веб-інтерфейс. У конфігураційному файлі wp-config.php прописують директиви define('DISALLOW_FILE_EDIT', true); та define('DISALLOW_FILE_MODS', true);. Навіть якщо зловмисник отримає доступ до кабінету адміністратора, він не зможе вставити шкідливий код у редакторі тем чи встановити сторонній архів.
Суворі права доступу Linux. Усі директорії сайту повинні мати права 755, а файли 644. Конфігураційний файл wp-config.php повинен мати права 600 або 400 і належати користувачу веб-сервера без права запису для сторонніх груп.
Блокування виконання PHP у папці uploads. Каталог wp-content/uploads призначений виключно для зображень та документів. У конфігурації Nginx забороняють обробку PHP-скриптів у цій папці, унеможливлюючи запуск завантажених бекдорів.
Захист від сканування авторів через REST API. Кінцева точка /wp-json/wp/v2/users за замовчуванням віддає логіни всіх зареєстрованих користувачів. Доступ до цього маршруту слід обмежити лише для авторизованих редакторів.

Якщо інтернет-магазин працює на базі WooCommerce, збереження конверсії вимагає суміщення суворої безпеки зі швидкістю чекауту. Як організувати надійне відстеження конверсій під час оплати, читайте у статті про воронку чекауту WooCommerce.

Порівняння підходів до аудиту безпеки

У таблиці нижче зібрано основні методи аудиту та контролю вразливостей для сайтів на WordPress:

Підхід до перевірки	Частота запуску	Навантаження на сервер	Виявлення 0-day загроз	Точність визначення CVE	Вплив на швидкість сторінок
Плагіни безпеки (Wordfence, iThemes)	Постійно в рантаймі	Високе (сповільнює PHP)	Висока (сигнатурний аналіз)	Середня	Збільшує час TTFB на 100-300 мс
Зовнішній WPScan за розкладом	Щодня через cron	Мінімальне (короткий тест)	Повна база CVE	Абсолютна	Нульовий вплив на користувачів
Статичний аналіз коду в CI/CD	При кожному коміті	Нульове для сайту	Виявляє дефекти коду	Попередня оцінка	Нульовий
Комбінований WAF + CI/CD аудит	Безперервно	Мінімальне (хмарний фільтр)	Максимальний захист	Повна відповідність CVE	Нульовий завдяки кешуванню

Типові помилки адміністрування безпеки

Збереження неактивних плагінів на диску сервера. Навіть якщо плагін деактивовано в панелі WordPress, його файли залишаються доступними за прямими посиланнями. Зловмисник може звернутися до вразливого PHP-файлу безпосередньо через браузер і виконати атаку.
Використання плагінів, покинутих розробниками. Якщо плагін не оновлювався понад рік, він не тестувався на нових версіях PHP 8.2 або 8.4 і містить розкриті вразливості, які ніхто не виправлятиме.
Ігнорування версіонування конфігурацій. Зміни в налаштуваннях безпеки повинні фіксуватися в Git, а не вноситися вручну на живому сервері через файловий менеджер хостингу.
Відсутність ізольованих резервних копій. Резервні копії, збережені в сусідній папці того самого сервера, видаляються або шифруються зловмисником у перші секунди після зламу. Бекапи мають автоматично вивантажуватися на віддалене хмарне сховище S3.

Часті запитання

Чи безпечно використовувати безкоштовні плагіни з офіційного каталогу WordPress?

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

Що робити, якщо WPScan знайшов вразливість, для якої немає оновлення?

Якщо розробник припинив підтримку модуля, його слід негайно замінити на безпечний аналог або відключити. Тимчасовим захистом може слугувати віртуальний патч у хмарному фаєрволі Cloudflare чи ModSecurity, який блокує конкретні підозрілі запити до вразливого файлу.

Як часто оновлюється база вразливостей WPScan?

База даних оновлюється щодня на основі повідомлень дослідників кібербезпеки та публікацій у реєстрах CVE. Використання свіжого API-токена гарантує актуальність інформації про виявлені ризики.

Чи створює сканування WPScan загрозу для доступності сайту?

При стандартних налаштуваннях сканер генерує помірну кількість HTTP-запитів і не перевантажує продуктивні сервери. Для додаткової обережності аудит проводять на staging-копіях або під час нічного мінімуму відвідуваності.

Захистимо ваш сайт від цифрових загроз

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

Актуальні тарифи представлені на сторінці цін на послуги. У нашому прайсі корпоративний сайт на WordPress коштує від $500, повноцінний інтернет-магазин від $1,000, щомісячна підтримка сайту від $250, технічний SEO-аудит від $200, розробка кастомного модуля від $80, а автоматизація на n8n від $500. Щоб перевірити захищеність вашого сайту, залиште заявку через форму контактів або напишіть нам напряму в Telegram.

Безпека WordPress: як перевірити плагіни на відомі вразливості через WPScan, CVE та автоматизувати аудит у CI/CD