SSRF en SillyTavern (<= 1.17.0): Lo que los propietarios de sitios de WordPress necesitan saber y cómo WP‑Firewall te protege

Fecha: 2026-05-19
Autor: Equipo de seguridad de firewall WP

Etiquetas: seguridad, wordpress, ssrf, vulnerabilidad, waf, respuesta a incidentes

Resumen ejecutivo

El 19 de mayo de 2026 se publicó una vulnerabilidad de Falsificación de Solicitudes del Lado del Servidor (SSRF) de alta gravedad que afecta al paquete NPM “tabernasilly” (<= 1.17.0) (CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j). El problema proviene de un baseUrl parámetro utilizado por una integración de proxy de búsqueda SearXNG. Un atacante puede abusar de esta falla para obligar al servidor afectado a realizar solicitudes HTTP a direcciones controladas por el atacante o internas, exponiendo potencialmente credenciales, puntos finales de metadatos, servicios internos o habilitando un movimiento lateral adicional. El paquete fue corregido en la versión 1.18.0. Si ejecutas servicios que dependen de sillytavern o exponen funcionalidad de proxy inverso, trata esto como urgente.

Esta publicación explica los detalles técnicos en un lenguaje sencillo, por qué los administradores de WordPress deberían preocuparse, cómo detectar intentos de explotación, mitigaciones inmediatas y a largo plazo recomendadas, reglas de WAF de ejemplo que puedes implementar ahora (incluyendo la guía de WP‑Firewall), y una lista de verificación de respuesta a incidentes que puedes seguir si sospechas de un compromiso.

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

A primera vista, una vulnerabilidad de paquete NPM puede no parecer directamente relacionada con WordPress. Pero los entornos modernos de WordPress rara vez están aislados:

• Los sitios de WordPress a menudo coexisten con otros servicios en la misma cuenta de hosting o VM (capas de caché, frontends/backends sin cabeza, agentes de chat, bots o integraciones autoalojadas).
• Los equipos ejecutan herramientas de tecnología mixta (microservicios de Node.js, frontends de chat, asistentes autoalojados) en la misma infraestructura que la aplicación de WordPress.
• Cualquier componente que pueda ser inducido a realizar solicitudes HTTP(S) salientes en nombre de un atacante puede ser utilizado para acceder a puntos finales internos (por ejemplo, APIs de metadatos, paneles de administración, puertos de base de datos) o alcanzar servicios internos que nunca deberían ser públicos.

SSRF es una clase de error de alto impacto porque el atacante controla el objetivo de las solicitudes HTTP del lado del servidor, lo que potencialmente permite el acceso a recursos internos que de otro modo serían inaccesibles. Para los entornos de WordPress que comparten redes o credenciales con otros servicios, un SSRF en incluso un paquete puede tener consecuencias severas.

Antecedentes técnicos — qué sucedió

SillyTavern utiliza SearXNG como un proxy de búsqueda para algunas de sus características. En las versiones vulnerables (<= 1.17.0) el baseUrl valor que configura el proxy de búsqueda no fue validado ni restringido adecuadamente. Eso permitió a un atacante proporcionar o manipular baseUrl para que la aplicación realizara solicitudes a URLs arbitrarias determinadas por el atacante.

Características clave de la vulnerabilidad:

• Clase: Falsificación de Solicitudes del Lado del Servidor (SSRF).
• Causa raíz: validación insuficiente de un parámetro de URL/configuración (baseUrl) pasado a una llamada de proxy.
• Impacto: el servidor vulnerable puede ser inducido a realizar solicitudes a IPs internas, puntos finales de metadatos en la nube (169.254.169.254), otras API de gestión internas, o cualquier host que el servidor pueda alcanzar. El atacante no necesita estar en la misma red que la víctima; solo necesita poder activar la ruta de código vulnerable.
• Parche: sillytavern v1.18.0 incluye validación y restricciones para prevenir el control del atacante. baseUrl valores.

Identificadores de CVE y asesoría (para seguimiento): CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j.

Posibles escenarios de explotación (nivel alto)

A continuación se presentan escenarios representativos para ilustrar por qué SSRF es peligroso. Evito presentar código de explotación, pero es importante entender ataques plausibles:

