SSRF i SillyTavern (<= 1.17.0): Hvad WordPress-webstedsejere skal vide, og hvordan WP‑Firewall beskytter dig

Dato: 2026-05-19
Forfatter: WP-Firewall Sikkerhedsteam

Tags: sikkerhed, wordpress, ssrf, sårbarhed, waf, hændelsesrespons

Resumé

Den 19. maj 2026 blev en høj‑alvorlig Server Side Request Forgery (SSRF) sårbarhed, der påvirker NPM-pakken “sillytavern” (<= 1.17.0) offentliggjort (CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j). Problemet stammer fra en ikke-valideret baseUrl parameter, der bruges af en SearXNG søgeproxy-integration. En angriber kan udnytte denne fejl til at tvinge den berørte server til at foretage HTTP-anmodninger til angriber-kontrollerede eller interne adresser, hvilket potentielt kan afsløre legitimationsoplysninger, metadata-endepunkter, interne tjenester eller muliggøre yderligere lateral bevægelse. Pakken blev rettet i version 1.18.0. Hvis du kører nogen tjenester, der afhænger af sillytavern eller udsætter omvendt proxy-funktionalitet, skal du behandle dette som presserende.

Dette indlæg forklarer de tekniske detaljer på almindeligt sprog, hvorfor WordPress-administratorer bør bekymre sig, hvordan man opdager udnyttelsesforsøg, anbefalede øjeblikkelige og langsigtede afbødninger, eksempler på WAF-regler, du kan implementere nu (inklusive WP‑Firewall vejledning), og en tjekliste for hændelsesrespons, du kan følge, hvis du mistænker kompromittering.

Hvorfor dette er vigtigt for WordPress-webstedsejere

Ved første øjekast kan en NPM-pakke-sårbarhed ikke se direkte relateret til WordPress ud. Men moderne WordPress-miljøer er sjældent isolerede:

• WordPress-websteder sameksisterer ofte med andre tjenester på den samme hostingkonto eller VM (cachinglagre, headless frontend/backends, chatagenter, bots eller selvhostede integrationer).
• Teams kører blandet teknologi værktøjer (Node.js mikrotjenester, chat frontends, selvhostede assistenter) på den samme infrastruktur som WordPress-applikationen.
• Enhver komponent, der kan tilskyndes til at udføre udgående HTTP(S) anmodninger på vegne af en angriber, kan blive våbeniseret til at få adgang til interne endepunkter (f.eks. metadata API'er, admin-paneler, databaseporte) eller nå interne tjenester, der aldrig bør være offentlige.

SSRF er en høj-påvirkningsklasse af fejl, fordi angriberen kontrollerer målet for server-side HTTP-anmodninger, hvilket potentielt muliggør adgang til ellers utilgængelige interne ressourcer. For WordPress-miljøer, der deler netværk eller legitimationsoplysninger med andre tjenester, kan en SSRF i selv én pakke medføre alvorlige konsekvenser.

Teknisk baggrund — hvad skete der

SillyTavern bruger SearXNG som en søgeproxy til nogle af sine funktioner. I de sårbare versioner (<= 1.17.0) blev baseUrl værdien, der konfigurerer søgeproxyen, ikke korrekt valideret eller begrænset. Det tillod en angriber at levere eller manipulere baseUrl så applikationen ville foretage anmodninger til vilkårlige URL'er bestemt af angriberen.

Nøglekarakteristika ved sårbarheden:

• Klasse: Server Side Request Forgery (SSRF).
• Rodårsag: utilstrækkelig validering af en URL/konfigurationsparameter (baseUrl) sendt til et proxyopkald.
• Indvirkning: den sårbare server kan fås til at udføre anmodninger til interne IP'er, cloud metadata-endepunkter (169.254.169.254), andre interne administrations-API'er eller enhver vært, som serveren kan nå. Angriberen behøver ikke at være på det samme netværk som offeret — de skal kun kunne udløse den sårbare kodevej.
• Patch: sillytavern v1.18.0 inkluderer validering og restriktioner for at forhindre angriber-kontrolleret baseUrl værdier.

CVE og rådgivende identifikatorer (til sporing): CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j.

Mulige udnyttelsesscenarier (højt niveau)

Nedenfor er repræsentative scenarier for at illustrere, hvorfor SSRF er farligt. Jeg undgår at præsentere udnyttelseskode, men det er vigtigt at forstå plausible angreb:

• Hent cloud metadata: Hvis serveren kan nå cloududbyderens metadata-endepunkt, kan en angriber anmode om legitimations tokens eller instans metadata (f.eks. AWS IMDS på 169.254.169.254), hvilket giver dem mulighed for at eskalere til cloud API-adgang.
• Adgang til interne admin-grænseflader: Mange applikationer eksponerer administrations-API'er på localhost eller interne subnet. SSRF kan bruges til at få adgang til disse API'er (for eksempel et administrations-endepunkt bundet til 127.0.0.1 eller en Docker/RPC socket eksponeret via HTTP) og udløse destruktive handlinger.
• Portscanning og intern opdagelse: En angriber kan bruge den sårbare server som en pivot til at scanne interne IP-områder og kortlægge tjenester, der ellers er utilgængelige fra internettet.
• Omgå netværksadgangsregler: Nogle netværk begrænser direkte ekstern adgang til visse systemer; SSRF kan omgå disse begrænsninger ved at lade offer-serveren foretage anmodningen i stedet.
• Dataeksfiltrering via interne endepunkter: Nogle tjenester eksponerer følsomme data via interne API'er eller debug-endepunkter. SSRF kan anmode om disse endepunkter og returnere resultater til angriberen (direkte eller via omdirigerede svar).

Fordi den sårbare parameter konfigurerer udgående mål, kan en angriber udforme anmodninger, der enten direkte returnerer nyttige data eller etablerer en kæde af opfølgninger, der resulterer i datadiskretion.

Sådan opdager du forsøg på udnyttelse

At opdage SSRF-forsøg kræver overvågning af både webanmodninger og serverens udgående aktivitet. Her er praktiske detektionssignaler:

• Webserverlogfiler: se efter anmodninger med usædvanlige parametre, især baseUrl, proxy, url, mål, eller andre URL-parametre. Usædvanligt lange eller kodede værdier, grundlæggende autentificeringslegitimationsoplysninger i URL'en, eller værdier der inkluderer http://169.254.169.254 eller private IP-områder er røde flag.
• Applikationslogfiler: tjek for kodeveje, der udfører HTTP-anmodninger og logger destinationsadresser. Spidser i frekvensen af udgående anmodninger eller gentagne anmodninger til et enkelt proxy-endepunkt er mistænkelige.
• Udgående netværkslogger: inspicer egress logs for forbindelser til interne IP-områder, der laves fra webserverprocessen, eller uventede forbindelser til 169.254.169.254, 127.0.0.1, private RFC1918-områder eller IPv6 link-lokale adresser (fe80::/10).
• DNS-logfiler: se efter DNS-forespørgsler til tilfældige subdomæner eller domæner med hurtige TTL-ændringer (potentiel DNS-baseret undvigelse).
• WAF logs: blokér og overvåg eventuelle forsøg, der inkluderer mistænkelige baseUrl værdier eller mønstre, der matcher private IP-områder.
• Procesadfærd: nye processer, der laver netværksopkald fra PHP/Node-runtime eller spidser i CPU/DNS-aktivitet kan indikere automatiserede udnyttelsesforsøg.

Etabler disse baseline tidligt, så afvigelser skiller sig ud.

Øjeblikkelige skridt — hvad man skal gøre i de næste par timer

1. Patch softwaren
   Hvis du kører SillyTavern eller en hvilken som helst tjeneste, der afhænger af sillytavern, opdater straks til v1.18.0. Det er den korrekte løsning og fjerner den underliggende fejl.
2. Hvis du ikke kan opdatere straks, anvend virtuel patching
   Udrul WAF-regler for at opdage og blokere ondsindet baseUrl brug (eksempler nedenfor).
   Begræns offentlig adgang til eventuelle slutpunkter, der accepterer baseUrl eller proxy-URL'er.
3. Begræns udgående forbindelser
   Brug værts-egress regler (cloud sikkerhedsgrupper, firewall regler, iptables eller hostingkontroller) til at nægte udgående trafik undtagen til eksplicit tilladte destinationer.
   Som minimum, blokér adgang til cloud metadata slutpunkter (169.254.169.254) og interne administrationsnetværk.
4. Karantæne og undersøg
   Hvis du opdager mistænkelige indikatorer fra detektionslisten, isoler den berørte vært og bevar logfiler til retsmedicinske formål. Tjek for tegn på credential tyveri eller yderligere kompromittering.
5. Rotér legitimationsoplysninger og hemmeligheder (hvis nødvendigt)
   Hvis cloud metadata eller admin API'er muligvis er blevet forespurgt, roter de berørte API-nøgler og legitimationsoplysninger.
6. Overvåg for efterfølgende handlinger
   Se efter nye brugerkonti, ændret konfiguration, modificerede filer eller planlagte opgaver, der kan indikere opfølgende aktivitet.

WP-Firewall afbødninger og eksempler på regler

Som en webapplikationsfirewall-leverandør anbefaler vi en lagdelt tilgang: øjeblikkelige WAF-regelsæt til at virtual-patch denne specifikke vektor, plus vært/netværk udgående kontroller for dybdeforsvar.

Nedenfor er eksempler på regler, du kan implementere med det samme. Disse er generiske regel eksempler (ModSecurity stil) beregnet til at blive tilpasset til din platform. Test regler i et staging-miljø, før du implementerer dem i produktion for at undgå at bryde legitim trafik.

Vigtig bemærkning: disse er detektions- og blokkeringsmønstre. De er bevidst defensive; brug dem ikke som den eneste beskyttelse - opdatering af den sårbare pakke forbliver obligatorisk.

1) Bloker anmodninger med baseUrl henvisning til private IP'er eller metadata-endepunkter

