Resumen ejecutivo
On 19 May 2026 a high-severity Server Side Request Forgery (SSRF) vulnerability affecting the NPM package “sillytavern” (≤ 1.17.0) was published (CVE-2026-46372, GHSA-qg89-qwwh-5f3j). The issue stems from an unvalidated baseUrl parameter used by a SearXNG search proxy integration. An attacker can abuse this flaw to force the affected server to make HTTP requests to attacker-controlled or internal addresses, potentially exposing credentials, metadata endpoints, internal services, or enabling further lateral movement. The package was patched in version 1.18.0. If you run any services that depend on sillytavern or expose reverse proxy functionality, treat this as urgent.

Por qué esto es importante para los propietarios de sitios de WordPress

Although this vulnerability is in an NPM package, modern WordPress sites often share infrastructure with other services (Node.js microservices, chat frontends, self-hosted assistants, etc.). When multiple services share the same host, network, or credentials, an SSRF in one component can be weaponised to reach internal resources that the WordPress application or its administrators rely on.

• Shared hosting: WordPress may sit on the same VM or container as other software that uses Node packages.
• Mixed stacks: Teams run mixed-technology tooling that can be used as a pivot if one component is compromised.
• SSRF risk: Any component that performs outbound HTTP(S) requests on behalf of an input can be tricked into querying internal endpoints like metadata services, management APIs, or local admin interfaces.

SSRF is high-impact because the attacker controls the request target; consequences range from credential theft to lateral movement inside a cloud or private network.

Technical background — what happened

SillyTavern uses SearXNG as a search proxy for certain features. In vulnerable releases (≤ 1.17.0) the baseUrl configuration value was not validated. This allowed an attacker to supply or manipulate baseUrl so that the application would issue requests to arbitrary URLs chosen by the attacker.

Características clave:

• Class: Server Side Request Forgery (SSRF).
• Root cause: insufficient validation of a URL/configuration parameter (baseUrl).
• Impact: the server can be induced to request internal IPs, cloud metadata endpoints (e.g., 169.254.169.254), or any reachable host.
• Patch: sillytavern v1.18.0 includes validation and restrictions to prevent attacker-controlled baseUrl valores.

Referencing: CVE-2026-46372, GHSA-qg89-qwwh-5f3j.

Posibles escenarios de explotación (nivel alto)

Representative attacks to understand the risk (no exploit code provided):

• Retrieve cloud metadata: Requesting metadata endpoints to obtain credentials or tokens (e.g., AWS IMDS at 169.254.169.254).
• Access internal admin interfaces: Access management APIs bound to localhost or internal subnets.
• Port scanning / discovery: Use the vulnerable host to map internal IP ranges and services.
• Bypass network controls: Have the victim server perform requests that are blocked from the Internet.
• Exfiltración de datos: Query internal debug endpoints and return sensitive data to an attacker-controlled endpoint.

Cómo detectar intentos de explotación

Detection requires correlating web traffic and outbound activity. Look for:

• Registros del servidor web: Solicitudes con parámetros como baseUrl, proxy, url, objetivo. Long, encoded, or credential-containing values are suspicious.
• Registros de aplicación: Logged destination addresses for outbound requests; spikes in outbound request frequency.
• Outbound network/egress logs: Connections from the web process to 169.254.169.254, 127.0.0.1, RFC1918 ranges, or IPv6 link-local addresses.
• DNS logs: Queries for random subdomains or unusual resolution patterns.
• Registros de WAF: Rules blocking suspicious baseUrl values or private IP patterns.
• Process behaviour: New or unexpected processes making network calls from PHP/Node runtimes, or CPU/DNS spikes.

Establish baselines for normal behaviour so deviations can be detected more reliably.

Immediate steps — what to do in the next few hours

1. Patch the software

   If you run SillyTavern or services depending on sillytavern, update to v1.18.0 immediately. This is the correct fix.

2. If you cannot update immediately, virtual patch

   Deploy WAF rules to detect and block malicious baseUrl usage and restrict public access to endpoints that accept proxy URLs.

3. Restrict outgoing connections

   Apply host egress rules (cloud security groups, firewalls, iptables) to deny outbound traffic except to allowed destinations. At minimum, block access to cloud metadata endpoints (169.254.169.254) and internal management networks.

4. Quarantine and investigate

   If indicators are present, isolate the affected host, preserve logs, and search for signs of credential theft or persistence.

5. Rotate credentials and secrets (if necessary)

   If metadata or admin APIs may have been queried, rotate API keys and service credentials.

6. Monitor for follow-on actions

   Watch for new accounts, altered configurations, modified files, or scheduled tasks indicating follow-up activity.

WAF mitigations and example rules

Below are practical ModSecurity-style examples to detect and block common SSRF patterns. Test these in staging before production; tailor to your environment.

1) Block requests with baseUrl referencing private IPs or metadata endpoints

# Check for baseUrl param containing private IPs or metadata endpoints
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:'Blocked potential SSRF - disallowed target in baseUrl',id:100002,log"
    

Purpose: Niega solicitudes donde baseUrl points to localhost, RFC1918 addresses, AWS metadata, or IPv6 link-local addresses.

