Vulnerabilidades

Se ha identificado una vulnerabilidad de inyección SQL en Siyuan 3.1.11 a través del parámetro de matriz ids en /batchGetBlockAttrs.

FFmpeg n7.0 se ve afectado por una doble liberación a través de la función rkmpp_retrieve_framework dentro de libavcodec/rkmppdec.c.

Ant-Media-Serverv2.8.2 se ve afectado por una neutralización incorrecta de la salida de registros. La vulnerabilidad se origina en una desinfección insuficiente de la entrada en el mecanismo de registro. Sin un filtrado o validación adecuados, los datos controlables por el usuario, como identificadores u otra información confidencial, pueden incluirse en las entradas de registro sin restricciones.

FFmpeg n6.1.1 es un desbordamiento de enteros. La vulnerabilidad existe en la función parse_options de sbgdec.c dentro del módulo libavformat. Al analizar ciertas opciones, el software no valida adecuadamente la entrada. Esto permite que se acepten valores de duración negativos sin una verificación de los límites adecuada.

FFmpeg n6.1.1 tiene una lectura fuera de los límites a través de libavcodec/ppc/vp8dsp_altivec.c, static const vec_s8 h_subpel_filters_outer

El complemento Backstage Scaffolder contiene tipos y utilidades para crear módulos relacionados con el scaffolder. Se ha identificado una vulnerabilidad en la funcionalidad de plantilla de Backstage Scaffolder, en la que se puede explotar Server-Side Template Injection (SSTI) para realizar una inyección de configuración de Git. La vulnerabilidad permite a un atacante capturar tokens de Git privilegiados utilizados por el complemento Backstage Scaffolder. Con estos tokens, se puede lograr acceso no autorizado a recursos confidenciales en Git. El impacto se considera de gravedad media, ya que el modelo de amenazas de Backstage recomienda restringir el acceso para agregar y editar plantillas en el complemento Backstage Catalog. El problema se ha resuelto en las versiones `v0.4.12`, `v0.5.1` y `v0.6.1` del paquete `@backstage/plugin-scaffolder-node`. Se recomienda a los usuarios que actualicen a esta versión para mitigar la vulnerabilidad. Se recomienda a los usuarios que actualicen. Los usuarios que no puedan actualizar pueden asegurarse de que las plantillas no cambien la configuración de Git.

pyjwt es una implementación de JSON Web Token en Python. Se ejecuta una comparación de cadena incorrecta para la comprobación de `iss`, lo que da como resultado que `"acb"` se acepte en lugar de `"_abc_"`. Este es un error introducido en la versión 2.10.0: la comprobación de la reclamación "iss" cambió de `isinstance(issuer, list)` a `isinstance(issuer, Sequence)`. Dado que str es una secuencia, pero no una lista, `in` también se utiliza para la comparación de cadenas. Esto da como resultado que se compruebe `if "abc" not in "__abcd__":` en lugar de `if "abc" != "__abc__":`. Las comprobaciones de firma aún están presentes, por lo que es probable que el impacto en el mundo real se limite a escenarios de denegación de servicio. Este problema se ha corregido en la versión 2.10.1. Se recomienda a todos los usuarios que actualicen. No existen workarounds conocidos para esta vulnerabilidad.

RIOT es un microcontrolador de código abierto que opera con sistema, diseñado para cumplir con los requisitos de los dispositivos de Internet de las cosas (IoT) y otros dispositivos integrados. Un actor malintencionado puede enviar un paquete IEEE 802.15.4 con un byte de longitud falsificado y, opcionalmente, un FCS falsificado, lo que eventualmente da como resultado un bucle sin fin en un CC2538 como receptor. Antes de la PR n.° 20998, el receptor verificaba la ubicación del bit CRC utilizando el byte de longitud del paquete al considerar los 8 bits, en lugar de descartar el bit 7, que es lo que hace la radio. Esto luego da como resultado una lectura fuera del FIFO RX. Aunque imprime un error al intentar leer fuera del FIFO RX, continuará haciéndolo. Esto puede generar una discrepancia en la verificación de CRC según el firmware y la radio. Si la CPU juzga que el CRC es correcto y la radio está configurada en `AUTO_ACK`, cuando se solicita el paquete y se confirma el acuse de recibo, la CPU pasará al estado `CC2538_STATE_TX_ACK`. Sin embargo, si la radio juzga que el CRC es incorrecto, no enviará un acuse de recibo y, por lo tanto, el evento `TXACKDONE` no se activará. Entonces, nunca volverá al estado `CC2538_STATE_READY` ya que el procesamiento de banda base aún está deshabilitado. Entonces, la CPU estará en un bucle sin fin. Dado que la configuración en inactivo no es forzada, no lo hará si el estado de la radio no es `CC2538_STATE_READY`. Todavía no se ha realizado una solución.

