Vulnerabilidades

NATS-Server es un servidor de alto rendimiento para NATS.io, un sistema de mensajería nativo de la nube y del borde. Antes de las versiones 2.11.14 y 2.12.5, si el nats-server tiene la configuración 'leafnode' habilitada (no predeterminada), entonces cualquiera que pueda conectarse puede bloquear el nats-server al desencadenar un pánico. Esto ocurre antes de la autenticación y requiere que la compresión esté habilitada (lo cual está habilitado, por defecto, cuando se usan leafnodes). Las versiones 2.11.14 y 2.12.5 contienen una corrección. Como solución alternativa, deshabilite la compresión en el puerto leafnode.

NATS-Server es un servidor de alto rendimiento para NATS.io, un sistema de mensajería nativo de la nube y del borde. A partir de la versión 2.2.0 y antes de las versiones 2.11.14 y 2.12.5, una comprobación de cordura faltante en un marco de WebSockets podría desencadenar un pánico del servidor en el nats-server. Esto ocurre antes de la autenticación, y por lo tanto está expuesto a cualquiera que pueda conectarse al puerto de websockets. Las versiones 2.11.14 y 2.12.5 contienen una corrección. Una solución alternativa está disponible. La vulnerabilidad solo afecta a las implementaciones que usan WebSockets y que exponen el puerto de red a puntos finales no confiables. Si uno es capaz de hacerlo, una defensa en profundidad de restringir cualquiera de estos mitigará el ataque.

Un problema en mtrojnar Osslsigncode afectado en v2.10 y anteriores permite a un atacante remoto escalar privilegios a través del componente osslsigncode.c

IBM Concert 1.0.0 hasta 2.2.0 contiene credenciales codificadas de forma rígida que podrían ser obtenidas por un usuario local.

IBM InfoSphere Information Server 11.7.0.0 hasta 11.7.1.6 podría permitir a un atacante obtener información sensible debido a credenciales insuficientemente protegidas.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 2.6.4 y 1.123.23, un usuario autenticado sin permiso para listar secretos externos podía referenciar un secreto por el nombre externo en una credencial y recuperar su valor en texto plano al guardar la credencial. Esto eludía la verificación de permisos 'externalSecret:list' y permitía el acceso a secretos almacenados en bóvedas conectadas sin privilegios de administrador o propietario. Este problema requiere que la instancia tenga una bóveda de secretos externos configurada. El atacante debe conocer o ser capaz de adivinar el nombre de un secreto objetivo. El problema ha sido solucionado en las versiones 1.123.23 y 2.6.4 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: Restringir el acceso a n8n solo a usuarios de plena confianza, y/o deshabilitar la integración de secretos externos hasta que se pueda aplicar el parche. 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 la versión 2.5.0, cuando la característica de Control de Código Fuente está configurada para usar SSH, el comando SSH utilizado para las operaciones de git deshabilitaba explícitamente la verificación de la clave de host. Un atacante de red posicionado entre la instancia de n8n y el servidor Git remoto podría interceptar la conexión y presentar una clave de host fraudulenta, inyectando potencialmente contenido malicioso en los flujos de trabajo o interceptando datos del repositorio. Este problema solo afecta a las instancias donde la característica de Control de Código Fuente ha sido explícitamente habilitada y configurada para usar SSH (no predeterminada). El problema ha sido solucionado en la versión 2.5.0 de n8n. 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: Deshabilitar la característica de Control de Código Fuente si no es activamente requerida, y/o restringir el acceso a la red para asegurar que la instancia de n8n se comunique con el servidor Git solo a través de rutas de red confiables y controladas. 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 1.123.27, 2.13.3 y 2.14.1, un usuario autenticado con permiso para crear o modificar flujos de trabajo podía elaborar un flujo de trabajo que produjera un objeto de datos binarios HTML sin un nombre de archivo. El endpoint `/rest/binary-data` servía dichas respuestas en línea en el origen de n8n sin los encabezados `Content-Disposition` o `Content-Security-Policy`, permitiendo que el HTML se renderizara en el navegador con acceso completo a JavaScript del mismo origen. Al enviar la URL resultante a un usuario con mayores privilegios, un atacante podría ejecutar JavaScript en la sesión autenticada de la víctima, lo que permitiría la exfiltración de flujos de trabajo y credenciales, la modificación de flujos de trabajo o la escalada de privilegios a administrador. El problema ha sido solucionado en las versiones de n8n 1.123.27, 2.13.3 y 2.14.1. 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 restringir el acceso a la red a la instancia de n8n para evitar que usuarios no confiables accedan a las URL de datos binarios. 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 1.123.27, 2.13.3 y 2.14.1, un fallo en la lógica de escape de filtros del nodo LDAP permitía que los metacaracteres LDAP pasaran sin escapar cuando la entrada controlada por el usuario se interpolaba en los filtros de búsqueda LDAP. En flujos de trabajo donde la entrada de usuario externa se pasa a través de expresiones a los parámetros de búsqueda del nodo LDAP, un atacante podría manipular el filtro construido para recuperar registros LDAP no deseados o eludir las comprobaciones de autenticación implementadas en el flujo de trabajo. La explotación requiere una configuración de flujo de trabajo específica. El nodo LDAP debe usarse con entrada controlada por el usuario pasada a través de expresiones (por ejemplo, desde un formulario o webhook). El problema se ha solucionado en las versiones de n8n 1.123.27, 2.13.3 y 2.14.1. 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, deshabilitar el nodo LDAP añadiendo `n8n-nodes-base.ldap` a la variable de entorno `NODES_EXCLUDE`, y/o evitar pasar entrada de usuario externa no validada a los parámetros de búsqueda del nodo LDAP a través de expresiones. Estas soluciones provisionales no remedian completamente el riesgo y solo deben usarse como medidas de mitigación a corto plazo.

Un archivo TIFF creado maliciosamente puede provocar que la decodificación de la imagen intente asignar hasta 4 GiB de memoria, causando un consumo excesivo de recursos o un error de falta de memoria.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de la versión 2.8.0, cuando la variable de entorno `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK` se establece en `true`, el gestor de callback de OAuth omite la verificación de propiedad del parámetro de estado de OAuth. Esto permite a un atacante engañar a una víctima para que complete un flujo de OAuth contra un objeto de credencial que el atacante controla, haciendo que los tokens de OAuth de la víctima se almacenen en la credencial del atacante. El atacante puede entonces usar esos tokens para ejecutar flujos de trabajo en su nombre. Este problema solo afecta a las instancias donde `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true` está configurado explícitamente (no predeterminado). El problema ha sido solucionado en la versión 2.8.0 de n8n. 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: Evitar habilitar `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true` a menos que sea estrictamente necesario, y/o restringir el acceso a la instancia de n8n solo a usuarios de plena confianza. Estas soluciones provisionales no remedian completamente el riesgo y solo deben usarse como medidas de mitigación a corto plazo.

Modoboa es una plataforma de alojamiento y gestión de correo. Antes de la versión 2.7.1, `exec_cmd()` en `modoboa/lib/sysutils.py` siempre ejecuta llamadas a subprocesos con `shell=True`. Dado que los nombres de dominio fluyen directamente a las cadenas de comandos de shell sin ninguna sanitización, un Revendedor o SuperAdministrador puede incluir metacaracteres de shell en un nombre de dominio para ejecutar comandos arbitrarios del sistema operativo en el servidor. La versión 2.7.1 corrige el problema.