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 “sillytavern” (≤ 1.17.0) (CVE-2026-46372, GHSA-qg89-qwwh-5f3j). El problema proviene de un baseUrl parámetro no validado 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 permitiendo 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.

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

Aunque esta vulnerabilidad está en un paquete NPM, los sitios modernos de WordPress a menudo comparten infraestructura con otros servicios (microservicios de Node.js, frontends de chat, asistentes autohospedados, etc.). Cuando múltiples servicios comparten el mismo host, red o credenciales, un SSRF en un componente puede ser utilizado como arma para alcanzar recursos internos de los que la aplicación de WordPress o sus administradores dependen.

• Alojamiento compartido: WordPress puede estar en la misma VM o contenedor que otro software que utiliza paquetes de Node.
• Pilas mixtas: Los equipos ejecutan herramientas de tecnología mixta que pueden ser utilizadas como un pivote si un componente es comprometido.
• Riesgo de SSRF: Cualquier componente que realice solicitudes HTTP(S) salientes en nombre de una entrada puede ser engañado para consultar puntos finales internos como servicios de metadatos, APIs de gestión o interfaces de administración locales.

SSRF tiene un alto impacto porque el atacante controla el objetivo de la solicitud; las consecuencias varían desde el robo de credenciales hasta el movimiento lateral dentro de una red privada o en la nube.

Antecedentes técnicos — qué sucedió

SillyTavern utiliza SearXNG como un proxy de búsqueda para ciertas funciones. En versiones vulnerables (≤ 1.17.0) el baseUrl valor de configuración no fue validado. Esto permitió a un atacante proporcionar o manipular baseUrl para que la aplicación emitiera solicitudes a URLs arbitrarias elegidas por el atacante.

Características clave:

• 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).
• Impacto: el servidor puede ser inducido a solicitar IPs internas, puntos finales de metadatos en la nube (por ejemplo, 169.254.169.254) o cualquier host accesible.
• Parche: sillytavern v1.18.0 incluye validación y restricciones para prevenir el control del atacante. baseUrl valores.

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

Posibles escenarios de explotación (nivel alto)

Ataques representativos para entender el riesgo (no se proporciona código de explotación):

• Recuperar metadatos de la nube: Solicitar puntos finales de metadatos para obtener credenciales o tokens (por ejemplo, AWS IMDS en 169.254.169.254).
• Acceder a interfaces administrativas internas: Acceder a APIs de gestión vinculadas a localhost o subredes internas.
• Escaneo de puertos / descubrimiento: Utilizar el host vulnerable para mapear rangos de IP internas y servicios.
• Eludir controles de red: Hacer que el servidor víctima realice solicitudes que están bloqueadas desde Internet.
• Exfiltración de datos: Consultar puntos finales de depuración internos y devolver datos sensibles a un punto final controlado por el atacante.

Cómo detectar intentos de explotación

La detección requiere correlacionar el tráfico web y la actividad saliente. Buscar:

• Registros del servidor web: Solicitudes con parámetros como baseUrl, proxy, url, objetivo. Valores largos, codificados o que contienen credenciales son sospechosos.
• Registros de aplicación: Direcciones de destino registradas para solicitudes salientes; picos en la frecuencia de solicitudes salientes.
• Registros de red saliente/egreso: Conexiones desde el proceso web a 169.254.169.254, 127.0.0.1, rangos RFC1918 o direcciones locales de enlace IPv6.
• Registros DNS: Consultas para subdominios aleatorios o patrones de resolución inusuales.
• Registros de WAF: Reglas que bloquean sospechosos baseUrl valores o patrones de IP privada.
• Comportamiento del proceso: Nuevos procesos o inesperados que realizan llamadas de red desde entornos PHP/Node, o picos de CPU/DNS.

Establecer líneas base para el comportamiento normal para que las desviaciones puedan ser detectadas de manera más confiable.

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

1. Parchear el software

   Si ejecutas SillyTavern o servicios que dependen de sillytavern, actualiza a v1.18.0 de inmediato. Esta es la solución correcta.

2. Si no puedes actualizar de inmediato, parche virtual

   Desplegar reglas WAF para detectar y bloquear el uso malicioso baseUrl y restringir el acceso público a los puntos finales que aceptan URLs de proxy.

3. Restringir conexiones salientes

   Aplicar reglas de egreso de host (grupos de seguridad en la nube, cortafuegos, iptables) para denegar tráfico saliente excepto a destinos 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 hay indicadores presentes, aislar el host afectado, preservar registros y buscar signos de robo de credenciales o persistencia.

5. Rotar credenciales y secretos (si es necesario)

   Si se pueden haber consultado metadatos o APIs de administración, rotar claves API y credenciales de servicio.

6. Monitorear acciones posteriores

   Estar atento a nuevas cuentas, configuraciones alteradas, archivos modificados o tareas programadas que indiquen actividad de seguimiento.

Mitigaciones WAF y reglas de ejemplo

A continuación se presentan ejemplos prácticos al estilo de ModSecurity para detectar y bloquear patrones comunes de SSRF. Pruebe estos en staging antes de producción; adáptelos a su entorno.

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

# Verificar el parámetro baseUrl que contenga IPs privadas o puntos finales de metadatos"
    

Propósito: Niega solicitudes donde baseUrl apunta a localhost, direcciones RFC1918, 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 de proxy repetidas

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

Integre con un limitador de tasa para reducir los intentos de explotación automatizados.

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

Si su WAF o proxy admite verificaciones externas, resuelva el nombre de host proporcionado y bloquee cuando se resuelva a IPs privadas. Esto requiere una implementación cuidadosa para evitar condiciones de carrera DNS.

