SSRF w SillyTavern (<= 1.17.0): Co właściciele stron WordPress powinni wiedzieć i jak WP‑Firewall Cię chroni

Data: 2026-05-19
Autor: Zespół ds. bezpieczeństwa WP‑Firewall

Tagi: bezpieczeństwo, wordpress, ssrf, podatność, waf, reakcja na incydenty

Streszczenie

19 maja 2026 roku opublikowano podatność o wysokim stopniu zagrożenia typu Server Side Request Forgery (SSRF) dotycząca pakietu NPM “głupiatawerna” (<= 1.17.0) (CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j). Problem wynika z niezweryfikowanego baseUrl parametru używanego przez integrację proxy wyszukiwania SearXNG. Napastnik może wykorzystać tę lukę, aby zmusić dotknięty serwer do wykonywania żądań HTTP do adresów kontrolowanych przez napastnika lub wewnętrznych, potencjalnie ujawniając dane uwierzytelniające, punkty końcowe metadanych, usługi wewnętrzne lub umożliwiając dalszy ruch boczny. Pakiet został poprawiony w wersji 1.18.0. Jeśli uruchamiasz jakiekolwiek usługi, które zależą od sillytavern lub udostępniają funkcjonalność odwrotnego proxy, traktuj to jako pilne.

Ten post wyjaśnia szczegóły techniczne w prostym języku, dlaczego administratorzy WordPress powinni się tym przejmować, jak wykrywać próby wykorzystania, zalecane natychmiastowe i długoterminowe środki zaradcze, przykładowe zasady WAF, które możesz wdrożyć teraz (w tym wskazówki WP‑Firewall) oraz listę kontrolną reakcji na incydenty, którą możesz śledzić, jeśli podejrzewasz kompromitację.

Dlaczego to ma znaczenie dla właścicieli stron WordPress

Na pierwszy rzut oka podatność pakietu NPM może nie wyglądać na bezpośrednio związaną z WordPress. Ale nowoczesne środowiska WordPress rzadko są izolowane:

• Strony WordPress często współistnieją z innymi usługami na tym samym koncie hostingowym lub VM (warstwy pamięci podręcznej, bezgłowe frontend/backendy, agenci czatu, boty lub samodzielnie hostowane integracje).
• Zespoły uruchamiają narzędzia o mieszanej technologii (mikrousługi Node.js, frontendy czatu, samodzielnie hostowane asystenty) na tej samej infrastrukturze co aplikacja WordPress.
• Każdy komponent, który można skłonić do wykonywania wychodzących żądań HTTP(S) w imieniu napastnika, może być wykorzystany do uzyskania dostępu do wewnętrznych punktów końcowych (np. API metadanych, paneli administracyjnych, portów baz danych) lub dotarcia do wewnętrznych usług, które nigdy nie powinny być publiczne.

SSRF to klasa błędów o wysokim wpływie, ponieważ napastnik kontroluje cel żądań HTTP po stronie serwera, co potencjalnie umożliwia dostęp do inaczej niedostępnych zasobów wewnętrznych. Dla środowisk WordPress, które dzielą sieć lub dane uwierzytelniające z innymi usługami, SSRF w nawet jednym pakiecie może przynieść poważne konsekwencje.

Tło techniczne — co się stało

SillyTavern używa SearXNG jako proxy wyszukiwania dla niektórych swoich funkcji. W podatnych wersjach (<= 1.17.0) baseUrl wartość, która konfiguruje proxy wyszukiwania, nie była odpowiednio weryfikowana ani ograniczana. To pozwoliło napastnikowi dostarczyć lub manipulować baseUrl tak, aby aplikacja wysyłała żądania do dowolnych adresów URL określonych przez napastnika.

Kluczowe cechy podatności:

• Klasa: Fałszywe żądanie po stronie serwera (SSRF).
• Przyczyna główna: niewystarczająca walidacja parametru URL/konfiguracji (baseUrl) przekazywanego do wywołania proxy.
• Wpływ: podatny serwer może być zmuszony do wykonywania żądań do wewnętrznych adresów IP, punktów końcowych metadanych w chmurze (169.254.169.254), innych wewnętrznych interfejsów API zarządzania lub dowolnego hosta, do którego serwer ma dostęp. Atakujący nie musi być w tej samej sieci co ofiara — wystarczy, że będzie w stanie wywołać podatną ścieżkę kodu.
• Łatka: sillytavern v1.18.0 zawiera walidację i ograniczenia, aby zapobiec kontrolowanym przez atakującego baseUrl wartościami.