• Recuperar metadatos de la nube: Si el servidor puede alcanzar el punto final de metadatos del proveedor de la nube, un atacante puede solicitar tokens de credenciales o metadatos de instancia (por ejemplo, AWS IMDS en 169.254.169.254), lo que les permite escalar al acceso a la API de la nube.
• Acceder a interfaces administrativas internas: Muchas aplicaciones exponen API de gestión en localhost o subredes internas. SSRF puede ser utilizado para acceder a esas API (por ejemplo, un punto final de gestión vinculado a 127.0.0.1 o un socket de Docker/RPC expuesto a través de HTTP) y activar acciones destructivas.
• Escaneo de puertos y descubrimiento interno: Un atacante puede usar el servidor vulnerable como un pivote para escanear rangos de IP internas y mapear servicios que de otro modo serían inalcanzables desde Internet.
• Eludir reglas de acceso a la red: Algunas redes restringen el acceso externo directo a ciertos sistemas; SSRF puede eludir esas restricciones haciendo que el servidor víctima realice la solicitud en su lugar.
• Exfiltración de datos a través de puntos finales internos: Algunos servicios exponen datos sensibles a través de API internas o puntos finales de depuración. SSRF puede solicitar esos puntos finales y devolver resultados al atacante (directamente o a través de respuestas redirigidas).

Debido a que el parámetro vulnerable configura objetivos de salida, un atacante puede elaborar solicitudes que devuelvan directamente datos útiles o establecer una cadena de seguimientos que resulten en divulgación de datos.

Cómo detectar intentos de explotación

Detectar intentos de SSRF requiere monitorear tanto las solicitudes web como la actividad de salida del servidor. Aquí hay señales de detección prácticas:

• Registros del servidor web: buscar solicitudes con parámetros inusuales, especialmente baseUrl, proxy, url, objetivo, u otros parámetros de URL. Valores inusualmente largos o codificados, credenciales de autenticación básica en la URL, o valores que incluyan http://169.254.169.254 o rangos de IP privadas son señales de alerta.
• Registros de la aplicación: verificar rutas de código que realicen solicitudes HTTP y registren direcciones de destino. Picos en la frecuencia de solicitudes salientes o solicitudes repetidas a un único punto final de proxy son sospechosos.
• Registros de red saliente: inspeccionar los registros de salida para conexiones a rangos de IP internos que se realicen desde el proceso del servidor web, o conexiones inesperadas a 169.254.169.254, 127.0.0.1, rangos privados RFC1918, o direcciones locales de enlace IPv6 (fe80::/10).
• registros DNS: buscar consultas DNS a subdominios aleatorios o dominios con cambios rápidos de TTL (posible evasión basada en DNS).
• Registros de WAF: bloquear y monitorear cualquier intento que incluya valores baseUrl o patrones que coincidan con rangos de IP privados.
• Comportamiento del proceso: nuevos procesos que realizan llamadas de red desde el tiempo de ejecución de PHP/Node o picos en la actividad de CPU/DNS pueden indicar intentos de explotación automatizados.

Establecer estas líneas base temprano para que las desviaciones se destaquen.

Pasos inmediatos — qué hacer en las próximas horas

1. Parchear el software
   Si ejecutas SillyTavern o cualquier servicio que dependa de sillytavern, actualiza a la v1.18.0 de inmediato. Esa es la solución correcta y elimina el error subyacente.
2. Si no puedes actualizar de inmediato, aplica parches virtuales
   Desplegar reglas WAF para detectar y bloquear el uso malicioso baseUrl (ejemplos a continuación).
   Restringir el acceso público a cualquier punto final que acepte baseUrl o proxy URLs.
3. Restringir conexiones salientes
   Utilizar reglas de salida de host (grupos de seguridad en la nube, reglas de firewall, iptables o controles de hosting) para denegar el tráfico saliente excepto a destinos explícitamente permitidos.
   Como mínimo, bloquear el acceso a los puntos finales de metadatos en la nube (169.254.169.254) y redes de gestión internas.
4. Cuarentena e investigar
   Si detectas indicadores sospechosos de la lista de detección, aísla el host afectado y preserva los registros para la forensía. Busca signos de robo de credenciales o compromisos adicionales.
