Base de datos CVE

En Baicells Nova 430H, un dispositivo no autenticado dentro del alcance de radio puede enviar un mensaje de enlace ascendente malformado durante el establecimiento de la conexión que contiene una carga útil NAS no válida. Como el eNodeB no valida correctamente esta carga útil, reenvía el mensaje a la red central, lo que puede desencadenar el cierre de la asociación de señalización de la celda. Esto provoca una interrupción temporal del servicio hasta que el eNodeB y la red central restablecen la conectividad.

Un desbordamiento de búfer en ANGLE en Google Chrome para Android anterior a la versión 154.0.8037.92 permitió a un atacante remoto ejecutar potencialmente código arbitrario fuera del sandbox mediante una página HTML manipulada. (Gravedad de seguridad de Chromium: Crítica)

En el firmware de Anjvision YSSD‑RTMP‑H5 versión 3.3.2.4, el dispositivo incluye un hash de contraseña heredado en la consola serie que se basa en un cifrado débil basado en DES.

En Anjvision YSSD‑RTMP‑H5 firmware version 3.3.2.4, dos endpoints de información del usuario pueden revelar detalles sensibles del dispositivo y de la cuenta en condiciones que no están previstas para el funcionamiento normal.

En la versión 3.3.2.4 del firmware de Anjvision YSSD‑RTMP‑H5, se puede activar una función de comprobación de red sin autenticación para sondear hosts arbitrarios desde la red interna del dispositivo. Esto puede exponer información interna o filtrar datos mediante consultas DNS.

En el firmware Anjvision YSSD-RTMP-H5 versión 3.3.2.4, una solicitud POST con el cuerpo vacío a /setUserConfig, procesada por el controlador SOAP-RPC del servidor web, degrada silenciosamente la contraseña del administrador al valor predeterminado y corrompe el estado de autenticación en memoria hasta que se vuelve a cargar el dispositivo. El controlador no verifica el nivel de privilegios de la sesión, por lo que cualquier usuario autenticado puede activarlo.

En el firmware de Anjvision YSSD‑RTMP‑H5 versión 3.3.2.4, se puede habilitar una interfaz de depuración interna mediante una vía no documentada, lo que expone funciones no destinadas al funcionamiento normal. Cuando se activa, esta interfaz permite realizar acciones que podrían proporcionar involuntariamente un acceso elevado al sistema.

En el firmware de Anjvision YSSD‑RTMP‑H5 versión 3.3.2.4, el firmware incluye credenciales de API en la nube codificadas de forma fija que se comparten entre los dispositivos desplegados. Cualquier persona que obtenga el paquete público de firmware puede reutilizar estos valores para interactuar con el servicio en la nube de formas no previstas para el funcionamiento normal.

En la versión 3.3.2.4 del firmware de Anjvision YSSD‑RTMP‑H5, los mecanismos de actualización local y en la nube aplican el nuevo firmware sin ninguna verificación criptográfica y se basan únicamente en un hash básico. Este diseño permite que un atacante que pueda acceder a la rutina de actualización introduzca imágenes de firmware no confiables que el dispositivo aceptará como válidas.

En la versión 3.3.2.4 del firmware de Anjvision YSSD‑RTMP‑H5, se puede habilitar una interfaz de depuración oculta mediante una solicitud autenticada, lo que permite enviar comandos adicionales a un servicio backend. Una vez activa, esta vía puede exponer involuntariamente funcionalidad a nivel del sistema que podría ser objeto de uso indebido si entradas manipuladas llegan al controlador de comandos subyacente.

En la versión 3.3.2.4 del firmware Anjvision YSSD‑RTMP‑H5, varios endpoints del servicio ONVIF procesan solicitudes de administración sin exigir la autenticación requerida. Esto podría permitir que un atacante no autorizado acceda a operaciones sensibles del dispositivo.

TeamViewer Full Client and Host para Linux en versiones anteriores a la 15.82 contiene una vulnerabilidad de validación incorrecta de rutas en la funcionalidad Cloud Session Recording (CSR). Al explotar una condición de carrera durante la validación de rutas y el acceso posterior a los archivos, un atacante local autenticado puede provocar operaciones de archivos privilegiadas en ubicaciones no previstas del sistema afectado.

