Vulnerabilidades

Se descubrió que OneBlog v2.3.4 contiene una vulnerabilidad de cross-site scripting (XSS) almacenado a través del módulo de administración de roles.

Qiskit IBM Runtime es un entorno que agiliza los cálculos cuánticos y proporciona implementaciones óptimas del SDK de computación cuántica de Qiskit. A partir de la versión 0.1.0 y antes de la versión 0.21.2, deserializar datos json usando `qiskit_ibm_runtime.RuntimeDecoder` puede llevar a la ejecución de código arbitrario dada una cadena de entrada con el formato correcto. La versión 0.21.2 contiene una solución para este problema.

OAuthenticator proporciona complementos para que JupyterHub utilice proveedores de OAuth comunes, así como clases base para escribir sus propios autenticadores con cualquier proveedor de OAuth 2.0. `GoogleOAuthenticator.hosted_domain` se utiliza para restringir a qué cuentas de Google se les puede autorizar el acceso a un JupyterHub. La restricción está destinada a las cuentas de Google que forman parte de una o más organizaciones de Google verificadas para controlar dominios específicos. Antes de la versión 16.3.0, la restricción real era para las cuentas de Google con correos electrónicos que terminaban con el dominio. Estas cuentas podrían haber sido creadas por cualquier persona que en algún momento haya podido leer un correo electrónico asociado con el dominio. Esto fue descrito por Dylan Ayrey (@dxa4481) en esta [publicación de blog] del 15 de diciembre de 2023). OAuthenticator 16.3.0 contiene un parche para este problema. Como workaround, restrinja quién puede iniciar sesión de otra manera, como "usuarios_permitidos" o "grupos_de_google_permitidos".

Saleor Storefront es un software para crear experiencias de comercio electrónico. Antes del commit 579241e75a5eb332ccf26e0bcdd54befa33f4783, cuando cualquier usuario se autentica en el escaparate, los usuarios anónimos pueden acceder a sus datos. La sesión se filtra a través del caché y cualquiera puede acceder a ella. Los usuarios deben actualizar a una versión que incorpore El commit 579241e75a5eb332ccf26e0bcdd54befa33f4783 o posterior para recibir un parche. Un posible workaround es desactivar temporalmente la autenticación cambiando el uso de `createSaleorAuthClient()`.

Moby es un marco de contenedores de código abierto que es un componente clave de Docker Engine, Docker Desktop y otras distribuciones de herramientas o tiempos de ejecución de contenedores. La implementación de redes de Moby permite definir muchas redes, cada una con su propio rango de direcciones IP y puerta de enlace. Esta característica se conoce frecuentemente como redes personalizadas, ya que cada red puede tener un controlador, un conjunto de parámetros y, por lo tanto, comportamientos diferentes. Al crear una red, el indicador `--internal` se utiliza para designar una red como _internal_. El atributo "interno" en un archivo docker-compose.yml también se puede usar para marcar una red como _interna_, y otros clientes API también pueden especificar el parámetro "interno". Cuando se crean contenedores con redes, se les asignan interfaces de red y direcciones IP únicas. El host sirve como enrutador para redes no internas, con una IP de puerta de enlace que proporciona SNAT/DNAT hacia/desde las IP del contenedor. Los contenedores en una red interna pueden comunicarse entre sí, pero no pueden comunicarse con ninguna red a la que el host tenga acceso (LAN o WAN), ya que no hay una ruta predeterminada configurada y las reglas de firewall están configuradas para eliminar todo el tráfico saliente. Es posible la comunicación con la dirección IP de la puerta de enlace (y, por lo tanto, con los servicios de host configurados adecuadamente), y el host puede comunicarse directamente con cualquier IP de contenedor. Además de configurar las diversas funciones de red del kernel de Linux para habilitar la red de contenedores, `dockerd` proporciona directamente algunos servicios a las redes de contenedores. El principal de ellos es servir como solucionador, permitiendo el descubrimiento de servicios y la resolución de nombres desde un solucionador ascendente. Cuando se recibe una solicitud de DNS para un nombre que no corresponde a un contenedor, la solicitud se reenvía al solucionador ascendente configurado. Esta solicitud se realiza desde el espacio de nombres de la red del contenedor: el nivel de acceso y enrutamiento del tráfico es el mismo que si la solicitud la realizara el propio contenedor. Como consecuencia de este diseño, los contenedores conectados únicamente a una red interna no podrán resolver nombres utilizando el solucionador ascendente, ya que el contenedor en sí no puede comunicarse con ese servidor de nombres. Sólo se pueden resolver los nombres de los contenedores también conectados a la red interna. Muchos sistemas ejecutan un solucionador de DNS de reenvío local. Como el host y cualquier contenedor tienen dispositivos de loopback separados, una consecuencia del diseño descrito anteriormente es que los contenedores no pueden resolver nombres desde el solucionador configurado del host, ya que no pueden alcanzar estas direcciones en el dispositivo de loopback del host. Para cerrar esta brecha y permitir que los contenedores resuelvan nombres correctamente incluso cuando se utiliza un solucionador de reenvío local en una dirección de loopback, `dockerd` detecta este escenario y en su lugar reenvía solicitudes DNS desde el espacio de nombres del trabajo de nombres del host. Luego, el solucionador de bucle invertido reenvía las solicitudes a sus solucionadores ascendentes configurados, como se esperaba. Debido a que `dockerd` reenvía solicitudes de DNS al dispositivo de bucle invertido del host, omitiendo por completo la semántica de enrutamiento normal del espacio de nombres de la red del contenedor, las redes internas pueden reenviar solicitudes de DNS inesperadamente a un servidor de nombres externo. Al registrar un dominio para el cual controlan los servidores de nombres autorizados, un atacante podría hacer que un contenedor comprometido extraiga datos codificándolos en consultas DNS que eventualmente serán respondidas por sus servidores de nombres.---TRUNCADO---