Nota: Estos son patrones defensivos. Reducen la exposición pero no reemplazan el parcheo del paquete vulnerable.

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

Los desarrolladores que aceptan URLs externas o configuraciones de proxy deben adoptar estas prácticas:

• Lista blanca de hosts: Permitir solo un conjunto definido de nombres de host que la aplicación necesita contactar legítimamente.
• Rechazar esquemas no HTTP: Aceptar solo http and https donde sea apropiado.
• Habilitar la validación del host: Analizar y validar el componente del host; rechazar IPs en rangos privados.
• Prevenir credenciales incrustadas: No permitir URLs que contengan usuario:contraseña@host.
• Resolver y validar: Si se permiten nombres de host, resuélvelos y niega si las IPs resultantes son privadas. Usa un resolvedor seguro y considera condiciones de carrera.
• Tiempos de espera y límites: Establecer tiempos de espera para solicitudes y redirecciones máximas para evitar solicitudes de larga duración.
• Tratar la configuración como sensible: No usar valores proporcionados por el usuario directamente como configuración en tiempo de ejecución sin una validación estricta.

Estos son los tipos de mitigaciones que los mantenedores de SillyTavern implementaron en v1.18.0.

Protecciones a nivel de host y red

• Prevenir que los procesos web accedan a servicios solo internos a menos que sea explícitamente necesario. Usa reglas de firewall de salida del host, grupos de seguridad en la nube o proxies de salida.
• Bloquear el acceso a metadatos de la nube desde instancias de aplicación si no es requerido por la aplicación. Por ejemplo, bloquear el tráfico saliente a 169.254.169.254 desde el proceso web.
• Ejecutar servicios en redes segmentadas con redes de menor privilegio.
• Donde sea posible, enrutar solicitudes salientes a través de un proxy monitoreado que haga cumplir listas de permitidos y registre la actividad.

Los controles de red limitan a lo que un SSRF puede alcanzar incluso si la aplicación sigue siendo vulnerable por un período.

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

1. Preservar evidencia

   Capturar registros de web, aplicación, firewall, DNS y red. Asegurarse de que los registros no sean sobrescritos.

2. Contener

   Desactive la función vulnerable o coloque el host detrás de restricciones de IP. Elimine el acceso público temporalmente si es necesario.

3. Parche

   Actualice sillytavern a v1.18.0 o aplique la remediación recomendada por el proveedor.

4. Analizar

   Inspeccione los registros de acceso en busca de sospechas. baseUrl valores y verifique las conexiones salientes y las consultas DNS desde el host.

5. Rotar secretos

   Si los metadatos o credenciales pueden haber sido expuestos, rote las claves y tokens de API.

6. Escanear y limpiar

   Ejecute análisis de malware y verificaciones de integridad para detectar artefactos post-explotación.

7. Restaurar y monitorear

   Reanude las operaciones normales solo después de confirmar que el sistema está limpio. Aumente la supervisión durante al menos 30 días.

8. Informe

   Notifique a su equipo de seguridad, proveedor de alojamiento o clientes según lo requiera su política de respuesta a incidentes u obligaciones regulatorias.

Detección y ejemplos de registros para buscar.

Utilice estos indicadores al buscar en los registros o coordinar con su proveedor de alojamiento:

• Solicitudes con parámetros: ?baseUrl=, ?proxy=, ?target=, cuerpos POST/JSON que contengan. baseUrl or proxy_url.
• Valores de parámetros que contengan: 169.254.169.254, 127.0.0.1, localhost, 10., 172.16.–172.31., 192.168., fe80:, ::1, o el @ carácter (credenciales incrustadas).
• Picos en solicitudes salientes a rangos privados desde la IP de su servidor web.
• Registros de WAF que muestran activaciones de firma para patrones de SSRF.

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

Las reglas de WAF y el filtrado de salida son controles compensatorios. Reducen el riesgo pero no eliminan la vulnerabilidad subyacente. La remediación correcta es actualizar sillytavern a v1.18.0, que soluciona la causa raíz. Los parches virtuales pueden fallar si los atacantes modifican las cargas útiles o si los casos de uso legítimos eluden las reglas.

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

• Actualizar sillytavern a v1.18.0 (o posterior).
• Implementar reglas de WAF que bloqueen baseUrl apuntando a rangos privados, IPs de metadatos y credenciales incrustadas.
• Restringir el acceso a la red saliente para procesos web; bloquear los puntos finales de metadatos en la nube desde los procesos de aplicación.
• Revisar el código de la aplicación en busca de otros parámetros de URL proporcionados por el usuario y endurecer en consecuencia.
• Monitorear los registros en busca de uso sospechoso de proxies e implementar alertas para conexiones salientes anómalas.
• Rotar credenciales si se puede haber accedido a metadatos o puntos finales internos.
• Realizar una investigación completa y un escaneo de malware si se sospecha explotación.

Reflexiones finales

Las vulnerabilidades de SSRF son particularmente peligrosas porque permiten a un atacante utilizar su propia infraestructura como plataforma de reconocimiento y ataque. Para los operadores de WordPress que comparten infraestructura con servicios de Node.js o entornos mixtos, este SSRF de SillyTavern es un recordatorio para:

• Aplica el parche de inmediato.
• Usar WAFs como parches virtuales temporales mientras actualiza.
• Endurecer las reglas de salida y la segmentación de la red.
• Monitorear los registros y estar preparado para responder.

Si necesita ayuda para evaluar la exposición o aplicar mitigaciones, contrate a un asesor de seguridad de confianza o al equipo de respuesta a incidentes de su proveedor de alojamiento. Manténgase alerta: mantenga el software actualizado, valide las entradas y limite lo que cada servidor puede acceder en la red.