identyfikatorom CVE i poradnikom (do śledzenia): CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j.

Możliwe scenariusze wykorzystania (na wysokim poziomie)

Poniżej przedstawiono reprezentatywne scenariusze ilustrujące, dlaczego SSRF jest niebezpieczne. Unikam przedstawiania kodu eksploatacyjnego, ale ważne jest, aby zrozumieć prawdopodobne ataki:

• Pobieranie metadanych chmury: Jeśli serwer może uzyskać dostęp do punktu końcowego metadanych dostawcy chmury, atakujący może zażądać tokenów uwierzytelniających lub metadanych instancji (np. AWS IMDS na 169.254.169.254), co pozwala im na eskalację dostępu do API chmury.
• Dostęp do wewnętrznych interfejsów administracyjnych: Wiele aplikacji udostępnia interfejsy API zarządzania na localhost lub wewnętrznych podsieciach. SSRF może być używane do uzyskiwania dostępu do tych interfejsów API (na przykład punkt końcowy zarządzania powiązany z 127.0.0.1 lub gniazdo Docker/RPC udostępnione przez HTTP) i wywoływania destrukcyjnych działań.
• Skanowanie portów i odkrywanie wewnętrznych: Atakujący może użyć podatnego serwera jako punktu obrotu do skanowania wewnętrznych zakresów IP i mapowania usług, które są inaczej niedostępne z Internetu.
• Ominięcie zasad dostępu do sieci: Niektóre sieci ograniczają bezpośredni dostęp zewnętrzny do niektórych systemów; SSRF może ominąć te ograniczenia, sprawiając, że serwer ofiary wykona żądanie zamiast tego.
• Ekstrakcja danych przez wewnętrzne punkty końcowe: Niektóre usługi udostępniają wrażliwe dane przez wewnętrzne interfejsy API lub punkty końcowe debugowania. SSRF może żądać tych punktów końcowych i zwracać wyniki do atakującego (bezpośrednio lub za pośrednictwem przekierowanych odpowiedzi).

Ponieważ podatny parametr konfiguruje cele wychodzące, atakujący może tworzyć żądania, które albo bezpośrednio zwracają użyteczne dane, albo ustanawiają łańcuch dalszych działań, które prowadzą do ujawnienia danych.

Jak wykrywać próby wykorzystania

Wykrywanie prób SSRF wymaga monitorowania zarówno żądań internetowych, jak i wychodzącej aktywności serwera. Oto praktyczne sygnały wykrywania:

• Dzienniki serwera WWW: szukaj żądań z nietypowymi parametrami, szczególnie baseUrl, proxy, url, cel, lub innymi parametrami URL. Nietypowo długie lub zakodowane wartości, dane uwierzytelniające podstawowej autoryzacji w URL lub wartości, które zawierają http://169.254.169.254 lub prywatne zakresy IP są czerwonymi flagami.
• Dzienniki aplikacji: sprawdź ścieżki kodu, które wykonują żądania HTTP i rejestrują adresy docelowe. Wzrost częstotliwości wychodzących żądań lub powtarzające się żądania do jednego punktu końcowego proxy są podejrzane.
• Wychodzące dzienniki sieciowe: sprawdź logi egress dla połączeń do wewnętrznych zakresów IP wykonywanych z procesu serwera WWW lub niespodziewanych połączeń do 169.254.169.254, 127.0.0.1, prywatnych zakresów RFC1918 lub adresów lokalnych IPv6 (fe80::/10).
• logi DNS: szukaj zapytań DNS do losowych subdomen lub domen z szybkim czasem TTL (potencjalna unikanie oparte na DNS).
• Dzienniki WAF: blokuj i monitoruj wszelkie próby, które zawierają podejrzane baseUrl wartości lub wzorce pasujące do prywatnych zakresów IP.
• Zachowanie procesu: nowe procesy wykonujące wywołania sieciowe z runtime PHP/Node lub skoki w aktywności CPU/DNS mogą wskazywać na zautomatyzowane próby eksploatacji.

