Vulnerabilidades

Clatter es una implementación pura de Rust, compatible con no_std, del framework del protocolo Noise con soporte post-cuántico. Las versiones anteriores a 2.2.0 tienen una vulnerabilidad de cumplimiento del protocolo. La librería permitía patrones de handshake post-cuánticos que violaban la regla de validez de PSK (Framework del Protocolo Noise Sección 9.3). Esto podría permitir que las claves derivadas de PSK se usaran para cifrado sin una aleatorización adecuada por aleatoriedad efímera auto-elegida, debilitando las garantías de seguridad y potencialmente permitiendo la reutilización catastrófica de claves. Los patrones predeterminados afectados incluyen 'noise_pqkk_psk0', 'noise_pqkn_psk0', 'noise_pqnk_psk0', 'noise_pqnn_psk0', y algunas variantes híbridas. Los usuarios de estos patrones pueden haber estado utilizando handshakes que no cumplen con las propiedades de seguridad previstas. El problema está completamente parcheado y lanzado en Clatter v2.2.0. La versión corregida incluye comprobaciones en tiempo de ejecución para detectar patrones de handshake ofensivos. Como solución alternativa, evite usar las variantes ofensivas '*_psk0' de patrones post-cuánticos. Revise cuidadosamente los patrones de handshake personalizados.

DNN (anteriormente DotNetNuke) es una plataforma de gestión de contenido web (CMS) de código abierto en el ecosistema de Microsoft. Antes de las versiones 9.13.10 y 10.2.0, un módulo podía instalarse con texto enriquecido en su campo de descripción, el cual podía contener scripts que se ejecutarían para el usuario en la Barra Persona. Las versiones 9.13.10 y 10.2.0 contienen una solución para el problema.

DNN (anteriormente DotNetNuke) es una plataforma de gestión de contenido web de código abierto (CMS) en el ecosistema de Microsoft. A partir de la versión 9.0.0 y anterior a las versiones 9.13.10 y 10.2.0, las extensiones podían escribir texto enriquecido en las notas de registro, que pueden incluir scripts que se ejecutarían en la PersonaBar al mostrarse. Las versiones 9.13.10 y 10.2.0 contienen una solución para el problema.

SandboxJS es una librería de sandboxing de JavaScript. Las versiones anteriores a la 0.8.26 tienen una vulnerabilidad de escape de sandbox debido a que `AsyncFunction` no está aislada en `SandboxFunction`. La librería intenta aplicar un sandbox a la ejecución de código reemplazando el constructor global `Function` con una versión segura y con sandbox (`SandboxFunction`). Esto se maneja en `utils.ts` mapeando `Function` a `sandboxFunction` dentro de un mapa utilizado para búsquedas. Sin embargo, antes de la versión 0.8.26, la librería no incluía mapeos para `AsyncFunction`, `GeneratorFunction` y `AsyncGeneratorFunction`. Estos constructores no son propiedades globales, pero se puede acceder a ellos a través de la propiedad `.constructor` de una instancia (por ejemplo, `(async () => {}).constructor`). En `executor.ts`, se maneja el acceso a propiedades. Cuando el código que se ejecuta dentro del sandbox accede a `.constructor` en una función asíncrona (que el sandbox permite crear), el `executor` recupera el valor de la propiedad. Dado que `AsyncFunction` no estaba en el mapa de reemplazo seguro, el `executor` devuelve el constructor `AsyncFunction` nativo real del host. Los constructores para funciones en JavaScript (como `Function`, `AsyncFunction`) crean funciones que se ejecutan en el ámbito global. Al obtener el constructor `AsyncFunction` del host, un atacante puede crear una nueva función asíncrona que se ejecuta completamente fuera del contexto del sandbox, eludiendo todas las restricciones y obteniendo acceso total al entorno del host (ejecución remota de código). La versión 0.8.26 corrige esta vulnerabilidad.

StudioCMS es un sistema de gestión de contenido sin cabeza, nativo de Astro, renderizado en el lado del servidor. Las versiones anteriores a la 0.2.0 contienen una vulnerabilidad de Autorización de Nivel de Objeto Rota (BOLA) en la función de Gestión de Contenido que permite a los usuarios con el rol de 'Visitante' acceder a contenido borrador creado por usuarios Editor/Administrador/Propietario. La versión 0.2.0 corrige el problema.

OpenEMR es una aplicación de gestión de registros de salud electrónicos y práctica médica de código abierto y gratuita. Las versiones anteriores a la 7.0.4 tienen una vulnerabilidad donde datos sensibles son revelados involuntariamente a partes no autorizadas. El contenido de las Notas Clínicas y el Plan de Atención, donde un encuentro tiene Sensibilidad=alta, puede ser visto y cambiado por usuarios que no tienen el privilegio Sensibilidades=alta. La versión 7.0.4 corrige el problema.