# Tjek for baseUrl-parameter, der indeholder private IP'er eller metadata-endepunkter SecRule ARGS_NAMES|ARGS "@rx (?i)^(baseurl|base_url|proxy_url|target_url)$" "phase:2,pass,id:100001,log,ctl:ruleRemoveById=981172" SecRule ARGS:baseUrl|ARGS:base_url|ARGS:proxy_url|ARGS:target_url \n    "@rx (?i)(127\.0\.0\.1|localhost|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.169\.254|fe80:|::1)" \n    "phase:2,deny,status:403,msg:'Blokerede potentielle SSRF - ikke tilladt mål i baseUrl',id:100002,log"

Hvad dette gør:

• Detekterer parametre som baseUrl og nægter anmodninger, hvis værdien indeholder localhost, private RFC1918-områder, AWS metadata IP eller IPv6 link-lokale adresser.

2) Nægte URL'er med indlejrede legitimationsoplysninger eller mistænkelige protokoller

# Bloker URL'er med grundlæggende auth legitimationsoplysninger eller farlige protokoller SecRule ARGS "@rx [a-z0-9+\-.]+://[^@]+@|^(file|gopher|dict|scp|ssh):" \n    "phase:2,deny,status:403,msg:'Blokerede potentielle SSRF - legitimationsoplysninger eller usikker skema fundet',id:100003,log"

3) Ratebegræns eller blokér gentagne proxy-anmodninger

Hvis en enkelt fjern-IP sender mange proxy-anmodninger eller mange unikke baseUrl værdier, dæmp eller blokér:

# Rate limiting eksempel (konceptuelt)"

(Ovenstående illustrerer integration af en brugerdefineret hastighedsbegrænsningskontrol for at reducere automatiseret udnyttelse.)

4) Bloker DNS-opslag, der løser til private adresser

En mere avanceret tilgang er at udføre en DNS-opløsning af den angivne vært og blokere, hvis den løser til private IP'er. Dette kræver WAF-understøttelse til eksterne kontroller eller brug af en proxyservice.

5) WP‑Firewall administrerede regler

WP‑Firewall-kunder vil modtage administrerede signaturer, der:

• Registrerer og blokerer almindelige SSRF-mønstre i forespørgselsparametre og JSON-payloads.
• Nægter anmodninger, der retter sig mod metadata eller RFC1918 IP-områder.
• Anvender heuristikker til at opdage DNS-rebinding eller værtsnavne, der løser til interne adresser.

Hvis du er en WP‑Firewall-kunde, skal du sikre dig, at de administrerede regler er aktiveret, og at automatiske regelopdateringer er aktive.

Hærdningsvejledning til udviklere (rettelser i kode)

Hvis du vedligeholder eller udvikler kode, der accepterer eksterne URL'er eller proxykonfiguration, skal du vedtage disse sikre kodningspraksisser:

• Brug en tilladelsesliste: tillad kun specifikke værtsnavne (eller et klart defineret sæt af værtsnavne), som applikationen legitimt har brug for at kontakte.
• Afvis ikke-HTTP-skemata: accepter kun http og https hvor det er passende. Nægte file:, gopher: gopher:, ssh:osv.
• Håndhæve værtsvalidering: parse URL'en server-side og validere værtskomponenten mod en tilladelsesliste. Afvis IP'er i private områder.
• Forhindre indlejrede legitimationsoplysninger: forbyde URL'er, der indeholder bruger:kode@vært.
• Opløs værtsnavne og valider IP-adresser: hvis du tillader værtsnavne, udfør en DNS-opløsning og nægt, hvis den løste IP er privat eller på anden måde mistænkelig. Vær opmærksom på DNS-racebetingelser og brug robuste kontroller (f.eks. udfør opløsning ved hjælp af en sikker resolver).
• Timeout og grænser: sæt anmodningstimeouts og grænser for omdirigeringer for at undgå anmodningssmugling og langvarige forbindelser.
• Undgå at bruge brugerleverede værdier direkte som konfiguration: behandl konfigurationsparametre som følsomme input, der kræver streng validering før brug.