Ustal te podstawy wcześnie, aby odchylenia były widoczne.

Natychmiastowe kroki — co zrobić w ciągu najbliższych kilku godzin

1. Zaktualizuj oprogramowanie
   Jeśli uruchamiasz SillyTavern lub jakąkolwiek usługę, która zależy od sillytavern, zaktualizuj do v1.18.0 natychmiast. To jest poprawne rozwiązanie i eliminuje podstawowy błąd.
2. Jeśli nie możesz zaktualizować natychmiast, zastosuj wirtualne łatanie
   Wdróż zasady WAF, aby wykrywać i blokować złośliwe baseUrl użycie (przykłady poniżej).
   Ogranicz publiczny dostęp do wszelkich punktów końcowych, które akceptują baseUrl lub proxy URL.
3. Ogranicz połączenia wychodzące
   Użyj zasad egress hosta (grupy zabezpieczeń w chmurze, zasady zapory, iptables lub kontrole hostingu), aby odmówić ruchu wychodzącego, z wyjątkiem wyraźnie dozwolonych miejsc docelowych.
   Co najmniej zablokuj dostęp do punktów końcowych metadanych w chmurze (169.254.169.254) i wewnętrznych sieci zarządzania.
4. Kwarantanna i dochodzenie
   Jeśli wykryjesz podejrzane wskaźniki z listy wykrywania, izoluj dotknięty host i zachowaj logi do analizy kryminalistycznej. Sprawdź oznaki kradzieży poświadczeń lub dalszego naruszenia.
5. Rotuj poświadczenia i sekrety (jeśli to konieczne)
   Jeśli metadane chmury lub interfejsy API administratora mogły być zapytane, rotuj dotknięte klucze API i poświadczenia.
6. Monitoruj dalsze działania
   Szukaj nowych kont użytkowników, zmienionej konfiguracji, zmodyfikowanych plików lub zaplanowanych zadań, które mogą wskazywać na działania następcze.

Mitigacje WP‑Firewall i przykładowe zasady

Jako dostawca zapory aplikacji internetowej zalecamy podejście warstwowe: natychmiastowe zestawy reguł WAF do wirtualnego łatania tego konkretnego wektora, plus kontrole egress hosta/sieci dla głębszej obrony.

Poniżej znajdują się przykładowe zasady, które możesz wdrożyć natychmiast. Są to ogólne przykłady reguł (styl ModSecurity) przeznaczone do dostosowania do twojej platformy. Testuj zasady w środowisku stagingowym przed wdrożeniem do produkcji, aby uniknąć zakłócenia legalnego ruchu.

Ważna uwaga: są to wzorce wykrywania i blokowania. Są celowo defensywne; nie używaj ich jako jedynej ochrony — aktualizacja podatnego pakietu pozostaje obowiązkowa.

1) Blokuj żądania z baseUrl odniesieniem do prywatnych adresów IP lub punktów końcowych metadanych

# Sprawdź parametr baseUrl zawierający prywatne adresy IP lub punkty końcowe metadanych"

Co to robi:

• Wykrywa parametry takie jak baseUrl i odrzuca żądania, jeśli wartość zawiera localhost, prywatne zakresy RFC1918, adres IP metadanych AWS lub lokalne adresy IPv6.

2) Odrzuć adresy URL z osadzonymi poświadczeniami lub podejrzanymi protokołami

# Blokuj adresy URL z poświadczeniami podstawowej autoryzacji lub niebezpiecznymi protokołami"

3) Ogranicz lub blokuj powtarzające się żądania proxy

Jeśli pojedynczy zdalny adres IP wysyła wiele żądań proxy lub wiele unikalnych baseUrl wartości, ogranicz lub zablokuj:

# Przykład ograniczenia przepustowości (koncepcyjny)"

(Powyższe ilustruje integrację niestandardowego sprawdzania ograniczenia przepustowości w celu zmniejszenia automatycznego wykorzystywania.)

4) Blokowanie zapytań DNS rozwiązujących na adresy prywatne