5. Rota credenciales y secretos (si es necesario)
   Si se han consultado metadatos de la nube o APIs de administración, rota las claves API y credenciales afectadas.
6. Monitorea acciones de seguimiento
   Busca nuevas cuentas de usuario, configuraciones cambiadas, archivos modificados o tareas programadas que puedan indicar actividad de seguimiento.

Mitigaciones de WP‑Firewall y reglas de ejemplo

Como proveedor de firewall de aplicaciones web, recomendamos un enfoque en capas: conjuntos de reglas WAF inmediatos para parchear virtualmente este vector específico, más controles de salida de host/red para defensa en profundidad.

A continuación se presentan reglas de ejemplo que puedes implementar de inmediato. Estos son ejemplos de reglas genéricas (estilo ModSecurity) destinadas a ser adaptadas para tu plataforma. Prueba las reglas en un entorno de pruebas antes de implementarlas en producción para evitar interrumpir el tráfico legítimo.

Nota importante: estos son patrones de detección y bloqueo. Son intencionalmente defensivos; no los uses como la única protección: actualizar el paquete vulnerable sigue siendo obligatorio.

1) Bloquear solicitudes con baseUrl referencias a IPs privadas o puntos finales de metadatos

# Verifica si el parámetro baseUrl contiene IPs privadas o puntos finales de metadatos"

Lo que esto hace:

• Detecta parámetros como baseUrl y niega solicitudes si el valor contiene localhost, rangos privados RFC1918, IP de metadatos de AWS o direcciones locales IPv6.

2) Negar URLs con credenciales incrustadas o protocolos sospechosos

# Bloquear URLs con credenciales de autenticación básica o protocolos peligrosos"

3) Limitar la tasa o bloquear solicitudes proxy repetidas

Si una sola IP remota está enviando muchas solicitudes proxy o muchos valores únicos, baseUrl limita o bloquea:

Ejemplo de limitación de tasa # (conceptual)"

(Lo anterior ilustra la integración de una verificación de límite de tasa personalizada para reducir la explotación automatizada.)

4) Bloquear búsquedas DNS que resuelven a direcciones privadas

Un enfoque más avanzado es realizar una resolución DNS del host proporcionado y bloquear si se resuelve a IPs privadas. Esto requiere soporte de WAF para verificaciones externas o el uso de un servicio proxy.

5) Reglas gestionadas por WP‑Firewall

Los clientes de WP‑Firewall recibirán firmas gestionadas que:

• Detectan y bloquean patrones comunes de SSRF en parámetros de consulta y cargas útiles JSON.
• Niegan solicitudes que apunten a metadatos o rangos de IP RFC1918.
• Aplican heurísticas para detectar reencuadres DNS o nombres de host que resuelven a direcciones internas.

Si eres cliente de WP‑Firewall, asegúrate de que las reglas gestionadas estén habilitadas y que las actualizaciones automáticas de reglas estén activas.

Guía de endurecimiento para desarrolladores (correcciones en el código)

Si mantienes o desarrollas código que acepta URLs externas o configuración de proxy, adopta estas prácticas de codificación segura:

• Usa una lista de permitidos: solo permite nombres de host específicos (o un conjunto claramente definido de nombres de host) que la aplicación necesita contactar legítimamente.
• Rechaza esquemas no HTTP: solo acepta http y https donde sea apropiado. Niega file:, gopher:, ssh:, etc.
• Aplica validación de host: analiza la URL del lado del servidor y valida el componente del host contra una lista de permitidos. Rechaza IPs en rangos privados.
• Previene credenciales incrustadas: no permitas URLs que contengan usuario:contraseña@host.
• Resuelve nombres de host y valida direcciones IP: si permites nombres de host, realiza una resolución DNS y niega si la IP resuelta es privada o de otro modo sospechosa. Ten en cuenta las condiciones de carrera DNS y utiliza verificaciones resilientes (por ejemplo, realiza la resolución utilizando un resolvedor seguro).
• Timeouts y límites: establece tiempos de espera de solicitudes y límites en redirecciones para evitar el enmascaramiento de solicitudes y conexiones de larga duración.
• Evita usar valores proporcionados por el usuario directamente como configuración: trata los parámetros de configuración como entradas sensibles que requieren una validación estricta antes de su uso.

