Vulnerabilidades

Libsixel versión 1.8.2, contiene un desbordamiento de búfer en la región heap de la memoria en la función dither_func_fs en el archivo tosixel.c

Libsixel versión 1.8.3, contiene un desbordamiento de búfer en la región heap de la memoria en la función sixel_encode_highcolor en el archivo tosixel.c

En Ericsson ECM versiones anteriores a 18.0, se observó que el Endpoint del Proveedor de Seguridad en la Sección de Administración de Perfiles de Usuario es vulnerable a una inyección de CSV

En Ericsson ECM versiones anteriores a 18.0, se observó que el Endpoint del Proveedor de Seguridad en la Sección de Administración de Perfiles de Usuario es vulnerable a un ataque de tipo XSS almacenado por medio de un nombre, conllevando a el secuestro de la sesión y la toma de posesión completa de la cuenta

Wasmtime es un runtime de código abierto para WebAssembly y WASI. En Wasmtime desde la versión 0.26.0 y versiones anteriores a 0.30.0, está afectado por una vulnerabilidad por falta de memoria. Se presentaba un error de lectura y escritura no válida y fuera de límites cuando se ejecutaba Wasm que usa "externref"s en Wasmtime. Para desencadenar este fallo, Wasmtime necesita estar ejecutando Wasm que usa "externref"s, el host crea "externrefs" no nulos, Wasmtime lleva a cabo una recolección de basura (GC), y tiene que presentar un marco Wasm en la pila que está en un punto de seguridad de GC donde no hay referencias vivas en este punto de seguridad, y presenta un punto de seguridad con referencias vivas antes en la función de este marco. Bajo este escenario, Wasmtime usaría incorrectamente el mapa de pila de la GC para el punto de seguridad de antes en la función en lugar del punto de seguridad vacío. Esto resultaría en que Wasmtime tratara ranuras de pila arbitrarias como "externref"s que debían ser enraizadas para la GC. En la *next* GC, se determinaría que nada hacía referencia a estas falsas "externref"s (porque nada podría hacer referencia a ellas, ya que no son realmente "externref"s) y entonces Wasmtime las desasignaría y ejecutaría "(ExternRef as Drop)::drop" sobre ellas. Esto resulta en una liberación de memoria que no está necesariamente en la pila (y no debería ser liberada en este momento incluso si lo estuviera), así como potenciales lecturas y escrituras fuera de límites. Aunque el soporte para "externref"s (por medio de la propuesta de tipos de referencia) está habilitado por defecto, a menos que estés creando "externref"s no nulos en tu código anfitrión o activando explícitamente GCs, no puedes ser afectado por este error. Tenemos razones para creer que el impacto efectivo de este bug es relativamente pequeño porque el uso de "externref" es actualmente bastante raro. Este bug ha sido parcheado y los usuarios deberían actualizar a la versión 0.30.0 de Wasmtime. Si no puedes actualizar Wasmtime en este momento, puedes evitar este bug al desactivar la propuesta de tipos de referencia pasando "false" a "wasmtime::Config::wasm_reference_types"

seatd-launch en seatd versiones 0.6.x anteriores a 0.6.2, permite una escalada de privilegios porque usa execlp y puede ser instalado como root setuid

** EN DISPUTA ** RealVNC Viewer 6.21.406 permite que los servidores VNC remotos provoquen una denegación de servicio (caída de la aplicación) a través de datos de protocolo RFB manipulados. NOTA: Se afirma que este problema requiere ingeniería social para que un usuario se conecte a un servidor VNC falso. La aplicación VNC Viewer que están utilizando se colgará, hasta que se termine, pero no se produce ninguna fuga de memoria - los recursos se liberan una vez que el proceso colgado se termina y el uso de recursos es constante durante el cuelgue. Sólo el proceso que está conectado al falso servidor se ve afectado. Esto es un error de la aplicación, no un problema de seguridad

el archivo setup.cgi en los dispositivos NETGEAR R6020 versión 1.0.0.48, permite a un administrador ejecutar comandos de shell arbitrarios por medio de metacaracteres de shell en el campo ntp_server