vue-i18n es un complemento de internacionalización para Vue.js. En las versiones afectadas, se pueden enviar mensajes de configuración regional a vue-i18n a `createI18n` o `useI18n`. Cuando se generan mensajes de configuración regional en modo de desarrollo, existe la posibilidad de un ataque de Cross-site Scripting. Este problema se ha solucionado en las versiones 9.14.2 y 10.0.5. Se recomienda a los usuarios que actualicen la versión. No existen workarounds conocidos para esta vulnerabilidad.

@E58intlify/shared es una librería compartida para el proyecto intlify. La última versión de @intlify/shared (10.0.4) es vulnerable a la contaminación de prototipos a través de la(s) función(es) de entrada lib.deepCopy. Un atacante puede proporcionar un payload con el definidor Object.prototype para introducir o modificar propiedades dentro de la cadena de prototipos global, lo que provoca una denegación de servicio (DoS) como consecuencia mínima. Además, las consecuencias de esta vulnerabilidad pueden escalar a otros ataques basados ??en inyección, según cómo se integre la librería dentro de la aplicación. Por ejemplo, si la propiedad contaminada se propaga a las API de Node.js sensibles (p. ej., exec, eval), podría permitir que un atacante ejecute comandos arbitrarios dentro del contexto de la aplicación. Este problema se ha solucionado en las versiones 9.14.2 y 10.0.5. Se recomienda a los usuarios que actualicen. No existen workarounds conocidos para esta vulnerabilidad.E57

check-jsonschema es una CLI y un conjunto de ganchos de pre-confirmación para la validación de jsonschema. La estrategia de caché predeterminada utiliza el nombre base de un esquema remoto como el nombre del archivo en la caché, p. ej., `https://example.org/schema.json` se almacenará como `schema.json`. Este nombre permite conflictos. Si un atacante puede lograr que un usuario ejecute `check-jsonschema` contra una URL de esquema malintencionada, p. ej., `https://example.evil.org/schema.json`, puede insertar su propio esquema en la caché y se seleccionará y usará en lugar del esquema apropiado. Un ataque de confusión de caché de este tipo podría usarse para permitir que los datos pasen la validación que deberían haber sido rechazados. Este problema se ha corregido en la versión 0.30.0. Se recomienda a todos los usuarios que actualicen. Existen algunos workaround: 1. Los usuarios pueden usar `--no-cache` para deshabilitar el almacenamiento en caché. 2. Los usuarios pueden usar `--cache-filename` para seleccionar nombres de archivos para usar en la memoria caché o para garantizar que otros usos no sobrescriban el esquema almacenado en caché. (Nota: esta opción se está descontinuando como parte del esfuerzo de remediación). 3. Los usuarios pueden descargar explícitamente el esquema antes de usarlo como un archivo local, como en `curl -LOs https://example.org/schema.json; check-jsonschema --schemafile ./schema.json`

Ibexa Admin UI Bundle contiene todas las partes necesarias para ejecutar la interfaz de back office de Ibexa DXP. El patrón de nombre de contenido se utiliza para crear nombres de contenido a partir de uno o más campos. Se ha encontrado una vulnerabilidad de XSS en este mecanismo. Se requiere permiso de edición de contenido para explotarla. Después de la solución, no se ejecutará ningún XSS inyectado existente. Este problema se ha corregido en la versión 4.6.14. Se recomienda a todos los usuarios que actualicen. No existen workarounds conocidos para esta vulnerabilidad.