Vulnerabilidades

Flowise es una interfaz de usuario de arrastrar y soltar para construir un flujo de modelo de lenguaje grande personalizado. Antes de la versión 3.1.2, cuando las credenciales se obtienen con un parámetro de filtro credentialName, el campo encryptedData no se elimina de la respuesta. El código omite correctamente encryptedData cuando no se usa ningún filtro, pero no lo hace cuando se usa un filtro. Este problema ha sido parcheado en la versión 3.1.2.

Flowise es una interfaz de usuario de arrastrar y soltar para construir un flujo de modelo de lenguaje grande personalizado. Antes de la versión 3.1.2, todos los puntos finales CRUD para el almacén de vectores de asistentes de OpenAI no tienen middleware de autenticación y la ruta /api/v1/openai-assistants-vector-store no está en WHITELIST_URLS. Sin embargo, tampoco está protegida por el middleware de autenticación principal cuando se accede a través de una clave API - la ruta requiere autenticación con clave API (no incluida en la lista blanca), pero no existen comprobaciones de permisos en ninguna operación. Este problema ha sido parcheado en la versión 3.1.2.

Flowise es una interfaz de usuario de arrastrar y soltar para construir un flujo de modelo de lenguaje grande personalizado. Antes de la versión 3.1.2, la asignación masiva de creación y actualización de asistentes permite la toma de control de asistentes entre espacios de trabajo. Este problema ha sido parcheado en la versión 3.1.2.

Flowise es una interfaz de usuario de arrastrar y soltar para construir un flujo de modelo de lenguaje grande personalizado. Antes de la versión 3.1.2, la asignación masiva de creación y actualización de CustomTemplate permite la toma de control de plantillas entre espacios de trabajo. Este problema ha sido parcheado en la versión 3.1.2.

Vulnerabilidad de lectura fuera de límites en Servidor HTTP Apache con mod_headers y mod_mime y múltiples idiomas de respuesta.<br /> <br /> Este problema afecta a Servidor HTTP Apache: desde 2.4.0 hasta 2.4.67.

Vulnerabilidad de gestión de privilegios inadecuada en el Servidor HTTP Apache 2.4.67 y anteriores permite a los autores locales de .htaccess leer archivos con los privilegios del usuario httpd.<br /> <br /> Este problema afecta al Servidor HTTP Apache: hasta la 2.4.67.<br /> <br /> Se recomienda a los usuarios actualizar a la versión 2.4.68, que corrige el problema.