Bardziej zaawansowane podejście polega na przeprowadzeniu rozwiązywania DNS dostarczonego hosta i zablokowaniu, jeśli rozwiązuje się na prywatne adresy IP. Wymaga to wsparcia WAF dla zewnętrznych kontroli lub użycia usługi proxy.

5) Zarządzane zasady WP‑Firewall

Klienci WP‑Firewall otrzymają zarządzane sygnatury, które:

• Wykrywają i blokują powszechne wzorce SSRF w parametrach zapytań i ładunkach JSON.
• Odrzucają zapytania celujące w metadane lub zakresy IP RFC1918.
• Stosują heurystyki do wykrywania DNS rebinding lub nazw hostów, które rozwiązują się na adresy wewnętrzne.

Jeśli jesteś klientem WP‑Firewall, upewnij się, że zarządzane zasady są włączone, a automatyczne aktualizacje zasad są aktywne.

Wskazówki dotyczące wzmacniania dla programistów (poprawki w kodzie)

Jeśli utrzymujesz lub rozwijasz kod, który akceptuje zewnętrzne adresy URL lub konfigurację proxy, przyjmij te bezpieczne praktyki kodowania:

• Użyj listy dozwolonych: zezwól tylko na konkretne nazwy hostów (lub wyraźnie zdefiniowany zestaw nazw hostów), które aplikacja rzeczywiście musi kontaktować.
• Odrzuć schematy nie-HTTP: akceptuj tylko http I https tam, gdzie to odpowiednie. Odrzuć file:, gopher:, ssh:itd.
• Wymuszaj walidację hosta: analizuj URL po stronie serwera i waliduj komponent hosta w odniesieniu do listy dozwolonych. Odrzuć adresy IP w prywatnych zakresach.
• Zapobiegaj osadzonym poświadczeniom: zabroń adresów URL zawierających użytkownik:hasło@host.
• Rozwiązuj nazwy hostów i waliduj adresy IP: jeśli zezwalasz na nazwy hostów, przeprowadź rozwiązywanie DNS i odrzuć, jeśli rozwiązany adres IP jest prywatny lub w inny sposób podejrzany. Uważaj na warunki wyścigu DNS i używaj odpornych kontroli (np. przeprowadzaj rozwiązywanie za pomocą bezpiecznego resolvera).
• Czas oczekiwania i limity: ustaw limity czasu żądań i limity przekierowań, aby uniknąć oszustw żądań i długoterminowych połączeń.
• Unikaj bezpośredniego używania wartości dostarczonych przez użytkownika jako konfiguracji: traktuj parametry konfiguracyjne jako wrażliwe dane wejściowe, które wymagają ścisłej walidacji przed użyciem.

To są rodzaje poprawek, które wprowadzili utrzymujący SillyTavern w wersji v1.18.0, aby zamknąć lukę.

Ochrony na poziomie hosta i sieci

Poleganie wyłącznie na poprawkach aplikacji nie wystarczy. Dodaj kontrole sieciowe:

• Zapobiegaj dostępowi procesów webowych do usług dostępnych tylko wewnętrznie, chyba że jest to wyraźnie wymagane. Użyj reguł zapory egress hosta (iptables / nftables), grup zabezpieczeń w chmurze lub proxy egress, aby ograniczyć wychodzący HTTP.
• Zablokuj dostęp do metadanych chmury z instancji aplikacji, jeśli API chmury nie są potrzebne przez aplikację. Na przykład, zablokuj ruch wychodzący do 169.254.169.254 z procesu webowego lub użyj polityk ról instancji, które ograniczają ekspozycję.
• Uruchamiaj usługi w oddzielnych segmentach sieciowych z najmniejszymi uprawnieniami między komponentami.
• Gdzie to możliwe, wymuś wychodzące żądania przez monitorowane, kontrolowane proxy, które egzekwuje listy dozwolone i rejestruje aktywność.

Te środki ograniczają to, co SSRF może osiągnąć, nawet jeśli aplikacja jest podatna.

Lista kontrolna reakcji na incydenty (praktyczne kroki)

Jeśli podejrzewasz wykorzystanie, postępuj zgodnie z tą uporządkowaną listą kontrolną:

1. Zachowaj dowody
   Zbieraj logi (webowe, aplikacyjne, zapory, DNS i przepływy sieciowe). Nie nadpisuj logów.
2. Zawierać
   Tymczasowo wyłącz podatną funkcję lub punkt końcowy.
   Umieść hosta za kontrolą dostępu (ograniczenie IP) lub wyłącz publiczny dostęp do usługi.
3. Poprawka
   Zaktualizuj sillytavern do v1.18.0 lub zastosuj zalecaną przez dostawcę poprawkę.
4. Analiza
   Sprawdź logi dostępu pod kątem podejrzanych baseUrl wartości, powtarzające się żądania proxy lub żądania zawierające prywatne cele IP.
   Sprawdź wychodzące połączenia i zapytania DNS pochodzące z hosta.
5. Obracanie sekretów
   Jeśli masz jakiekolwiek powody, aby sądzić, że metadane chmury lub dane uwierzytelniające zostały ujawnione, obróć klucze API, tokeny i dane uwierzytelniające usługi.
6. Skanuj i czyść
   Przeprowadź pełne skanowanie złośliwego oprogramowania i kontrolę integralności na serwerze, aby wykryć możliwe artefakty poeksploatacyjne.
7. Przywróć i monitoruj
   Wznów normalne operacje tylko po upewnieniu się, że system jest czysty i zabezpieczony. Zwiększ monitoring przez co najmniej 30 dni.
8. Zgłoś
   W razie potrzeby powiadom swój zespół ds. bezpieczeństwa, dostawcę hostingu lub klientów, w zależności od polityki reagowania na incydenty i obowiązków regulacyjnych.

Wykrywanie i przykłady logów do przeszukania

Przeszukaj swoje logi (lub przekaż te zapytania swojemu dostawcy hostingu) w poszukiwaniu oznak prób wykorzystania:

• Żądania z parametrami:
  • ?baseUrl=
  • ?proxy= Lub ?target=
  • Ciała POST/JSON zawierające baseUrl Lub proxy_url
• Wartości w parametrach zawierające:
  • 169.254.169.254
  • 127.0.0.1 Lub localhost
  • 10. / 172.16.–172.31. / 192.168.
  • fe80: Lub ::1
  • @ (wskazujące na osadzone poświadczenia)
• Nagłe skoki w wychodzących żądaniach do prywatnych zakresów pochodzących z adresu IP twojego serwera WWW.
• Logi WAF pokazujące powtarzające się sygnatury wspomniane powyżej.

Zbieraj i koreluj te ustalenia w logach sieciowych, DNS i webowych.

Dlaczego aktualizacja jest nadal najważniejszym krokiem

Zasady WAF, filtrowanie wychodzące i ograniczenia hostów zmniejszają ryzyko, ale są to kontrole kompensacyjne. Prawdziwym rozwiązaniem jest załatanie podatnego oprogramowania. Wirtualne łatki mogą zawieść, jeśli napastnicy zmienią swoje ładunki, lub jeśli wymagane są legalne użycia. Aktualizacja do sillytavern v1.18.0 eliminuje podatność u źródła i zmniejsza twoją długoterminową powierzchnię ataku.

Jak WP‑Firewall pomaga chronić środowiska WordPress

W WP‑Firewall koncentrujemy się na łączeniu zarządzanych zasad, proaktywnego wykrywania i łatwej naprawy, aby chronić strony WordPress i infrastrukturę wokół nich:

• Zarządzane sygnatury: nasze aktualizacje zasad obejmują wzorce wykrywania SSRF i dostosowane heurystyki do blokowania prób wykorzystania niezvalidowanych baseUrl lub parametry proxy.
• Wirtualne łatanie: gdy ujawniona zostanie pilna luka, WP‑Firewall może wdrożyć wirtualne poprawki za pomocą WAF, aby zmniejszyć narażenie podczas planowania aktualizacji kodu.
• Skanowanie złośliwego oprogramowania: skanujemy wskaźniki kompromitacji i podejrzane zmiany, które mogą nastąpić po przeskoku SSRF.
• Kontrola egress i limitów: WP‑Firewall można skonfigurować, aby ograniczać podejrzane punkty końcowe i wykrywać nietypowe wzorce żądań wychodzących.
• Wskazówki i wsparcie incydentowe: nasi eksperci zapewniają szczegółowe wskazówki dotyczące usuwania problemów i mogą pomóc w interpretacji dzienników oraz reagowaniu na incydenty.

