Vulnerabilidades

Un archivo MODEL creado maliciosamente, cuando es analizado por ciertos productos de Autodesk, puede forzar una vulnerabilidad de escritura fuera de límites. Un actor malicioso puede aprovechar esta vulnerabilidad para causar un fallo, causar corrupción de datos o ejecutar código arbitrario en el contexto del proceso actual.

Se ha encontrado una vulnerabilidad en FascinatedBox lily hasta la versión 2.3. Este problema afecta a la función shorthash_for_name del archivo src/lily_symtab.c. Si se explota se provoca un uso después de la liberación. Se requiere acceso local para llevar a cabo este ataque. El exploit está disponible públicamente y podría ser utilizado. Se informó al proyecto del problema con antelación, a través de un informe de incidencia pero aún no ha respondido.

Rack es una interfaz modular de servidor web Ruby. Antes de las versiones 2.2.22, 3.1.20 y 3.2.5, la verificación de ruta de 'Rack::Directory' utilizaba una coincidencia de prefijo de cadena en la ruta expandida. Una solicitud como '/../root_example/' puede escapar de la raíz configurada si la ruta de destino comienza con la cadena raíz, permitiendo la enumeración de directorios fuera de la raíz prevista. Las versiones 2.2.22, 3.1.20 y 3.2.5 solucionan el problema.

PHPGurukul Hospital Management System v4.0 contiene una vulnerabilidad de falsificación de petición en sitios cruzados (CSRF) en el módulo 'Add Doctor'. La aplicación no aplica la validación de tokens CSRF en el endpoint add-doctor.php. Esto permite a atacantes remotos crear cuentas de Doctor arbitrarias (usuarios privilegiados) engañando a un administrador autenticado para que visite una página maliciosa.

El SDK de BSV Blockchain es un SDK unificado de TypeScript para desarrollar aplicaciones escalables en la BSV Blockchain. Antes de la versión 2.0.0, una vulnerabilidad criptográfica en la implementación de autenticación BRC-104 del SDK de TypeScript causó una preparación incorrecta de los datos de la firma, lo que resultó en incompatibilidad de firmas entre implementaciones de SDK y posibles escenarios de omisión de autenticación. La vulnerabilidad se encontraba en el archivo 'Peer.ts' del SDK de TypeScript, específicamente en los métodos 'processInitialRequest' y 'processInitialResponse' donde se preparan los datos de la firma para la autenticación mutua BRC-104. El SDK de TypeScript preparó incorrectamente los datos de la firma al concatenar cadenas nonce codificadas en base64 ('message.initialNonce + sessionNonce') y luego decodificar la cadena base64 concatenada ('base64ToBytes(concatenatedString)'). Esto produjo ~32-34 bytes de datos de firma en lugar de los 64 bytes correctos. La autenticación BRC-104 se basa en firmas criptográficas para establecer confianza mutua entre pares. Cuando la preparación de los datos de la firma es incorrecta, las firmas generadas por el SDK de TypeScript no coinciden con las esperadas por los SDK de Go/Python; la autenticación entre implementaciones falla; y un atacante podría potencialmente explotar esto para omitir las comprobaciones de autenticación. La corrección en la versión 2.0.0 asegura que todos los SDK ahora produzcan firmas criptográficas idénticas, restaurando la autenticación mutua adecuada entre implementaciones.

PHPGurukul Hospital Management System v4.0 contiene una vulnerabilidad de escalada de privilegios. Un usuario con pocos privilegios (Paciente) puede acceder directamente al Panel de Administrador y a todos los submódulos (p. ej., Registros de Usuario, Gestión de Médicos) navegando manualmente al directorio /admin/ después de la autenticación. Esto permite a cualquier usuario autorregistrado tomar el control de la aplicación, ver registros confidenciales y modificar datos del sistema.

El módulo 'Medical History' en PHPGurukul Hospital Management System v4.0 contiene una vulnerabilidad de Referencia Directa Insegura a Objeto (IDOR). La aplicación no verifica que el parámetro 'viewid' solicitado pertenezca al paciente actualmente autenticado. Esto permite a un usuario acceder a los registros médicos confidenciales de otros pacientes al iterar el entero 'viewid'.

Se encontró una vulnerabilidad en Squirrel hasta la versión 3.2. Está afectada por esta vulnerabilidad la función SQFuncState::PopTarget del archivo src/squirrel/squirrel/sqfuncstate.cpp. Si se manipula el argumento _target_stack puede lograrse una lectura fuera de límites. Es posible lanzar el ataque en el host local. El exploit ha sido divulgado públicamente y puede ser utilizado. Se informó pronto del problema al proyecto a través de un informe de incidencias pero aún no ha respondido.

Se encontró una vulnerabilidad en newbee-ltd newbee-mall hasta a069069b07027613bf0e7f571736be86f431faee. Se ve afectada una función desconocida del componente Multiple Endpoints. Si se explota la vulnerabilidad se logra realizar una falsificación de petición en sitios cruzados. Es posible la explotar el ataque en remoto. El exploit se ha hecho público y podría utilizarse. Este producto sigue un enfoque de lanzamiento continuo, por lo que no se proporcionan detalles de la versión para las versiones afectadas o actualizadas. Se informó al proyecto del problema con antelación a través de un informe de incidencias, pero aún no ha respondido.

Se descubrió un problema en OpenStack Nova antes de la versión 30.2.2, 31 antes de la 31.2.1, y 32 antes de la 32.1.1. Al escribir una cabecera QCOW maliciosa en un disco raíz o efímero y luego activar un redimensionamiento, un usuario puede inducir al backend de imagen Flat de Nova a llamar a qemu-img sin una restricción de formato, lo que resulta en una operación de redimensionamiento de imagen insegura que podría destruir datos en el sistema anfitrión. Solo los nodos de cómputo que utilizan el backend de imagen Flat (normalmente configurados con use_cow_images=False) se ven afectados.

En las versiones de Splunk Enterprise anteriores a 10.2.0, 10.0.2, 9.4.7, 9.3.8 y 9.2.11, y en las versiones de Splunk Cloud Platform anteriores a 10.2.2510.0, 10.1.2507.11, 10.0.2503.9 y 9.3.2411.120, un usuario de una implementación de Splunk Search Head Cluster (SHC) que posee un rol con acceso al índice _internal de Splunk podría ver las configuraciones de Security Assertion Markup Language (SAML) para solicitudes de consulta de atributos (AQRs) o extensiones de autenticación en texto sin formato dentro del archivo conf.log, dependiendo de qué característica esté configurada.

En las versiones de Splunk Enterprise anteriores a la 10.2.0, 10.0.2, 9.4.7, 9.3.9 y 9.2.11, un usuario de una implementación de Splunk Search Head Cluster (SHC) que posee un rol con acceso al índice '_internal' de Splunk podría ver el valor 'accessKey' de RSA del archivo [Authentication.conf ](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/authentication.conf), en texto plano.