Estos son los tipos de correcciones que los mantenedores de SillyTavern implementaron en la versión v1.18.0 para cerrar la vulnerabilidad.

Protecciones a nivel de host y red

Confiar exclusivamente en correcciones de la aplicación no es suficiente. Agrega controles de red:

• Evita que los procesos web accedan a servicios solo internos a menos que sea explícitamente necesario. Usa reglas de firewall de salida del host (iptables / nftables), grupos de seguridad en la nube o proxies de salida para restringir HTTP saliente.
• Bloquea el acceso a metadatos de la nube desde instancias de aplicación si las API de la nube no son necesarias para la aplicación. Por ejemplo, bloquea el tráfico saliente a 169.254.169.254 desde el proceso web o usa políticas de rol de instancia que limiten la exposición.
• Ejecuta servicios en segmentos de red separados con redes de menor privilegio entre componentes.
• Donde sea posible, fuerza las solicitudes salientes a través de un proxy controlado y monitoreado que haga cumplir listas de permitidos y registre la actividad.

Estas medidas limitan lo que un SSRF puede alcanzar incluso si la aplicación es vulnerable.

Lista de verificación de respuesta a incidentes (pasos prácticos)

Si sospechas de explotación, sigue esta lista de verificación ordenada:

1. Preservar las pruebas
   Captura registros (web, aplicación, firewall, DNS y flujos de red). No sobrescribas los registros.
2. Contener
   Desactiva temporalmente la función o el punto final vulnerable.
   Coloca el host detrás de un control de acceso (restricción de IP) o desactiva el acceso público al servicio.
3. Parche
   Actualiza sillytavern a v1.18.0 o aplica la remediación recomendada por el proveedor.
4. Analizar
   Inspecciona los registros de acceso en busca de sospechas baseUrl valores, solicitudes de proxy repetidas o solicitudes que contienen objetivos de IP privada.
   Verifica las conexiones salientes y las consultas DNS que se originan desde el host.
5. secretos rotativos
   Si tienes alguna razón para creer que los metadatos de la nube o las credenciales fueron expuestos, rota las claves API, tokens y credenciales de servicio.
6. Escanear y limpiar
   Realiza un escaneo completo de malware y una verificación de integridad en el servidor para detectar posibles artefactos posteriores a la explotación.
7. Restaurar y monitorear
   Solo reanuda las operaciones normales después de estar seguro de que el sistema está limpio y endurecido. Aumenta la supervisión durante al menos 30 días.
8. Informe
   Donde sea necesario, notifica a tu equipo de seguridad, proveedor de alojamiento o clientes según tu política de respuesta a incidentes y obligaciones regulatorias.

Detección y ejemplos de registro para buscar

Busque en sus registros (o entregue estas consultas a su proveedor de alojamiento) signos de intentos de explotación:

• Solicitudes con parámetros:
  • ?baseUrl=
  • ?proxy= o ?target=
  • Cuerpos POST/JSON que contienen baseUrl o proxy_url
• Valores en parámetros que contienen:
  • 169.254.169.254
  • 127.0.0.1 o localhost
  • 10. / 172.16.–172.31. / 192.168.
  • fe80: o ::1
  • @ (indicando credenciales incrustadas)
• Picos repentinos en solicitudes salientes a rangos privados que se originan desde la IP de su servidor web.
• Registros de WAF que muestran las firmas mencionadas anteriormente activándose repetidamente.

Recoja y correlacione estos hallazgos en registros web, de red y DNS.

Por qué la actualización sigue siendo el paso más importante

Las reglas de WAF, el filtrado de salida y las restricciones de host reducen el riesgo, pero son controles compensatorios. La verdadera solución es parchear el software vulnerable. Los parches virtuales pueden fallar si los atacantes alteran sus cargas útiles, o si se requieren usos legítimos. Actualizar a sillytavern v1.18.0 elimina la vulnerabilidad en la fuente y reduce su superficie de ataque a largo plazo.

Cómo WP‑Firewall ayuda a proteger entornos de WordPress

