Vulnerabilidades

Cloud-init hasta la versión 25.1.2 se incluye la unidad de socket systemd cloud-init-hotplugd.socket con el SocketMode predeterminado, que otorga permisos 0666, lo que le otorga permisos de escritura universal. Esto se utiliza para el FIFO "/run/cloud-init/hook-hotplug-cmd". Un usuario sin privilegios podría ejecutar comandos hotplug-hook.

Razón rechazado: no es una vulnerabilidad.

Un usuario con permisos específicos de edición de grupos de nodos y un parámetro de clase especialmente manipulado podría ejecutar comandos como root en el host principal. Esto afecta a las versiones 2018.1.8 a 2023.8.3 y 2025.3 de Puppet Enterprise y se ha resuelto en las versiones 2023.8.4 y 2025.4.0.

Se ha descubierto un problema en GitLab EE que afecta a todas las versiones desde la 16.10 hasta la 17.11.5, la 18.0 hasta la 18.0.3 y la 18.1 hasta la 18.1.1 que podría haber permitido a los usuarios autenticados asignar frameworks de cumplimiento no relacionados a los proyectos mediante el envío de mutaciones GraphQL manipuladas que eludían los controles de permisos específicos del framework.

Se ha descubierto un problema en GitLab CE/EE que afecta a todas las versiones desde la 10.7 hasta la 17.11.5, la 18.0 hasta la 18.0.3 y la 18.1 hasta la 18.1.1 que podría haber permitido a atacantes autenticados crear una condición de denegación de servicio mediante el envío de solicitudes GraphQL manipuladas.

Existe un problema de solicitud directa (navegación forzada) en las versiones 0.10.12 y anteriores de iroha Board. Si se explota esta vulnerabilidad, un atacante que inicie sesión en el producto afectado podría acceder a contenido no público.

Existe una vulnerabilidad de cross-site request forgery en las versiones 0.10.12 y anteriores de iroha Board. Si un usuario accede a una URL especialmente manipulada mientras tiene la sesión iniciada en el producto afectado, podrían registrarse historiales de aprendizaje arbitrarios.

Se descubrió un problema en GitLab CE/EE que afecta a todas las versiones desde la 17.2 hasta la 17.11.5, la 18.0 hasta la 18.0.3 y la 18.1 hasta la 18.1.1 que podría haber permitido a los usuarios autenticados con permisos de rol de Invitado agregar elementos secundarios a los elementos de trabajo del incidente mediante el envío de solicitudes de API manipuladas que eludían las restricciones de rol impuestas por la interfaz de usuario.

Se ha identificado una posible vulnerabilidad de seguridad en HPE OneView para VMware vCenter (OV4VC). Esta vulnerabilidad podría explotarse para permitir que un atacante con privilegios de solo lectura provoque una escalada vertical de privilegios (el operador puede realizar acciones de administrador).

Se ha descubierto un problema en GitLab CE/EE que afecta a todas las versiones desde la 17.2 hasta la 17.11.5, la 18.0 hasta la 18.0.3 y la 18.1 hasta la 18.1.1 que podría haber permitido a atacantes no autenticados cargar archivos arbitrarios en proyectos públicos mediante el envío de solicitudes de API manipuladas, lo que podría provocar un abuso de recursos y un almacenamiento de contenido no autorizado.

Se ha descubierto un problema en GitLab CE/EE que afecta a todas las versiones desde la 17.3 hasta la 17.11.5, la 18.0 hasta la 18.0.3 y la 18.1 hasta la 18.1.1 que podría haber permitido que usuarios autenticados obtuvieran privilegios elevados de proyecto al solicitar acceso a proyectos en los que las modificaciones de roles durante el proceso de aprobación dieron como resultado concesiones de permisos no deseadas.

Las versiones del paquete snyk anteriores a la 1.1297.3 son vulnerables a la inserción de información confidencial en el archivo de registro a través de los registros de depuración locales de la CLI de Snyk. Las credenciales del Registro de Contenedores proporcionadas mediante variables de entorno o argumentos de la línea de comandos pueden quedar expuestas al ejecutar la CLI de Snyk en modo DEBUG o DEBUG/TRACE. El problema afecta a los siguientes comandos de Snyk: 1. Al ejecutar los comandos snyk container test o snyk container monitor en un registro de contenedores con el modo de depuración habilitado, las credenciales del registro de contenedores pueden escribirse en el registro de depuración local de la CLI de Snyk. Esto solo ocurre con las credenciales especificadas en las variables de entorno (SNYK_REGISTRY_USERNAME y SNYK_REGISTRY_PASSWORD) o en la CLI (--password/-p y --username/-u). 2. Cuando se ejecuta el comando snyk auth con el modo de depuración habilitado y el nivel de registro establecido en TRACE, los tokens de credenciales de acceso/actualización de Snyk utilizados para conectar la CLI a Snyk pueden escribirse en los registros de depuración de la CLI local. 3. Cuando se ejecuta la prueba snyk iac con un paquete de reglas personalizadas de IAC remoto, con el modo de depuración habilitado y el nivel de registro establecido en TRACE, el token de registro de Docker puede escribirse en los registros de depuración de la CLI local.