Una vulnerabilidad de control de acceso inadecuado en TeamViewer Full Client, Host y otros módulos afectados relacionados en Windows, Linux y macOS permite que un atacante remoto autenticado omita la configuración de permisos establecida por el usuario durante el establecimiento de la sesión. Al modificar los parámetros de control de acceso de las funciones restringidas, un atacante puede realizar acciones que la configuración de la víctima denegaba explícitamente. Esto puede dar lugar a acciones no autorizadas y potencialmente permitir la ejecución remota de código en el sistema objetivo.

TeamViewer Full Client and Host anteriores a la versión 15.82 en Windows contienen una condición de carrera TOCTOU en el mecanismo de reversión del instalador. Un atacante local con pocos privilegios puede reemplazar los archivos de copia de seguridad de reversión almacenados en un directorio temporal en el que el usuario puede escribir antes de que los restaure un instalador con privilegios elevados, lo que da lugar a una escalada de privilegios a NT AUHORITY/SYSTEM. La explotación requiere que la condición de carrera se produzca en el momento oportuno y que haya una reversión durante la instalación o actualización.

TeamViewer Full Client and Host para Linux y macOS en versiones anteriores a la 15.82 contienen una vulnerabilidad de buffer overflow basado en heap en el procesamiento de archivos de grabación de sesiones .tvs. Una discrepancia de tamaño durante la descompresión de los datos de la sesión grabada puede provocar escrituras fuera de límites en el heap. Si convence a un usuario para que abra una grabación de sesión especialmente diseñada mediante la función "Play or convert recorded session…", un atacante puede lograr la ejecución de código arbitrario con los privilegios del usuario actual.

Resumen del problema: Un par remoto malicioso puede saturar la pila QUIC local con tramas NEW_CONNECTION_ID al eludir una comprobación de límite sobre la cantidad de ID de conexión que puede usar la pila QUIC remota. Resumen del impacto: La pila QUIC local envía una trama RETIRE_CONN_ID por cada trama NEW_CONNECTION_ID que recibe. La trama RETIRE_CONN_ID se envía mediante la Control Frame Queue (CFQ). Si el par remoto también retiene los ACK, puede obligar a la pila local a asignar ~400MB (según el retraso de los ACK). CWE: CWE-770: Asignación de recursos sin límites ni limitación Descripción: Las secciones 5.1.1 y 5.1.2 de RFC 9000 [1] describen el mecanismo por el que un par remoto puede notificar a la pila QUIC local que cambie el ID de conexión de destino (también conocido como CID) que la pila local usa para identificar la conexión en el par remoto. Cada CID está asociado a un número de secuencia. El número de secuencia se transmite en las tramas NEW_CONNECTION_ID y RETIRE_CONNECTION_ID para identificar el CID que se está asociando a una conexión o retirando. El par remoto envía una trama NEW_CONNECTION_ID para informar a la pila local de que se está asociando un nuevo CID a una conexión existente. La trama NEW_CONNECTION_ID contiene el nuevo CID, su número de secuencia y el número retire-prior-to. El número retire-prior-to identifica los CID existentes que deben retirarse. La pila QUIC local debe enviar una trama RETIRE_CONNECTION_ID por cada CID de destino cuyo número de secuencia sea inferior a retire-prior-to. El CID queda retirado después de que la pila local recibe un ACK de su trama RETIRE_CONNECTION_ID. Aunque la pila QUIC de OpenSSL admite como máximo un CID de destino por conexión, se la puede engañar para que procese más de una trama RETIRE_CONNECTION_ID por conexión. Actualmente, la pila QUIC de OpenSSL retira el CID de destino en cuanto recibe la trama NEW_CONNECTION_ID, cuando en realidad el CID de destino debe retirarse después de recibir un ACK de la trama RETIRE_CONNECTION_ID. Corregir la lógica defectuosa también soluciona el crecimiento de la acumulación pendiente. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids Impacto en FIPS: no El módulo FIPS no se ve afectado, ya que la implementación de QUIC está fuera de los límites del módulo FIPS de OpenSSL.

