Podatności SSRF w popularnych wtyczkach WordPress — co zrobiliśmy u klienta

SSRF — Server-Side Request Forgery — to klasa podatności, w której atakujący zmusza Twój serwer do wykonania requestu HTTP do wybranego przez siebie URL. Brzmi niewinnie, aż do momentu gdy ten URL to http://169.254.169.254/latest/meta-data/ (AWS instance metadata, ujawnia klucze dostępowe), http://127.0.0.1:6379/ (lokalny Redis bez hasła), albo wewnętrzny endpoint Twojej sieci.

WordPress przez lata miał kilka głośnych SSRF. Poniżej pięć z 2024-2025, które realnie odnotowaliśmy u klientów — i szczegółowy opis jak zareagowaliśmy na jeden z nich na produkcji.

1. CVE-2024-27956 — WP Automatic Plugin (SQL + SSRF)

WP Automatic (ponad 40 000 aktywnych instalacji) miał endpoint, który fetchował URL użytkownika i parsował go. Bez walidacji hosta — atakujący mógł wskazać metadata AWS, localhost, wewnętrzne IP sieci.

Worse: połączone z SQL injection → pełne RCE. Atakujący mógł:

1. Wysłać request do endpointa z payload’em SSRF
2. Dostać dane z metadata AWS (klucze IAM)
3. Użyć kluczy do dostępu do S3 klienta

Sukces atakowania: masywny. W kwietniu 2024 odnotowano 5 milionów prób exploit’u dziennie (statystyki Patchstack).

Co zrobiliśmy u klienta, który miał WP Automatic:

• Po godzinie od ogłoszenia CVE — update na najnowszą wersję.
• Sprawdzenie logów access.log za ostatnie 30 dni pod kątem prób exploit (szukaliśmy GET /wp-admin/admin-ajax.php?action=csv z długimi query stringami).
• Znaleźliśmy 14 prób, wszystkie z IP już zbanowanych na Cloudflare.
• Fresh WordPress reinstall z backupu sprzed wrażliwych wersji (choć na tym sklepie nie było dowodu kompromitacji).

2. CVE-2024-5035 — TI WooCommerce Wishlist (unauthenticated SSRF)

Wtyczka wishlist z WooCommerce — 100 000 instalacji. Endpoint /wp-admin/admin-ajax.php?action=tinvwl_get_items_from_service bez autoryzacji, fetchował URL z parametru.

Atakujący nie potrzebował konta — tylko POST z service_url=http://localhost:8080/internal-api. WordPress fetchował, odpowiedź wracała jako JSON w response. Pełne information disclosure wewnętrznych serwisów.

U klienta używającego TI Wishlist zrobiliśmy natychmiastowy update. Sprawdzenie logów nie pokazało żadnych prób — wykryliśmy to w pierwszej godzinie od publikacji CVE, zanim skanery zdążyły zacząć.

3. CVE-2024-37484 — WP-Mail-SMTP (SSRF via API endpoint)

WP Mail SMTP (+3 miliony instalacji) ma endpoint do testowania konfiguracji. Parametr smtp_host był fetchowany bez walidacji. Atakujący z uprawnieniami subscriber’a mógł:

POST /wp-admin/admin-ajax.php
Action: wpmailsmtp_ajax_test_connection
Data: smtp_host=169.254.169.254

Response: [Internal server data]

Potrzebowało nie-admina account’u. W sklepach z otwartą rejestracją (every WooCommerce site) — każdy mógł zarejestrować konto i exploitować.

Co robić: update + zmiana kluczy SMTP (bo mogły wyciec przez nieautoryzowany access do konfiguracji).

4. CVE-2024-31282 — LiteSpeed Cache (authenticated SSRF)

LiteSpeed Cache (5 milionów instalacji) miał endpoint lscache_admin_url który walczył z URL manipulation. Authenticated atakujący (nawet z niskimi uprawnieniami) mógł wymusić fetch dowolnego URL przez wtyczkę.

LiteSpeed jest TYPY wtyczki używanej na większości sklepów o które dbamy — critical. Patrzyliśmy na każdy node klienta osobno:

1. Update w < 2h.
2. Sprawdzenie czy wp_options nie zawiera zmodyfikowanych kluczy wtyczki (atakujący mógł ustawić cache URL na endpoint zewnętrzny).
3. Regeneracja salt keys w wp-config.php.

5. CVE-2024-4047 — FluentSMTP (SSRF via callback URL)

FluentSMTP (300 000 instalacji) miał feature „OAuth authorization callback”, który fetchował callback URL bez walidacji. Typowy SSRF z OAuth redirect.

