Vulnerabilidades

TinyWeb es un servidor web (HTTP, HTTPS) escrito en Delphi para Win32. Las versiones anteriores a la versión 2.02 tienen una vulnerabilidad de denegación de servicio (DoS) a través del agotamiento de la memoria. Atacantes remotos no autenticados pueden enviar una solicitud POST HTTP al servidor con una cabecera 'Content-Length' excepcionalmente grande (p. ej., '2147483647'). El servidor asigna continuamente memoria para el cuerpo de la solicitud ('EntityBody') mientras transmite la carga útil sin imponer ningún límite máximo, lo que lleva a que toda la memoria disponible sea consumida y provoca la caída del servidor. Cualquiera que aloje servicios usando TinyWeb se ve afectado. La versión 2.02 corrige el problema. El parche introduce un límite 'CMaxEntityBodySize' (establecido en 10MB) para el tamaño máximo de las cargas útiles aceptadas. Como solución alternativa temporal si la actualización no es posible de inmediato, considere colocar el servidor detrás de un Cortafuegos de Aplicaciones Web (WAF) o un proxy inverso (como nginx o Cloudflare) configurado para limitar explícitamente el tamaño máximo permitido del cuerpo de la solicitud HTTP (p. ej., 'client_max_body_size' en nginx).

TinyWeb es un servidor web (HTTP, HTTPS) escrito en Delphi para Win32. Las versiones anteriores a la 2.02 son vulnerables a un ataque de denegación de servicio (DoS) conocido como Slowloris. El servidor genera un nuevo hilo del sistema operativo para cada conexión entrante sin imponer un límite máximo de concurrencia o un tiempo de espera de solicitud adecuado. Un atacante remoto no autenticado puede agotar los límites de concurrencia del servidor y la memoria abriendo numerosas conexiones y enviando datos excepcionalmente lento (por ejemplo, 1 byte cada pocos minutos). Cualquiera que aloje servicios usando TinyWeb se ve afectado. La versión 2.02 corrige el problema. El parche introduce un límite 'CMaxConnections' (establecido en 512) y un tiempo de espera de inactividad 'CConnectionTimeoutSecs' (establecido en 30 segundos). Como solución alternativa temporal si la actualización no es posible de inmediato, considere colocar el servidor detrás de un proxy inverso robusto o un cortafuegos de aplicaciones web (WAF) como nginx, HAProxy o Cloudflare, configurado para almacenar en búfer las solicitudes incompletas y aplicar agresivamente los límites y tiempos de espera de conexión.

Fleet es un software de gestión de dispositivos de código abierto. Una vulnerabilidad de inyección SQL en versiones anteriores a la 4.80.1 permitía a usuarios autenticados inyectar expresiones SQL arbitrarias a través del parámetro de consulta `order_key`. Debido al uso inseguro de `goqu.I()` al construir la cláusula `ORDER BY`, una entrada especialmente diseñada podría evadir el entrecomillado de identificadores y ser interpretada como SQL ejecutable. Un atacante autenticado con acceso al endpoint afectado podría inyectar expresiones SQL en la consulta MySQL subyacente. Aunque la inyección ocurre en un contexto `ORDER BY`, es suficiente para habilitar técnicas de inyección SQL ciega que pueden divulgar información de la base de datos a través de expresiones condicionales que afectan el orden de los resultados. Las expresiones diseñadas también pueden causar una computación excesiva o fallos en las consultas, lo que podría llevar a un rendimiento degradado o a una denegación de servicio. No se demostró evidencia directa de modificación de datos fiable o ejecución de consultas apiladas. La versión 4.80.1 corrige el problema. Si una actualización inmediata no es posible, los usuarios deben restringir el acceso al endpoint afectado solo a roles de confianza y asegurarse de que cualquier parámetro de ordenación o columna proporcionado por el usuario esté estrictamente en una lista blanca en la capa de aplicación o proxy.