2) Deny URLs with embedded credentials or suspicious protocols

# Block URLs with basic auth credentials or dangerous protocols
SecRule ARGS "@rx [a-z0-9+\-.]+://[^@]+@|^(file|gopher|dict|scp|ssh):" \n    "phase:2,deny,status:403,msg:'Blocked potential SSRF - credentials or unsafe scheme found',id:100003,log"
    

3) Rate limit or block repeated proxy requests

# Rate limiting example (conceptual)
SecRule REQUEST_URI "@contains /proxy" "phase:1,pass,nolog,exec:/usr/local/bin/check_rate_limit.sh"
    

Integrate with a rate-limiter to reduce automated exploitation attempts.

4) Block DNS lookups resolving to private addresses

If your WAF or proxy supports external checks, resolve the supplied hostname and block when it resolves to private IPs. This requires careful implementation to avoid DNS race conditions.

Nota: These are defensive patterns. They reduce exposure but do not replace patching the vulnerable package.

Hardening guidance for developers (fixes in code)

Developers accepting external URLs or proxy configuration should adopt these practices:

• Allowlist hosts: Only permit a defined set of hostnames the application legitimately needs to contact.
• Reject non-HTTP schemes: Accept only http and https donde sea apropiado.
• Enforce host validation: Parse and validate the host component; reject IPs in private ranges.
• Prevent embedded credentials: Disallow URLs containing user:pass@host.
• Resolve and validate: If hostnames are allowed, resolve them and deny if resulting IPs are private. Use a secure resolver and consider race conditions.
• Timeouts and limits: Set request timeouts and maximum redirects to avoid long-running requests.
• Treat config as sensitive: Do not use user-supplied values directly as runtime configuration without strict validation.

These are the types of mitigations SillyTavern’s maintainers implemented in v1.18.0.

Host & network level protections

• Prevent web processes from accessing internal-only services unless explicitly required. Use host egress firewall rules, cloud security groups, or egress proxies.
• Block cloud metadata access from application instances if not required by the app. For example, block outbound traffic to 169.254.169.254 from the web process.
• Run services in segmented networks with least-privilege networking.
• Where possible, route outbound requests through a monitored proxy that enforces allowlists and logs activity.

Network controls limit what an SSRF can reach even if the application remains vulnerable for a period.

Incident response checklist (practical steps)

1. Preservar evidencia

   Capture web, application, firewall, DNS, and network logs. Ensure logs are not overwritten.

2. Contener

   Disable the vulnerable feature or place the host behind IP restrictions. Remove public access temporarily if required.

3. Parche

   Update sillytavern to v1.18.0 or apply the vendor-recommended remediation.

4. Analizar

   Inspect access logs for suspicious baseUrl values and check outgoing connections and DNS queries from the host.

5. Rotar secretos

   If metadata or credentials may have been exposed, rotate API keys and tokens.

6. Escanear y limpiar

   Run malware scans and integrity checks to detect post-exploit artifacts.

7. Restaurar y monitorear

   Resume normal operations only after confirming the system is clean. Increase monitoring for at least 30 days.

8. Informe

   Notify your security team, hosting provider, or customers as required by your incident response policy or regulatory obligations.

Detection and log examples to search for

Use these indicators when searching logs or coordinating with your hosting provider:

• Solicitudes con parámetros: ?baseUrl=, ?proxy=, ?target=, POST/JSON bodies containing baseUrl or proxy_url.
• Parameter values containing: 169.254.169.254, 127.0.0.1, localhost, 10., 172.16.–172.31., 192.168., fe80:, ::1, or the @ character (embedded credentials).
• Spikes in outbound requests to private ranges from your web server IP.
• WAF logs showing signature triggers for SSRF patterns.

Why updating is still the most important step

WAF rules and egress filtering are compensating controls. They reduce risk but do not eliminate the underlying vulnerability. The correct remediation is to update sillytavern to v1.18.0, which fixes the root cause. Virtual patches can fail if attackers modify payloads or if legitimate use cases bypass rules.

Secure configuration checklist (summary)

• Update sillytavern to v1.18.0 (or later).
• Deploy WAF rules blocking baseUrl pointing to private ranges, metadata IPs, and embedded credentials.
• Restrict outbound network access for web processes; block cloud metadata endpoints from application processes.
• Review application code for other user-supplied URL parameters and harden accordingly.
• Monitor logs for suspicious proxy usage and implement alerts for anomalous outbound connections.
• Rotate credentials if metadata or internal endpoints may have been accessed.
• Perform a full investigation and malware scan if exploitation is suspected.

Reflexiones finales

SSRF vulnerabilities are particularly dangerous because they enable an attacker to use your own infrastructure as a reconnaissance and attack platform. For WordPress operators that share infrastructure with Node.js services or mixed environments, this SillyTavern SSRF is a reminder to:

• Aplica el parche de inmediato.
• Use WAFs as temporary virtual patches while you update.
• Harden egress rules and network segmentation.
• Monitor logs and be prepared to respond.

If you need assistance assessing exposure or applying mitigations, engage a trusted security advisor or your hosting provider’s incident response team. Stay vigilant: keep software up to date, validate inputs, and limit what each server can access on the network.