Wasmtime es un tiempo de ejecución de código abierto para WebAssembly y WASI. Wasmtime versiones anteriores a 0.30.0, está afectado por una vulnerabilidad de confusión de tipo. Como librería de Rust, la caja "wasmtime" marca claramente qué funciones son seguras y cuáles son "unsafe", garantizando que si los consumidores nunca usan "unsafe" no debería ser posible tener problemas de inseguridad de memoria en sus inserciones de Wasmtime. Se ha detectado un problema en la API segura de las APIs "Linker::func_*". Estas APIs no eran seguras cuando un "Engine" era usado para crear el "Linker" y luego otro "Engine" era usado para crear un "Store" y luego el "Linker" era usado para instanciar un módulo en ese "Store". Un uso cruzado de funciones de "Engine" no está soportado en Wasmtime y esto puede resultar en una confusión de tipo de los punteros de las funciones, resultando en poder llamar de forma segura a una función con el tipo equivocado. Desencadenar este bug requiere el uso de al menos dos valores de "Engine" en una inserción y, además, el uso de dos valores diferentes con un "Linker" (uno en el momento de la creación del "Linker" y otro cuando se instancie un módulo con el "Linker"). Se espera que el uso de más de un "Engine" en una inserción sea relativamente raro ya que un "Engine" está destinado a ser un recurso compartido globalmente, por lo que se espera que el impacto de este problema sea relativamente pequeño. La corrección implementada es cambiar este comportamiento a "panic!()" en Rust en lugar de permitirlo silenciosamente. El uso de diferentes instancias de "Engine" con un "Linker" es un error de programación que "wasmtime" detecta en tiempo de ejecución. Este bug ha sido parcheado y los usuarios deberían actualizar a la versión 0.30.0 de Wasmtime. Si no puedes actualizar Wasmtime y estás usando más de un "Engine" en tu inserción, se recomienda usar sólo un "Engine" para todo el programa si es posible. Un "Engine" está diseñado para ser un recurso globalmente compartido que es adecuado para tener sólo uno durante el tiempo de vida de un proceso entero. Si se requiere el uso de múltiples "Engines" entonces el código debe ser auditado para asegurar que el "Linker" sólo se usa con un "Engine"

Wasmtime es un tiempo de ejecución de código abierto para WebAssembly y WASI. En Wasmtime desde la versión 0.19.0 y versiones anteriores a 0.30.0, se presentaba un error de uso de memoria previamente liberada cuando se pasaban "externref"s desde el host al contenido del Wasm invitado. Para desencadenar el bug, debes pasar explícitamente múltiples "externref"s desde el host a una instancia de Wasm al mismo tiempo, ya sea pasando múltiples "externref"s como argumentos desde el código del host a una función de Wasm, o devolviendo múltiples "externref"s a Wasm desde una función de retorno multivalente definida en el host. Si no tienes código de host que coincida con una de estas formas, entonces no te afecta. Si la "VMExternRefActivationsTable" de Wasmtime se llenó de capacidad después de pasar la primera "externref", entonces pasar la segunda "externref" podría desencadenar una recolección de basura. Sin embargo, la primera "externref" no está arraigada hasta que pasamos el control a Wasm, y por lo tanto podría ser recuperada por el recolector si nada más estuviera manteniendo una referencia a ella o la mantuviera viva. Entonces, cuando se pasara el control a Wasm después de la recolección de basura, Wasm podría usar la primera "externref", que en este punto ya ha sido liberada. Tenemos razones para creer que el impacto efectivo de este error es relativamente pequeño porque el uso de "externref" es actualmente bastante raro. El bug ha sido corregido, y los usuarios deberían actualizar a Wasmtime versión 0.30.0. Si no puedes actualizar Wasmtime todavía, puedes evitar el bug deshabilitando el soporte de tipos de referencia en Wasmtime pasando "false" a "wasmtime::Config::wasm_reference_types"

Las peticiones POST correctamente formateadas a múltiples recursos en los servidores web HTTP y HTTPS del dispositivo Digi PortServer TS 16 Rack no requieren autenticación ni tokens de autenticación. Esta vulnerabilidad podría permitir a un atacante habilitar el servicio SNMP y manipular las cadenas de comunidad para lograr un mayor control en

*** Pendiente de traducción *** Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none