En WP‑Firewall nos enfocamos en combinar reglas gestionadas, detección proactiva y remediación fácil para proteger sitios de WordPress y la infraestructura que los rodea:

• Firmas gestionadas: nuestras actualizaciones de reglas incluyen patrones de detección de SSRF y heurísticas ajustadas para bloquear intentos de explotar no validados baseUrl o parámetros de proxy.
• Parches virtuales: cuando se divulga una vulnerabilidad urgente, WP‑Firewall puede implementar parches virtuales a través del WAF para reducir la exposición mientras planificas actualizaciones de código.
• Escaneo de malware: escaneamos en busca de indicadores de compromiso y cambios sospechosos que pueden seguir a un pivote SSRF.
• Controles de salida y tasa: WP‑Firewall se puede configurar para limitar puntos finales sospechosos y detectar patrones inusuales de solicitudes salientes.
• Orientación y soporte de incidentes: nuestros expertos proporcionan orientación de remediación paso a paso y pueden ayudarte a interpretar registros y responder a incidentes.

Combina las protecciones de WP‑Firewall con el parche del proveedor (v1.18.0) y el endurecimiento de la red del host para la mejor defensa.

Lista de verificación de configuración segura (resumen)

• Actualiza sillytavern a v1.18.0 (o posterior).
• Habilita las reglas gestionadas por WP‑Firewall y asegúrate de que las actualizaciones automáticas de firmas estén activadas.
• Implementa reglas WAF que bloqueen baseUrl apuntando a rangos privados, IPs de metadatos y credenciales incrustadas.
• Restringe el acceso a la red saliente para procesos web; bloquea los puntos finales de metadatos en la nube desde procesos de aplicación.
• Revisa el código de la aplicación en busca de otros parámetros de URL proporcionados por el usuario y endurece en consecuencia.
• Monitorea los registros en busca de uso sospechoso de proxy e implementa alertas para conexiones salientes anómalas.
• Rota las credenciales si se puede haber accedido a metadatos o puntos finales internos.
• Realiza una investigación completa y un escaneo de malware si se sospecha explotación.

Regístrate para protección inmediata: Comienza con el Plan Gratuito de WP‑Firewall

Asegura tu sitio rápidamente con el Plan Gratuito de WP‑Firewall

Si aún no estás protegido, el plan Básico (Gratis) de WP‑Firewall es una excelente manera de obtener mitigación inmediata mientras actualizas componentes vulnerables. El plan gratuito incluye protecciones esenciales como un firewall de aplicación web gestionado (WAF), escáner de malware, ancho de banda ilimitado y mitigación para los riesgos del OWASP Top 10: todo lo necesario para bloquear patrones comunes de explotación SSRF y reducir la exposición inmediata. Puedes registrarte y habilitar la protección rápidamente en:

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

Si deseas automatización adicional (eliminación automática de malware, listas negras/blancas de IP) o funciones avanzadas (informes de seguridad mensuales, parches virtuales automáticos y servicios de seguridad gestionados), considera actualizar a nuestros niveles Standard o Pro como tu próximo paso.

Reflexiones finales

Las vulnerabilidades SSRF son poderosas porque convierten tu propio host en una plataforma de reconocimiento y ataque. Para los propietarios y operadores de sitios de WordPress que comparten infraestructura con servicios de Node.js o ejecutan entornos mixtos, este problema de SSRF de SillyTavern es un recordatorio oportuno para:

• Aplique el parche lo antes posible.
• Utilizar WAFs para proporcionar parches virtuales rápidos.
• Endurecer las reglas de salida y la segmentación de la red.
• Monitorear registros y estar listo para responder.

Si necesitas ayuda para evaluar la exposición o aplicar mitigaciones guiadas, el equipo de seguridad de WP‑Firewall puede ayudarte a aplicar parches virtuales, crear reglas de WAF personalizadas y realizar investigaciones. Comienza con el plan gratuito para agregar protección rápidamente y contacta a nuestro equipo para obtener un soporte más profundo si encuentras indicadores de explotación.

Mantente seguro: mantén el software actualizado, valida las entradas y minimiza lo que cada servidor puede hacer en la red.