TinyWeb es un servidor web (HTTP, HTTPS) escrito en Delphi para Win32. Una vulnerabilidad en versiones anteriores a la 2.01 permite a atacantes remotos no autenticados eludir los controles de seguridad de parámetros CGI del servidor web. Dependiendo de la configuración del servidor y del ejecutable CGI específico en uso, el impacto es la divulgación de código fuente o la ejecución remota de código (RCE). Cualquiera que aloje scripts CGI (particularmente lenguajes interpretados como PHP) usando versiones vulnerables de TinyWeb está afectado. El problema ha sido parcheado en la versión 2.01. Si la actualización no es posible de inmediato, asegúrese de que `STRICT_CGI_PARAMS` esté habilitado (está definido por defecto en `define.inc`) y/o no utilice ejecutables CGI que acepten de forma nativa indicadores de línea de comandos peligrosos (como `php-cgi.exe`). Si aloja PHP, considere colocar el servidor detrás de un cortafuegos de aplicaciones web (WAF) que bloquee explícitamente los parámetros de cadena de consulta de URL que comienzan con un guion (`-`) o contienen comillas dobles codificadas (`%22`).

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 2.10.1, 2.9.3 y 1.123.22, un usuario autenticado con permiso para crear o modificar flujos de trabajo podía inyectar scripts arbitrarios en páginas renderizadas por la aplicación n8n utilizando diferentes técnicas en varios nodos (nodo Form Trigger, nodo Chat Trigger, nodo Send & Wait, nodo Webhook y nodo Chat). Los scripts inyectados por un flujo de trabajo malicioso se ejecutan en el navegador de cualquier usuario que visite la página afectada, lo que permite el secuestro de sesión y la toma de control de cuentas. Los problemas se han solucionado en las versiones de n8n 2.10.1 y 1.123.21. Los usuarios deben actualizar a una de estas versiones o posteriores para remediar la vulnerabilidad. Si la actualización no es posible de inmediato, los administradores deben considerar las siguientes mitigaciones temporales. Limite los permisos de creación y edición de flujos de trabajo solo a usuarios de plena confianza, y/o deshabilite el nodo Webhook añadiendo 'n8n-nodes-base.webhook' a la variable de entorno 'NODES_EXCLUDE'. Estas soluciones provisionales no remedian completamente el riesgo y solo deben utilizarse como medidas de mitigación a corto plazo.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 2.2.0 y 1.123.8, un usuario autenticado con permiso para crear o modificar flujos de trabajo podía encadenar el nodo Read/Write Files from Disk con operaciones git para lograr la ejecución remota de código. Al escribir en archivos de configuración específicos y luego activar una operación git, el atacante podía ejecutar comandos de shell arbitrarios en el host de n8n. El problema ha sido solucionado en las versiones 2.2.0 y 1.123.8 de n8n. Los usuarios deben actualizar a una de estas versiones o posteriores para remediar la vulnerabilidad. Si la actualización no es posible de inmediato, los administradores deben considerar las siguientes mitigaciones temporales. Limite los permisos de creación y edición de flujos de trabajo solo a usuarios de plena confianza, y/o deshabilite el nodo Read/Write Files from Disk añadiendo 'n8n-nodes-base.readWriteFile' a la variable de entorno 'NODES_EXCLUDE'. Estas soluciones provisionales no remedian completamente el riesgo y solo deben usarse como medidas de mitigación a corto plazo.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 2.10.1, 2.9.3 y 1.123.22, un usuario autenticado con permiso para crear o modificar flujos de trabajo podría aprovechar el modo de consulta SQL del nodo Merge para ejecutar código arbitrario y escribir archivos arbitrarios en el servidor n8n. Los problemas se han solucionado en las versiones de n8n 2.10.1, 2.9.3 y 1.123.22. Los usuarios deben actualizar a una de estas versiones o posteriores para remediar todas las vulnerabilidades conocidas. Si la actualización no es posible de inmediato, los administradores deben considerar las siguientes mitigaciones temporales. Limitar los permisos de creación y edición de flujos de trabajo solo a usuarios de plena confianza, y/o deshabilitar el nodo Merge añadiendo 'n8n-nodes-base.merge' a la variable de entorno 'NODES_EXCLUDE'. Estas soluciones provisionales no remedian completamente el riesgo y solo deben usarse como medidas de mitigación a corto plazo.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 2.10.1, 2.9.3 y 1.123.22, se han identificado y parcheado exploits adicionales en la evaluación de expresiones de n8n tras CVE-2025-68613. Un usuario autenticado con permiso para crear o modificar flujos de trabajo podría abusar de expresiones manipuladas en los parámetros del flujo de trabajo para desencadenar la ejecución no intencionada de comandos del sistema en el host que ejecuta n8n. Los problemas han sido solucionados en las versiones de n8n 2.10.1, 2.9.3 y 1.123.22. Los usuarios deberían actualizar a una de estas versiones o posteriores para remediar todas las vulnerabilidades conocidas. Si la actualización no es posible de inmediato, los administradores deberían considerar las siguientes mitigaciones temporales. Limitar los permisos de creación y edición de flujos de trabajo solo a usuarios de plena confianza, y/o desplegar n8n en un entorno endurecido con privilegios de sistema operativo y acceso a la red restringidos para reducir el impacto de una posible explotación. Estas soluciones provisionales no remedian completamente el riesgo y solo deberían usarse como medidas de mitigación a corto plazo.