Disse er de typer af rettelser, som SillyTavern-vedligeholdere implementerede i v1.18.0-udgivelsen for at lukke sårbarheden.

Værts- og netværksniveau beskyttelser

At stole udelukkende på applikationsrettelser er ikke nok. Tilføj netværkskontroller:

• Forhindre webprocesser i at få adgang til interne tjenester kun, hvis det er eksplicit nødvendigt. Brug værtsudgående firewall-regler (iptables / nftables), cloud-sikkerhedsgrupper eller udgående proxyer til at begrænse udgående HTTP.
• Bloker adgang til cloud-metadata fra applikationsinstanser, hvis cloud-API'er ikke er nødvendige for appen. For eksempel, bloker udgående trafik til 169.254.169.254 fra webprocessen eller brug instansrollepolitikker, der begrænser eksponeringen.
• Kør tjenester i adskilte netværkssegmenter med mindst privilegeret netværk mellem komponenter.
• Hvor det er muligt, tving udgående anmodninger gennem en overvåget, kontrolleret proxy, der håndhæver tilladelseslister og logger aktivitet.

Disse foranstaltninger begrænser, hvad en SSRF kan nå, selvom applikationen er sårbar.

Incident response tjekliste (praktiske skridt)

Hvis du mistænker udnyttelse, følg denne ordnede tjekliste:

1. Bevar beviser
   Fang logs (web, applikation, firewall, DNS og netværksstrømme). Overskriv ikke logs.
2. Indeholde
   Deaktiver midlertidigt den sårbare funktion eller endpoint.
   Sæt værten bag en adgangskontrol (IP-restriktion) eller deaktiver offentlig adgang til tjenesten.
3. Patch
   Opdater sillytavern til v1.18.0 eller anvend den leverandøranbefalede afhjælpning.
4. Analyser
   Inspicer adgangslogs for mistænkelige baseUrl værdier, gentagne proxyanmodninger eller anmodninger, der indeholder private IP-mål.
   Tjek udgående forbindelser og DNS-forespørgsler, der stammer fra værten.
5. Roter hemmeligheder
   Hvis du har nogen grund til at tro, at cloud-metadata eller legitimationsoplysninger blev eksponeret, roter API-nøgler, tokens og servicelegitimationsoplysninger.
6. Scann og rengør
   Kør en fuld malware-scanning og integritetskontrol på serveren for at opdage mulige post-exploit artefakter.
7. Gendan og overvåg
   Genoptag kun normale operationer, efter at du er sikker på, at systemet er rent og hærdet. Øg overvågningen i mindst 30 dage.
8. Rapportér
   Hvor det er nødvendigt, underret dit sikkerhedsteam, hostingudbyder eller kunder afhængigt af din hændelsesresponspolitik og regulatoriske forpligtelser.

Detektion og logeksempler at søge efter

Søg i dine logs (eller giv disse forespørgsler til din hostingudbyder) efter tegn på forsøg på udnyttelse:

• Forespørgsler med parametre:
  • ?baseUrl=
  • ?proxy= eller ?target=
  • POST/JSON-kroppe der indeholder baseUrl eller proxy_url
• Værdier i parametre der indeholder:
  • 169.254.169.254
  • 127.0.0.1 eller localhost
  • 10. / 172.16.–172.31. / 192.168.
  • fe80: eller ::1
  • @ (indikerer indlejrede legitimationsoplysninger)
• Pludselige stigninger i udgående forespørgsler til private områder, der stammer fra din webserver-IP.
• WAF-logs der viser de nævnte signaturer, der udløses gentagne gange.

Indsaml og korreler disse fund på tværs af web-, netværks- og DNS-logs.

Hvorfor opdatering stadig er det vigtigste skridt

WAF-regler, udgående filtrering og værtbegrænsninger reducerer risikoen, men de er kompenserende kontroller. Den sande løsning er at opdatere den sårbare software. Virtuelle patches kan fejle, hvis angribere ændrer deres payloads, eller hvis legitime anvendelser er nødvendige. Opdatering til sillytavern v1.18.0 eliminerer sårbarheden ved kilden og reducerer dit langsigtede angrebsoverflade.