Un problema de SSRF en REBUILD v.3.5 permite a un atacante remoto obtener información confidencial y ejecutar código arbitrario a través de los parámetros FileDownloader.java, proxyDownload y URL.

Umbraco es un sistema de gestión de contenidos ASP.NET. Umbraco 10 anterior a 10.8.4 con acceso a la pantalla de inicio de sesión nativa es vulnerable a un posible ataque de enumeración de usuarios. Este problema se solucionó en la versión 10.8.5. Como workaround, se puede desactivar la pantalla de inicio de sesión nativa utilizando exclusivamente inicios de sesión externos.

Una vulnerabilidad fue encontrada en Campcodes Complete Online DJ Booking System 1.0 y clasificada como problemática. Una función desconocida del archivo /admin/user-search.php es afectada por esta vulnerabilidad. La manipulación del argumento searchdata conduce a cross site scripting. El ataque puede lanzarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador de esta vulnerabilidad es VDB-257468.

Se encontró una vulnerabilidad en Campcodes Complete Online DJ Booking System 1.0. Ha sido clasificada como problemática. Esto afecta a una parte desconocida del archivo /admin/contactus.php. La manipulación del argumento correo electrónico conduce a cross site scripting. Es posible iniciar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. A esta vulnerabilidad se le asignó el identificador VDB-257469.

Una vulnerabilidad ha sido encontrada en Campcodes Complete Online DJ Booking System 1.0 y clasificada como crítica. Una función desconocida del archivo /admin/booking-bwdates-reports-details.php es afectada por esta vulnerabilidad. La manipulación del argumento fromdate conduce a la inyección de SQL. El ataque se puede lanzar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador asociado de esta vulnerabilidad es VDB-257467.

Jupyter Server Proxy permite a los usuarios ejecutar procesos externos arbitrarios junto con sus servidores portátiles Jupyter y proporciona acceso web autenticado. Antes de las versiones 3.2.3 y 4.1.1, Jupyter Server Proxy no verificaba adecuadamente la autenticación del usuario al utilizar websockets, lo que permitía el acceso no autenticado a cualquier persona que tuviera acceso de red al endpoint del servidor Jupyter. Esta vulnerabilidad puede permitir el acceso remoto no autenticado a cualquier endpoint de websocket configurado para ser accesible a través de Jupyter Server Proxy. En muchos casos, esto conduce a la ejecución remota de código arbitrario no autenticado, debido a cómo las instancias afectadas usan websockets. Los endpoints de websocket expuestos por el propio `jupyter_server` no se ven afectados. Los proyectos que no dependen de websockets tampoco se ven afectados. Las versiones 3.2.3 y 4.1.1 contienen una solución para este problema.

Zulip es una colaboración en equipo de código abierto. Cuando un usuario mueve un mensaje de Zulip, tiene la opción de mover todos los mensajes del tema, mover también solo los mensajes posteriores o mover solo un mensaje. Si el usuario elige mover solo un mensaje y lo mueve de una transmisión pública a una privada, Zulip movería exitosamente el mensaje, pero los usuarios activos que no tenían acceso a la transmisión privada, pero cuyo cliente ya lo había hecho. recibido el mensaje, continuaría viendo el mensaje en la transmisión pública hasta que recargaran su cliente. Además, Zulip no eliminó los permisos de visualización del mensaje de los usuarios activos recientemente, lo que permitió que el mensaje apareciera en la vista "Todos los mensajes" o en los resultados de búsqueda, pero no en las vistas "Bandeja de entrada" o "Conversaciones recientes". Si bien el error ha estado presente desde que se introdujo por primera vez el movimiento de mensajes entre transmisiones en la versión 3.0, esta opción se volvió mucho más común a partir de Zulip 8.0, cuando se cambió la opción predeterminada en el selector para mover el último mensaje de una conversación. Este problema se solucionó en Zulip Server 8.3. No hay workarounds disponibles.