Meshtastic es una solución de red mallada de código abierto. En la arquitectura actual de Meshtastic, un Nodo se identifica por su NodeID, generado a partir de la dirección MAC, en lugar de su clave pública. Este aspecto degrada la seguridad, específicamente al abusar del modo HAM que no utiliza cifrado. Un atacante puede, como tal, falsificar un NodeInfo en nombre de un nodo víctima anunciando que el modo HAM está habilitado. Esto, a su vez, permitirá a los otros nodos en la malla aceptar la nueva información y sobrescribir la NodeDB. Los otros nodos solo podrán entonces enviar mensajes directos a la víctima utilizando la clave de canal compartida en lugar de la PKC. Además, debido a que el modo HAM por diseño no proporciona ninguna confidencialidad o autenticación de la información, el atacante también podría potencialmente cambiar los detalles del Nodo, como el nombre completo, el código corto, etc. Para mantener el ataque persistente, es suficiente con reenviar regularmente el NodeInfo falsificado, en particular justo después de que la víctima envíe el suyo propio. Un parche está disponible en la versión 2.7.6.834c3c5.

OpenEMR es una aplicación de código abierto y gratuita para la gestión de registros médicos electrónicos y consultorios médicos. Versiones anteriores a la 7.0.4 tienen un control de acceso roto en el endpoint de Edición de Perfil. Un usuario normal autenticado puede modificar los parámetros de la solicitud (pubpid / pid) para hacer referencia al registro de otro usuario; el servidor acepta los IDs modificados y aplica los cambios al perfil de ese otro usuario. Esto permite a un usuario alterar los datos de perfil de otro usuario (nombre, información de contacto, etc.), y podría habilitar la toma de control de la cuenta. La versión 7.0.4 corrige el problema.

vlt anterior a 1.0.0-rc.10 maneja incorrectamente la sanitización de rutas para tar, lo que lleva a un salto de ruta durante la extracción.

En Bun antes de 1.3.5, la lista predeterminada de dependencias de confianza (también conocida como lista de permisos de confianza) puede ser suplantada por un paquete que no es de npm en caso de coincidencia de nombre (para archivo, enlace, git o github).

Ghost es un sistema de gestión de contenido de código abierto. En las versiones de Ghost 5.43.0 a 5.12.04 y 6.0.0 a 6.14.0, un atacante pudo crear un enlace malicioso que, cuando era accedido por un usuario de personal o miembro autenticado, ejecutaría JavaScript con los permisos de la víctima, lo que podría llevar a la toma de control de la cuenta. Las versiones de Ghost Portal 2.29.1 a 2.51.4 y 2.52.0 a 2.57.0 eran vulnerables a este problema. Ghost carga automáticamente el último parche del componente Portal de miembros a través de CDN. Para los usuarios de Ghost 5.x, actualizar a la v5.121.0 o posterior corrige la vulnerabilidad. La v5.121.0 carga Portal v2.51.5, que contiene el parche. Para los usuarios de Ghost 6.x, actualizar a la v6.15.0 o posterior corrige la vulnerabilidad. La v6.15.0 carga Portal v2.57.1, que contiene el parche. Para las instalaciones de Ghost que utilizan una versión personalizada o autoalojada de Portal, será necesario reconstruir manualmente desde o actualizar a la última versión del parche.

vLLM es un motor de inferencia y servicio para modelos de lenguaje grandes (LLM). Antes de la versión 0.14.1, existe una vulnerabilidad de falsificación de petición del lado del servidor (SSRF) en la clase 'MediaConnector' dentro del conjunto de características multimodales del proyecto vLLM. Los métodos load_from_url y load_from_url_async obtienen y procesan medios de URLs proporcionadas por los usuarios, utilizando diferentes librerías de análisis de Python al restringir el host de destino. Estas dos librerías de análisis tienen diferentes interpretaciones de las barras invertidas, lo que permite eludir la restricción del nombre de host. Esto permite a un atacante coaccionar al servidor vLLM para que realice peticiones arbitrarias a recursos de red internos. Esta vulnerabilidad es particularmente crítica en entornos contenerizados como 'llm-d', donde un pod vLLM comprometido podría usarse para escanear la red interna, interactuar con otros pods y potencialmente causar denegación de servicio o acceder a datos sensibles. Por ejemplo, un atacante podría hacer que el pod vLLM envíe peticiones maliciosas a un endpoint de gestión interno de 'llm-d', lo que llevaría a la inestabilidad del sistema al informar falsamente métricas como el estado de la caché KV. La versión 0.14.1 contiene un parche para el problema.