Una vulnerabilidad ha sido encontrada en fosrl Pangolin hasta 1.15.4-s.3. Esto afecta a la función verifyRoleAccess/verifyApiKeyRoleAccess del componente Gestor de Roles. La manipulación conduce a controles de acceso inadecuados. La explotación remota del ataque es posible. El exploit ha sido revelado al público y puede ser utilizado. Actualizar a la versión 1.15.4-s.4 mitiga este problema. El identificador del parche es 5e37c4e85fae68e756be5019a28ca903b161fdd5. Se aconseja actualizar el componente afectado.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Prior a las versiones 2.10.1, 2.9.3 y 1.123.22, un usuario autenticado con permiso para crear o modificar flujos de trabajo podría explotar una vulnerabilidad en el sandbox de JavaScript Task Runner para ejecutar código arbitrario fuera del límite del sandbox. En instancias que utilizan Task Runners internos (modo de ejecutor predeterminado), esto podría resultar en un compromiso total del host de n8n. En instancias que utilizan Task Runners externos, el atacante podría obtener acceso o impactar otras tareas ejecutadas en el Task Runner. Los Task Runners deben habilitarse usando 'N8N_RUNNERS_ENABLED=true'. El problema ha sido solucionado en las versiones de n8n 2.10.1, 2.9.3 y 1.123.22. Los usuarios deben actualizar a una de estas versiones o posteriores para remediar la vulnerabilidad. Si la actualización no es posible de inmediato, los administradores deben considerar las siguientes mitigaciones temporales. Limitar los permisos de creación y edición de flujos de trabajo solo a usuarios de plena confianza, y/o usar el modo de ejecutor externo ('N8N_RUNNERS_MODE=external') para limitar el radio de impacto. Estas soluciones provisionales no remedian completamente el riesgo y solo deben usarse como medidas de mitigación a corto plazo.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 2.10.1, 2.9.3 y 1.123.22, un usuario autenticado con permiso para crear o modificar flujos de trabajo podía usar el nodo de Código Python para escapar del sandbox. El sandbox no restringía suficientemente el acceso a ciertos objetos Python incorporados, permitiendo a un atacante exfiltrar contenidos de archivos o lograr RCE. En instancias que usan Task Runners internos (modo de ejecutor predeterminado), esto podría resultar en un compromiso total del host de n8n. En instancias que usan Task Runners externos, el atacante podría obtener acceso o impactar otras tareas ejecutadas en el Task Runner. Los Task Runners deben habilitarse usando `N8N_RUNNERS_ENABLED=true`. El problema ha sido solucionado en las versiones de n8n 2.10.1, 2.9.3 y 1.123.22. Los usuarios deben actualizar a esta versión o posterior para remediar la vulnerabilidad. Si la actualización no es posible de inmediato, los administradores deben considerar las siguientes mitigaciones temporales. Limitar los permisos de creación y edición de flujos de trabajo solo a usuarios de plena confianza, y/o deshabilitar el nodo de Código añadiendo `n8n-nodes-base.code` a la variable de entorno `NODES_EXCLUDE`. Estas soluciones provisionales no remedian completamente el riesgo y solo deben usarse como medidas de mitigación a corto plazo.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 2.10.1, 2.9.3 y 1.123.22, existía una vulnerabilidad de inyección de expresiones de segundo orden en los nodos de formulario de n8n que podría permitir a un atacante no autenticado inyectar y evaluar expresiones n8n arbitrarias al enviar datos de formulario manipulados. Cuando se encadena con un escape de sandbox de expresiones, esto podría escalar a ejecución remota de código en el host n8n. La vulnerabilidad requiere una configuración de flujo de trabajo específica para ser explotable. Primero, un nodo de formulario con un campo que interpola un valor proporcionado por un usuario no autenticado, p. ej., un valor enviado en un formulario. Segundo, el valor del campo debe comenzar con un carácter '=', lo que hizo que n8n lo tratara como una expresión y desencadenara una doble evaluación del contenido del campo. No hay una razón práctica para que un diseñador de flujo de trabajo prefije un campo con '=' intencionalmente — el carácter no se renderiza en la salida, por lo que el resultado no coincidiría con las expectativas del diseñador. Si se añade accidentalmente, sería notorio y muy poco probable que persistiera. Un atacante no autenticado necesitaría conocer esta circunstancia específica en una instancia objetivo o descubrir un formulario coincidente por casualidad. Incluso cuando se cumplen las precondiciones, la inyección de expresiones por sí sola se limita a los datos accesibles dentro del contexto de expresiones de n8n. La escalada a ejecución remota de código requiere encadenarse con una vulnerabilidad de escape de sandbox separada. El problema ha sido solucionado en las versiones de n8n 2.10.1, 2.9.3 y 1.123.22. Los usuarios deben actualizar a una de estas versiones o posteriores para remediar la vulnerabilidad. Si la actualización no es posible de inmediato, los administradores deben considerar las siguientes mitigaciones temporales. Revisar manualmente el uso de los nodos de formulario para las precondiciones mencionadas anteriormente, deshabilitar el nodo Formulario añadiendo 'n8n-nodes-base.form' a la variable de entorno 'NODES_EXCLUDE', y/o deshabilitar el nodo Form Trigger añadiendo 'n8n-nodes-base.formTrigger' a la variable de entorno 'NODES_EXCLUDE'. Estas soluciones alternativas no remedian completamente el riesgo y solo deben usarse como medidas de mitigación a corto plazo.