Vulnerabilidades

OpenSTAManager es un software de gestión de código abierto para asistencia técnica y facturación. En la versión 2.9.8 y anteriores, existe una vulnerabilidad de inyección SQL en el Módulo Stampe. Al momento de la publicación, no existe ningún parche conocido.

OpenSTAManager es un software de gestión de código abierto para asistencia técnica y facturación. En la versión 2.9.8 y anteriores, existe una vulnerabilidad de inyección SQL en el endpoint ajax_complete.php al manejar la operación get_sedi. Un atacante autenticado puede inyectar código SQL malicioso a través del parámetro idanagrafica, lo que lleva a un acceso no autorizado a la base de datos. En el momento de la publicación, no existe ningún parche conocido.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.9 y 2.2.1, existía una vulnerabilidad de cross-site scripting (XSS) en un componente de renderizado de markdown utilizado en la interfaz de n8n, incluyendo notas adhesivas de flujos de trabajo y otras áreas que admiten contenido markdown. Un usuario autenticado con permiso para crear o modificar flujos de trabajo podría abusar de esto para ejecutar scripts con privilegios del mismo origen cuando otros usuarios interactúan con un flujo de trabajo creado maliciosamente. Esto podría llevar al secuestro de sesión y a la toma de control de cuenta. Este problema ha sido parcheado en las versiones 1.123.9 y 2.2.1.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.118.0 y 2.4.0, una vulnerabilidad en el modo de consulta SQL del nodo Merge permitía a usuarios autenticados con permiso para crear o modificar flujos de trabajo escribir archivos arbitrarios en el sistema de archivos del servidor n8n, lo que podría conducir a la ejecución remota de código. Este problema ha sido parcheado en las versiones 1.118.0 y 2.4.0.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.18 y 2.5.0, una vulnerabilidad en los controles de acceso a archivos permite a usuarios autenticados con permiso para crear o modificar flujos de trabajo leer archivos sensibles del sistema anfitrión de n8n. Esto puede ser explotado para obtener datos de configuración críticos y credenciales de usuario, lo que lleva a una toma de control completa de la cuenta de cualquier usuario en la instancia. Este problema ha sido parcheado en las versiones 1.123.18 y 2.5.0.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.10 y 2.5.0, las vulnerabilidades en el nodo Git permitían a usuarios autenticados con permiso para crear o modificar flujos de trabajo ejecutar comandos de sistema arbitrarios o leer archivos arbitrarios en el host de n8n. Este problema ha sido parcheado en las versiones 1.123.10 y 2.5.0.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.12 y 2.4.0, cuando los flujos de trabajo procesan archivos cargados y los transfieren a servidores remotos a través del nodo SSH sin validar sus metadatos, la vulnerabilidad puede llevar a que los archivos se escriban en ubicaciones no deseadas en esos sistemas remotos, lo que podría llevar a la ejecución remota de código en esos sistemas. Como prerrequisito, un atacante no autenticado necesita conocimiento de la existencia de dichos flujos de trabajo y los puntos finales para la carga de archivos deben estar no autenticados. Este problema ha sido parcheado en las versiones 1.123.12 y 2.4.0.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de la versión 2.4.8, una vulnerabilidad en el nodo de Código Python permite a los usuarios autenticados escapar del entorno sandbox de Python y ejecutar código fuera del límite de seguridad previsto. Este problema ha sido parcheado en la versión 2.4.8.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.17 y 2.5.2, 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. Este problema ha sido parcheado en las versiones 1.123.17 y 2.5.2.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de la versión 1.123.2, se ha identificado una vulnerabilidad de cross-site scripting (XSS) en el manejo de respuestas de webhook y puntos finales HTTP relacionados. Bajo ciertas condiciones, la protección sandbox de la Política de Seguridad de Contenido (CSP) destinada a aislar respuestas HTML puede no aplicarse correctamente. Un usuario autenticado con permiso para crear o modificar flujos de trabajo podría abusar de esto para ejecutar scripts maliciosos con privilegios de mismo origen cuando otros usuarios interactúan con el flujo de trabajo manipulado. Esto podría llevar a secuestro de sesión y toma de control de cuenta. Este problema ha sido parcheado en la versión 1.123.2.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: arm64/fpsimd: señal: Corrección de la restauración del contexto SVE Cuando SME es compatible, la restauración del contexto de señal SVE puede salir mal de varias maneras, incluyendo colocar la tarea en un estado inválido donde el kernel puede leer de memoria fuera de límites (y puede potencialmente sufrir una falla fatal) y/o puede terminar la tarea con un SIGKILL. (1) Restaurar un contexto con SVE_SIG_FLAG_SM establecido puede colocar la tarea en un estado inválido donde SVCR.SM está establecido (y sve_state no es NULL) pero TIF_SME está despejado, lo que consecuentemente resulta en lecturas de memoria fuera de límites y/o la terminación de la tarea con SIGKILL. Esto solo puede ocurrir en casos inusuales (pero legítimos) donde el contexto de señal SVE ha sido modificado por el espacio de usuario o fue guardado en el contexto de otra tarea (p. ej., como con CRIU), ya que de lo contrario la presencia de un contexto de señal SVE con SVE_SIG_FLAG_SM implica que TIF_SME ya está establecido. Mientras en este estado, task_fpsimd_load() NO configurará SMCR_ELx (dejando algún valor arbitrario configurado en hardware) antes de restaurar SVCR e intentar restaurar los registros SVE en modo streaming desde la memoria a través de sve_load_state(). Como el valor de SMCR_ELx.LEN puede ser mayor que la longitud del vector SVE en modo streaming de la tarea, esto puede leer memoria fuera del sve_state asignado a la tarea, leyendo datos no relacionados y/o desencadenando una falla. Si bien esto puede resultar en la carga de secretos en los registros SVE en modo streaming, estos valores nunca son expuestos. Como TIF_SME está despejado, fpsimd_bind_task_to_cpu() configurará CPACR_ELx.SMEN para atrapar accesos EL0 a los registros SVE en modo streaming, por lo que estos no pueden ser accedidos directamente en EL0. Como fpsimd_save_user_state() verifica la longitud del vector en vivo antes de guardar el estado (S)SVE en memoria, ningún valor secreto puede ser guardado de nuevo en memoria (y por lo tanto no puede ser observado a través de ptrace, señales, etc.). Cuando la longitud del vector en vivo no coincide con la longitud del vector esperada para la tarea, fpsimd_save_user_state() enviará una señal SIGKILL fatal a la tarea. Por lo tanto, la tarea puede ser terminada después de ejecutar el espacio de usuario por algún período de tiempo. (2) Restaurar un contexto con SVE_SIG_FLAG_SM despejado no despeja el SVCR.SM de la tarea. Si SVCR.SM estaba establecido antes de restaurar el contexto, entonces la tarea quedará en modo streaming inesperadamente, y algún estado de registro se combinará de manera inconsistente, aunque la tarea quedará en un estado legítimo desde el punto de vista del kernel. Esto solo puede ocurrir en casos inusuales (pero legítimos) donde ptrace ha sido usado para establecer SVCR.SM después de la entrada a la llamada al sistema sigreturn, ya que la entrada a la llamada al sistema despeja SVCR.SM. En estos casos, los datos de registro SVE proporcionados se cargarán en el sve_state de la tarea usando la longitud del vector SVE no-streaming y los registros FPSIMD se fusionarán en esto usando la longitud del vector SVE en modo streaming. Solución para (1) estableciendo TIF_SME al establecer SVCR.SM. Esto también requiere asegurar que el sme_state de la tarea ha sido asignado, pero como esto podría contener estado ZA en vivo, no debe ser puesto a cero. Solución para (2) despejando SVCR.SM al restaurar un contexto de señal SVE con SVE_SIG_FLAG_SM despejado. Para consistencia, he adelantado la manipulación de SVCR, TIF_SVE, TIF_SME y fp_type, inmediatamente después de la asignación de sve_state/sme_state, antes de la restauración del estado de registro real. Esto facilita asegurar que estos siempre se modifiquen de manera consist

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipvlan: Hacer que el addrs_lock sea por puerto<br /> <br /> Hacer que el addrs_lock sea por puerto, no por dispositivo ipvlan.<br /> <br /> El código inicial parece estar escrito bajo la suposición de que cualquier cambio de dirección debe ocurrir bajo RTNL. Pero no es así para el caso de IPv6. Así que<br /> <br /> 1) Introducir addrs_lock por puerto.<br /> <br /> 2) Fue necesario corregir lugares donde se olvidó tomar el bloqueo (ipvlan_open/ipvlan_close)<br /> <br /> Esto parece ser un problema muy menor, sin embargo. Ya que es muy poco probable que ipvlan_add_addr() sea llamado en 2 CPU simultáneamente. Pero, sin embargo, esto podría causar:<br /> <br /> 1) Falso negativo de ipvlan_addr_busy(): una interfaz iteró a través de todos los port-&amp;gt;ipvlans + ipvlan-&amp;gt;addrs bajo algún spinlock de ipvlan, y otra añadió IP bajo su propio bloqueo. Aunque esto solo es posible para IPv6, ya que parece que solo ipvlan_addr6_event() puede ser llamado sin rtnl_lock.<br /> <br /> 2) Condición de carrera ya que ipvlan_ht_addr_add(port) es llamado bajo diferentes bloqueos ipvlan-&amp;gt;addrs_lock.<br /> <br /> Esto no debería afectar el rendimiento, ya que añadir/eliminar IP es una situación rara y el spinlock no se toma en rutas rápidas.