Resumen del problema: El primer uso concurrente del mismo certificado X.509 por varios hilos puede hacer que se liberen sus datos de extensiones almacenados en caché mientras otro hilo todavía los está usando. Resumen del impacto: Un par remoto no autenticado podría bloquear un cliente TLS multiproceso, o un servidor TLS multiproceso que solicite certificados de cliente, si varias conexiones construyen al mismo tiempo las primeras cadenas de certificados que llegan al mismo certificado de CA de confianza. Se trata de una lectura use-after-free, que probablemente bloqueará el proceso y provocará una denegación de servicio. CWE: CWE-416: Use After Free Descripción: OpenSSL almacena en caché los valores decodificados de las extensiones X.509v3 de un certificado dentro del objeto X509 la primera vez que se necesitan. En OpenSSL 4.0 esta caché se construye en dos fases: los valores de las extensiones se calculan mientras se mantiene un bloqueo de lectura sobre el certificado y, a continuación, los resultados se instalan en el certificado bajo un bloqueo de escritura. Como un bloqueo de lectura no excluye a otros lectores, varios hilos pueden calcular la caché del mismo certificado al mismo tiempo. Cada hilo que adquiere posteriormente el bloqueo de escritura instala sus propios resultados y libera los valores instalados por el hilo anterior, aunque ese hilo anterior ya haya marcado la caché como completa y haya podido devolver punteros a ella a quien lo llamó. Entonces, quien llama y sigue usando esos punteros lee memoria liberada. Cualquier certificado compartido entre hilos queda expuesto la primera vez que se decodifican sus extensiones. En TLS, los certificados en riesgo son los certificados de CA de confianza proporcionados para la verificación de la cadena, por cualquier medio, ya que todas las conexiones los comparten y sus extensiones se decodifican y almacenan en caché la primera vez que se construye una cadena hasta ellos. Los certificados enviados por el par se decodifican por separado para cada conexión y no se comparten, por lo que no se ven afectados. En un cliente TLS que verifica certificados de servidor, o en un servidor TLS que solicita y verifica certificados de cliente, el use-after-free solo podría ocurrir si varias conexiones construyen al mismo tiempo las primeras cadenas que llegan a la misma CA de confianza. Impacto en FIPS: no El módulo FIPS no se ve afectado, ya que la gestión de certificados X.509 queda fuera de los límites del módulo FIPS de OpenSSL. OpenSSL 4.0 es vulnerable a este problema. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 y 1.0.2 no se ven afectados por este problema. Los usuarios de OpenSSL 4.0 deberían actualizar a OpenSSL 4.0.3. Tim Becker (Xint.io) informó de este problema el 27 de agosto de 2026 y aydinmercan lo notificó de forma independiente en un informe público el 31 de agosto de 2026. La corrección fue desarrollada por Bob Beck. -- corte (metadatos no publicados para uso interno) -- Informado por: Tim Becker (Xint.io), aydinmercan Corregido por: Bob Beck