Hvordan WP‑Firewall hjælper med at beskytte WordPress-miljøer

Hos WP‑Firewall fokuserer vi på at kombinere administrerede regler, proaktiv detektion og nem afhjælpning for at beskytte WordPress-sider og infrastrukturen omkring dem:

• Administrerede signaturer: vores regelopdateringer inkluderer SSRF-detekteringsmønstre og tilpassede heuristikker til at blokere forsøg på at udnytte uvalidere baseUrl eller proxyparametre.
• Virtuel patching: når en akut sårbarhed afsløres, kan WP‑Firewall implementere virtuelle patches gennem WAF for at reducere eksponeringen, mens du planlægger kodeopdateringer.
• Malware-scanning: vi scanner efter indikatorer for kompromittering og mistænkelige ændringer, der kan følge efter et SSRF-pivot.
• Udgange og hastighedskontroller: WP‑Firewall kan konfigureres til at dæmpe mistænkelige slutpunkter og opdage usædvanlige udgående anmodningsmønstre.
• Vejledning og hændelsessupport: vores eksperter giver trin-for-trin vejledning til afhjælpning og kan hjælpe dig med at fortolke logs og reagere på hændelser.

Kombiner WP‑Firewall-beskyttelser med leverandørpatchen (v1.18.0) og hårdning af værtsnetværk for den bedste forsvar.

Sikker konfigurationscheckliste (resumé)

• Opdater sillytavern til v1.18.0 (eller senere).
• Aktivér WP‑Firewall administrerede regler og sørg for, at automatiske signaturopdateringer er aktiveret.
• Implementer WAF-regler, der blokerer baseUrl der peger på private områder, metadata IP'er og indlejrede legitimationsoplysninger.
• Begræns udgående netværksadgang for webprocesser; blokér cloud metadata slutpunkter fra app-processer.
• Gennemgå applikationskode for eventuelle andre brugerleverede URL-parametre og hård dem derefter.
• Overvåg logs for mistænkelig proxybrug og implementer alarmer for unormale udgående forbindelser.
• Rotér legitimationsoplysninger, hvis metadata eller interne slutpunkter kan være blevet tilgået.
• Udfør en fuld undersøgelse og malware-scanning, hvis udnyttelse mistænkes.

Tilmeld dig for øjeblikkelig beskyttelse: Start med WP‑Firewall Free Plan

Sikre dit websted hurtigt med WP‑Firewall Free Plan

Hvis du endnu ikke er beskyttet, er WP‑Firewall's Basic (Gratis) plan en fremragende måde at få øjeblikkelig afbødning, mens du opdaterer sårbare komponenter. Den gratis plan inkluderer essentielle beskyttelser såsom en administreret webapplikationsfirewall (WAF), malware-scanner, ubegribelig båndbredde og afbødning for OWASP Top 10 risici — alt hvad der er nødvendigt for at blokere almindelige SSRF udnyttelsesmønstre og reducere øjeblikkelig eksponering. Du kan tilmelde dig og aktivere beskyttelse hurtigt på:

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

Hvis du ønsker yderligere automatisering (automatisk malwarefjernelse, IP-blacklisting/hvidlisting) eller avancerede funktioner (månedlige sikkerhedsrapporter, automatisk virtuel patching og administrerede sikkerhedstjenester), overvej at opgradere til vores Standard eller Pro niveauer som dit næste skridt.

Afsluttende tanker

SSRF sårbarheder er magtfulde, fordi de forvandler din egen vært til en rekognoscerings- og angrebsplatform. For WordPress webstedsejere og operatører, der deler infrastruktur med Node.js tjenester eller kører blandede miljøer, er dette SillyTavern SSRF problem en rettidig påmindelse om at:

• Opdater med det samme.
• Brug WAF'er til at give hurtige virtuelle patches.
• Hærd udgående regler og netværkssegmentering.
• Overvåg logfiler og vær klar til at reagere.

Hvis du har brug for hjælp til at vurdere eksponering eller anvende vejledte afbødninger, kan WP‑Firewall's sikkerhedsteam hjælpe dig med at anvende virtuelle patches, udarbejde skræddersyede WAF regler og udføre undersøgelser. Start med den gratis plan for hurtigt at tilføje beskyttelse, og kontakt vores team for dybere support, hvis du finder indikatorer for udnyttelse.

Hold dig sikker — hold software opdateret, valider input og minimer hvad hver server har lov til at gøre på netværket.