Ciekawostka: ta podatność pozwoliła przypadkowo odkryć niezałatane VPN endpointy na sieci klienta — nasz audyt po CVE znalazł, że 2 lata temu ktoś skonfigurował internal VPN bez IP whitelist, a teraz był odkryty.

Case szczegółowo: jak reagujemy w agencji na krytyczne CVE

W naszym przepływie pracy ma to wyglądać konkretnie tak (dla przykładu WP Automatic wyżej):

Godzina 0: Alert

Patchstack (subskrypcja Enterprise dla agencji) wysyła alert na Slacka agencji. Monitoring Wordfence Premium u klientów również alertuje — ale Patchstack zwykle jest pierwszy (o 1-4 godziny).

Godzina 0-1: Triaż

• Kto jest affected? Odpalamy query: SELECT * FROM wp_options WHERE option_name LIKE 'active_plugins' AND option_value LIKE '%automatic%' na wszystkich instalacjach klientów. W 15 minut mamy listę.
• Severity assessment: Critical (RCE, SSRF, SQLi)? Wchodzimy w emergency mode.

Godzina 1-4: Wdrożenie

Per klient:

• Backup pełny bazy + plików (zawsze).
• Update wtyczki na najnowszą wersję (większość CVE ma już patch gdy ogłoszony).
• Jeśli nie ma patcha (rzadko) — tymczasowe wyłączenie wtyczki + alert do klienta.
• Smoke test — czy sklep działa, czy checkout przechodzi.

Godzina 4–8: Audyt powdrożeniowy

• Przeanalizowanie logów dostępu za ostatnie 30 dni pod kątem prób exploit. Regex match na typowe sygnatury payload’ów.
• Jeśli znaleziono successful exploit — pełny incident response: reinstall WP, rotacja wszystkich kluczy, informacja do klienta + informacja dla organów (jeśli wyciekły dane osobowe — RODO art. 33/34). Szczegóły procedury odzyskiwania zhakowanej strony — tutaj.

Godzina 8-24: Komunikacja

Każdy klient dostaje email z informacją o CVE + co zrobiliśmy + status („strona była podatna przez X dni / nigdy nie była podatna / została skompromitowana / nie została skompromitowana”). Transparentność.

Jak chronić się proactywnie

1. Patchstack + alerty

Wersja darmowa pozwala monitorować do 5 stron. Wersja Enterprise (dla agencji) monitoruje wszystkie strony + integracja z ManageWP / MainWP.

2. Automatyczne mniejsze aktualizacje

W wp-config.php:

define('WP_AUTO_UPDATE_CORE', 'minor');
add_filter('auto_update_plugin', '__return_true');

Minor updates (security) idą automatycznie. Major updates (2.0 → 3.0) dalej manual (mogą mieć breaking changes).

3. WAF — WAS NA POZIOMIE EDGE

Cloudflare Pro ma managed WAF rules dla WordPress. Wordfence Premium ma własny WAF on-server. Oba blokują większość known exploit patterns zanim dotrą do PHP.

4. Zasada minimum plugin list

Każda wtyczka = potencjalne CVE. Przegląd co kwartał: czy wszystkie aktywne wtyczki są używane? Porzucone albo nieaktualizowane > 12 miesięcy — kandydat do usunięcia.

5. Segmentacja sieci (dla VPS / dedykowanych)

SSRF zyskuje na sile, gdy WP ma dostęp do wewnętrznej sieci. Firewall rules blokujące WP process od dostępu do 169.254.169.254 (cloud metadata), 127.0.0.1:6379 (Redis), 10.0.0.0/8 (internal LAN) — ograniczają blast radius SSRF.

6. Bezpieczna konfiguracja wp_remote_get()

Jeśli piszesz własne wtyczki — walidacja hostów w każdym zewnętrznym request:

function safe_remote_get($url) {
    $parsed = parse_url($url);
    $ip = gethostbyname($parsed['host']);

    // Blokuj private / reserved ranges
    if (!filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
        return new WP_Error('forbidden_ip', 'Private/reserved IP');
    }

    return wp_remote_get($url, ['timeout' => 5]);
}

To chroni przed SSRF nawet jeśli przyjmuje URL od user input.

W Devance dla każdego klienta pakietu opieki monitoring CVE i emergency response jest wliczony w abonament — nie dopłata. Bo bezpieczeństwo nie może być opcją premium. Jeśli prowadzisz sklep WordPress i nie masz zautomatyzowanego monitoringu podatności — zrób darmowy audyt, pokażemy jakie CVE obecnie dotyczą Twojej instalacji.