Połącz ochronę WP‑Firewall z poprawką dostawcy (v1.18.0) i wzmocnieniem sieci hosta dla najlepszej obrony.

Lista kontrolna bezpiecznej konfiguracji (podsumowanie)

• Zaktualizuj sillytavern do v1.18.0 (lub nowszej).
• Włącz zarządzane zasady WP‑Firewall i upewnij się, że automatyczne aktualizacje sygnatur są aktywowane.
• Wdrożenie zasad WAF blokujących baseUrl wskazujących na prywatne zakresy, adresy IP metadanych i osadzone poświadczenia.
• Ogranicz dostęp do sieci wychodzącej dla procesów webowych; zablokuj punkty końcowe metadanych chmurowych z procesów aplikacji.
• Przejrzyj kod aplikacji pod kątem innych parametrów URL dostarczonych przez użytkownika i wzmocnij odpowiednio.
• Monitoruj dzienniki pod kątem podejrzanego użycia proxy i wdrażaj alerty dla anomalii w połączeniach wychodzących.
• Zmień poświadczenia, jeśli metadane lub wewnętrzne punkty końcowe mogły zostać uzyskane.
• Przeprowadź pełne dochodzenie i skanowanie złośliwego oprogramowania, jeśli podejrzewa się wykorzystanie.

Zarejestruj się, aby uzyskać natychmiastową ochronę: Rozpocznij od darmowego planu WP‑Firewall

Szybko zabezpiecz swoją stronę za pomocą darmowego planu WP‑Firewall

Jeśli jeszcze nie jesteś chroniony, plan podstawowy WP‑Firewall (darmowy) to doskonały sposób na natychmiastowe złagodzenie problemów podczas aktualizacji podatnych komponentów. Darmowy plan obejmuje podstawowe zabezpieczenia, takie jak zarządzany zapora aplikacji internetowej (WAF), skaner złośliwego oprogramowania, nielimitowaną przepustowość oraz łagodzenie ryzyk OWASP Top 10 — wszystko, co potrzebne, aby zablokować powszechne wzorce wykorzystania SSRF i zmniejszyć natychmiastową ekspozycję. Możesz szybko zarejestrować się i włączyć ochronę pod adresem:

https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Jeśli chcesz dodatkowej automatyzacji (automatyczne usuwanie złośliwego oprogramowania, czarna/biała lista IP) lub zaawansowanych funkcji (miesięczne raporty bezpieczeństwa, automatyczne łatki wirtualne i zarządzane usługi bezpieczeństwa), rozważ aktualizację do naszych poziomów Standard lub Pro jako następny krok.

Ostateczne przemyślenia

Luki SSRF są potężne, ponieważ zamieniają twój własny host w platformę rozpoznawania i ataku. Dla właścicieli i operatorów stron WordPress, którzy dzielą infrastrukturę z usługami Node.js lub prowadzą mieszane środowiska, ten problem SSRF w SillyTavern jest aktualnym przypomnieniem, aby:

• Należy niezwłocznie wykonać łatkę.
• Używać WAF do szybkiego dostarczania wirtualnych poprawek.
• Wzmocnić zasady wyjścia i segmentację sieci.
• Monitorować logi i być gotowym do reakcji.

Jeśli potrzebujesz pomocy w ocenie ekspozycji lub stosowaniu ukierunkowanych łagodzeń, zespół bezpieczeństwa WP‑Firewall może pomóc w zastosowaniu wirtualnych poprawek, opracowaniu dostosowanych zasad WAF i przeprowadzeniu dochodzeń. Zacznij od darmowego planu, aby szybko dodać ochronę, a jeśli znajdziesz wskaźniki wykorzystania, skontaktuj się z naszym zespołem w celu uzyskania głębszego wsparcia.

Bądź bezpieczny — utrzymuj oprogramowanie w aktualności, waliduj dane wejściowe i minimalizuj to, co każdy serwer może robić w sieci.