Bucle con condición de salida inalcanzable (&amp;#39;Bucle infinito&amp;#39;) vulnerabilidad en el módulo mod_proxy_ftp en el Servidor HTTP Apache con un servidor FTP de backend controlado por el atacante.<br /> <br /> Este problema afecta a indefinido: desde 2.4.0 hasta 2.4.67.<br /> <br /> Se recomienda a los usuarios actualizar a la versión 2.4.68, que corrige el problema.

Vulnerabilidad de escritura insuficiente de búfer en el Servidor HTTP Apache en expresiones regulares manipuladas en la configuración.<br /> <br /> Este problema afecta al Servidor HTTP Apache: desde 2.4.0 hasta 2.4.67.<br /> <br /> Se recomienda a los usuarios actualizar a la versión 2.4.68, la cual corrige el problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> io-wq: verificar que el predecesor esté hasheado en io_wq_remove_pending()<br /> <br /> io_wq_remove_pending() necesita corregir wq-&gt;hash_tail[] si el trabajo cancelado era la cola de su cubo hash. Al hacer esto, verifica si la entrada precedente en acct-&gt;work_list tiene el mismo valor hash, pero nunca verifica que el predecesor esté hasheado en absoluto. io_get_work_hash() es simplemente atomic_read(&amp;work-&gt;flags) &gt;&gt; IO_WQ_HASH_SHIFT, y los bits hash nunca se establecen para trabajos no hasheados, por lo que devuelve 0. Así, cuando un trabajo hasheado del cubo 0 es cancelado mientras que un trabajo no hasheado es su predecesor en la lista, la verificación pasa de forma espuria y un puntero al io_kiocb no hasheado se almacena en wq-&gt;hash_tail[0].<br /> <br /> Debido a que el trabajo no hasheado se desencola a través de la ruta rápida en io_get_next_work(), que nunca toca hash_tail[], el puntero obsoleto nunca se borra. Por lo tanto, después de que el io_kiocb no hasheado se completa y se libera de nuevo a req_cachep, wq-&gt;hash_tail[0] es un puntero colgante. El io_wq es por tarea (tctx-&gt;io_wq) y sobrevive a la apertura/cierre del anillo, por lo que el puntero colgante persiste durante la vida útil de la tarea; la siguiente encolación hasheada del cubo 0 lo desreferencia en io_wq_insert_work() y wq_list_add_after() escribe a través de memoria liberada.<br /> <br /> Añadir la verificación io_wq_is_hashed() faltante para que un predecesor no hasheado nunca herede una ranura hash_tail[].

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Bluetooth: hci_uart: corrige UAFs y condiciones de carrera en las rutas de cierre e inicialización<br /> <br /> Se observaron vulnerabilidades que conducen a condiciones de Uso Después de Liberación (UAF) y Desreferencia de Puntero Nulo (NPD) en la gestión del ciclo de vida de hci_uart.<br /> <br /> El problema principal surge porque las colas de trabajo (workqueues) (init_ready y write_work) solo se vacían/cancelan si la bandera HCI_UART_PROTO_READY está establecida durante el cierre de TTY. Si ocurre un cuelgue antes de que se complete la configuración, hci_uart_tty_close() omite la desinstalación de estas colas de trabajo y procede a liberar la estructura &amp;#39;hu&amp;#39;. Cuando el trabajo programado se ejecuta más tarde, desreferencia ciegamente la estructura &amp;#39;hu&amp;#39; liberada.<br /> <br /> Además, se identificaron varias condiciones de carrera de datos y UAFs en la secuencia de desinstalación:<br /> 1. Llamar a hci_uart_flush() desde hci_uart_close() sin deshabilitar efectivamente write_work causa una condición de carrera donde ambos pueden liberar doblemente hu-&gt;tx_skb de forma concurrente. Esto sucede porque los temporizadores del protocolo pueden invocar concurrentemente hci_uart_tx_wakeup() y volver a encolar write_work.<br /> 2. Llamar a hci_free_dev(hdev) antes de hu-&gt;proto-&gt;close(hu) causa un UAF cuando las devoluciones de llamada de cierre del protocolo específico del proveedor desreferencian hu-&gt;hdev.<br /> 3. En las rutas de error de inicialización, no tomar el bloqueo de escritura proto_lock antes de borrar PROTO_READY conduce a condiciones de carrera con lectores activos. Además, hci_uart_tty_receive() accede a hu-&gt;hdev fuera del bloqueo de lectura, lo que lleva a UAFs si la ruta de error de inicialización libera hdev concurrentemente.<br /> <br /> Corregir estos problemas de sincronización y ciclo de vida mediante:<br /> 1. Reordenar hci_uart_tty_close() para borrar HCI_UART_PROTO_READY primero, seguido inmediatamente por un cancel_work_sync(&amp;hu-&gt;write_work). Borrar la bandera bloquea a los temporizadores del protocolo concurrentes para que no invoquen con éxito hci_uart_tx_wakeup(), haciendo que la cancelación sea permanente y evitando la doble liberación de tx_skb.<br /> 2. Nota: Borrar PROTO_READY temprano hace que hci_uart_close() omita hu-&gt;proto-&gt;flush(). Esto es perfectamente seguro en la ruta tty_close porque hu-&gt;proto-&gt;close() se ejecuta poco después, lo que intrínsecamente purga todas las colas SKB del protocolo y desinstala el estado.<br /> 3. Reubicar hu-&gt;proto-&gt;close(hu) estrictamente antes de hci_free_dev(hdev) en todas las rutas de cierre y error para prevenir UAFs a nivel de proveedor.<br /> 4. Mover el incremento de hdev-&gt;stat.byte_rx en hci_uart_tty_receive() dentro de la sección crítica del lado de lectura de proto_lock para sincronizar de forma segura con la anulación del registro del dispositivo.<br /> 5. Añadir cancel_work_sync(&amp;hu-&gt;write_work) a hci_uart_close() para vaciar de forma segura la cola de trabajo antes de que hci_uart_flush() sea invocado a través del núcleo HCI.<br /> 6. Utilizar cancel_work_sync() en lugar de disable_work_sync() en todas las rutas para evitar romper permanentemente las capacidades de reintento del espacio de usuario.

Vulnerabilidad de lectura excesiva de búfer en Servidor HTTP Apache a través de solicitudes OCSP salientes a un servidor OCSP controlado por un atacante.<br /> <br /> Este problema afecta a Servidor HTTP Apache: desde 2.4.0 hasta 2.4.67.<br /> <br /> Se recomienda a los usuarios actualizar a la versión 2.4.68, que corrige el problema.

Un problema de manejo de rutas en mod_dav_fs en Apache 2.4.67 y versiones anteriores permite a un autor de contenido WebDAV manipular directamente bases de datos de propiedades DAV confiables, lo que podría causar caídas de procesos hijo.<br /> <br /> Se recomienda a los usuarios actualizar a la versión 2.4.68, que corrige este problema.