Vulnerabilidades

Se encontró una vulnerabilidad en Campcodes Complete Online DJ Booking System 1.0. Ha sido calificada como problemática. Este problema afecta a un procesamiento desconocido del archivo /admin/booking-bwdates-reports-details.php. La manipulación del argumento fromdate conduce a cross site scripting. El ataque puede iniciarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador asociado de esta vulnerabilidad es VDB-257471.

datahub-helm proporciona los gráficos de Kubernetes Helm para implementar Datahub y sus dependencias en un clúster de Kubernetes. A partir de la versión 0.1.143 y antes de la versión 0.2.182, debido a problemas de configuración en el gráfico de timón, si había una implementación inicial exitosa durante un período de tiempo limitado, posiblemente se creaban tokens de acceso personal con una clave secreta predeterminada. Dado que la clave secreta es un valor estático y disponible públicamente, alguien podría inspeccionar el algoritmo utilizado para generar tokens de acceso personal y generar los suyos propios para una instancia. La implementación con la autenticación del servicio de metadatos habilitada habría sido difícil durante la ventana de lanzamientos. Si alguien eludió la configuración del timón y configuró manualmente la autenticación del servicio de metadatos para que se habilite usando variables de entorno directamente, esto omitiría la lógica de generación automática para Kubernetes Secrets y DataHub GMS usaría de forma predeterminada la clave de firma especificada estáticamente en application.yml. La mayoría de las implementaciones probablemente no intentaron eludir la configuración del timón para habilitar la autenticación del servicio de metadatos durante este tiempo, por lo que el impacto probablemente sea limitado. Cualquier implementación con la autenticación del servicio de metadatos habilitada debe garantizar que sus valores secretos estén correctamente aleatorizados. La versión 0.2.182 contiene un parche para este problema. Como workaround, se puede restablecer la clave de firma del token para que sea un valor aleatorio, lo que invalidará los tokens de acceso personal activos.

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---

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()`.

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".

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.

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 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.

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.

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.