Resumen del problema: La lógica de retransmisión de DTLS no gestiona correctamente una escritura de mensaje de handshake que se suspende a mitad de la operación. El mensaje retransmitido puede leerse más allá del búfer del mensaje y la retransmisión sobrescribe el estado interno que la escritura suspendida necesita para reanudarse correctamente. Resumen del impacto: El mensaje retransmitido puede divulgar memoria del heap al peer como datos de handshake en texto plano, o provocar una caída y una denegación de servicio cuando la lectura alcanza una región de memoria no asignada. CWE: CWE-125: Lectura fuera de límites Descripción: Los mensajes de handshake de DTLS se pueden escribir en varios fragmentos, y una escritura puede suspenderse a mitad del mensaje (devolviendo WANT_WRITE) si el transporte subyacente no puede aceptar temporalmente más datos. Mientras dicha escritura está suspendida, el temporizador de retransmisión de DTLS puede activarse de forma independiente y pedir a la lógica de retransmisión que reenvíe un mensaje anterior, ya confirmado como enviado, de su cola de retransmisión. La lógica de retransmisión reutilizaba el mismo búfer interno y el seguimiento de posición que el mensaje que todavía se estaba escribiendo, sin restablecer la posición al inicio del mensaje que se estaba retransmitiendo. Como resultado, la retransmisión se leía a partir de dondequiera que se hubiera quedado la escritura suspendida, produciendo un mensaje con una etiqueta incorrecta cuyo cuerpo estaba formado por bytes sobrantes de otro mensaje, más grande, que seguía en tránsito: contenido que nunca debía enviarse en ese momento y que podía sobrepasar el final del búfer asignado. Por separado, incluso cuando la retransmisión está posicionada correctamente, permitir que se complete mientras otra escritura está suspendida sobrescribe los mismos datos de seguimiento compartidos de los que depende la escritura suspendida para reanudarse. Cuando la aplicación reanuda posteriormente la escritura suspendida (mediante una llamada posterior a SSL_read(), SSL_write(), SSL_accept() o SSL_connect()), encuentra esos datos de seguimiento en un estado incompatible con el mensaje y aborta el proceso en una compilación de depuración. La corrección restablece la posición de lectura de la retransmisión al inicio del mensaje antes de reenviarlo, y omite por completo la retransmisión siempre que una escritura de handshake siga suspendida, aplazándola hasta la siguiente llamada que la reanude. Impacto en FIPS: no El código afectado está fuera de los límites del módulo FIPS.

Resumen del problema: La generación de firmas SM2 utiliza aritmética que no es de tiempo constante sobre valores secretos, creando un canal lateral de temporización. Resumen del impacto: Un atacante capaz de medir los tiempos de firma SM2 puede obtener información sobre el nonce secreto de cada firma, lo que, tras muchas firmas, puede llevar, mediante un ataque de retículo / Problema del Número Oculto, a recuperar la clave privada. CWE: CWE-208: Discrepancia de temporización observable Descripción: La generación de firmas SM2 calcula el valor de la firma utilizando operaciones BIGNUM de tiempo variable sobre el nonce secreto y la clave privada, por lo que el tiempo necesario para producir una firma SM2 depende de estos valores secretos, creando un canal lateral de temporización. Las aplicaciones que realizan la generación de firmas SM2 están afectadas en todas las plataformas. Impacto en FIPS: no SM2 no es un algoritmo FIPS.

Resumen del problema: Una asociación DTLS 1.2 establecida que utiliza un conjunto de cifrado AEAD puede terminarse mediante un único datagrama no autenticado cuyo fragmento cifrado es más corto que la sobrecarga obligatoria del IV explícito y la etiqueta de autenticación. Resumen del impacto: Un atacante que pueda enviar un datagrama que se enrute a una asociación DTLS 1.2 existente puede terminar esa asociación sin conocer ningún material de clave. Se trata de una denegación de servicio limitada a la asociación objetivo. No hay impacto en la seguridad de la memoria ni en la confidencialidad. CWE: CWE-1284: Validación incorrecta de la cantidad especificada en la entrada Descripción: En TLS 1.2 y DTLS 1.2, cada registro protegido por un conjunto de cifrado AEAD contiene un IV explícito seguido del texto cifrado y una etiqueta de autenticación. Al descifrar dicho registro, la capa de registros pasaba la longitud del registro a la implementación del cifrado antes de comprobar que el registro fuera lo bastante largo como para contener el IV explícito y la etiqueta. Si un registro era más corto que esa sobrecarga, la implementación del cifrado rechazaba la longitud imposible y la capa de registros lo trataba como un fallo interno y generaba una alerta fatal internal_error en vez de tratar el registro como uno que no había superado la autenticación. En TLS 1.2, el mismo registro provoca una alerta fatal internal_error en vez de la alerta bad_record_mac esperada. Dado que cualquier registro que no se pueda descifrar ya termina una conexión TLS, esto es un problema de conformidad del protocolo y no un problema de seguridad en TLS. La corrección valida la longitud del registro frente a la longitud del IV explícito y de la etiqueta antes de cualquier procesamiento AEAD, de modo que TLS informe bad_record_mac y DTLS descarte silenciosamente el registro. Impacto en FIPS: no El código afectado está fuera del límite del módulo FIPS.