Vulnerabilidades

ssoready es un proveedor de inicio de sesión único implementado a través de Docker. Las versiones afectadas son vulnerables a ataques de omisión de firma XML. Un atacante puede llevar a cabo una omisión de firma si tiene acceso a ciertos mensajes firmados por IDP. El mecanismo subyacente explota el comportamiento diferencial entre analizadores XML. Los usuarios de https://ssoready.com, la instancia pública alojada de SSOReady, no se ven afectados. Recomendamos a las personas que alojan SSOReady por sí mismas que actualicen a 7f92a06 o posterior. Hágalo actualizando sus imágenes Docker de SSOReady de sha-... a sha-7f92a06. No existen workarounds conocidas para esta vulnerabilidad.

Taipy es una librería Python de código abierto que permite el desarrollo de aplicaciones de extremo a extremo para científicos de datos e ingenieros de aprendizaje automático. En las versiones afectadas, las cookies de sesión se envían sin los indicadores Secure y HTTPOnly. Este problema se ha solucionado en la versión 4.0.0 y se recomienda a todos los usuarios que actualicen la versión. No se conocen workarounds para esta vulnerabilidad.

Existe una vulnerabilidad de divulgación de información en la versión 0.3.8 de open-webui. La vulnerabilidad está relacionada con la función de actualización del modelo de incrustación en la configuración de administrador. Cuando un usuario actualiza la ruta del modelo, el sistema verifica si el archivo existe y proporciona diferentes mensajes de error según la existencia y la configuración del archivo. Este comportamiento permite a un atacante enumerar los nombres de los archivos y recorrer los directorios observando los mensajes de error, lo que puede provocar la exposición de información confidencial.

Se encontró una falla en Keycloak. Ciertos endpoints en la API REST de administración de Keycloak permiten que usuarios con pocos privilegios accedan a funcionalidades administrativas. Esta falla permite que los usuarios realicen acciones reservadas para administradores, lo que puede provocar violaciones de datos o comprometer el sistema.

ImportDump es una extensión para mediawiki diseñada para automatizar las solicitudes de importación de los usuarios. Cualquiera que pueda editar las cadenas de interfaz de una wiki (normalmente administradores y administradores de interfaz) puede incrustar payloads XSS en los mensajes de fechas y, por tanto, enviar XSS a cualquiera que vea Special:RequestImportQueue. Este problema se ha corregido en el commit `d054b95` y se recomienda a todos los usuarios que apliquen esta confirmación a su rama. Los usuarios que no puedan actualizar pueden impedir el acceso a Special:RequestImportQueue en todas las wikis, excepto en la wiki global; y si hay disponible una protección de nivel de administrador de interfaz (o equivalente) (que no se proporciona de forma predeterminada) en la wiki global, proteger los mensajes afectados hasta ese nivel. Esto hace que el XSS sea prácticamente inútil, ya que los usuarios con esos derechos ya pueden editar páginas de Javascript. O impedir el acceso a Special:RequestImportQueue por completo.

Wasmtime es un entorno de ejecución de código abierto para WebAssembly. Bajo ciertas órdenes de eventos concurrentes, el registro de tipos interno de `wasmtime::Engine` era susceptible a errores de doble anulación de registro debido a una condición de ejecución, lo que provocaba pánicos y, potencialmente, corrupción del registro de tipos. Esa corrupción del registro podría, después de una secuencia adicional y particular de eventos concurrentes, provocar violaciones de la integridad del flujo de control (CFI) y la seguridad de tipos de WebAssembly. Los usuarios que no usan `wasmtime::Engine` en varios subprocesos no se ven afectados. Los usuarios que solo crean nuevos módulos en varios subprocesos a lo largo del tiempo tampoco se ven afectados. Para reproducir este error es necesario crear y eliminar varias instancias de tipo (como `wasmtime::FuncType` o `wasmtime::ArrayType`) simultáneamente en varios subprocesos, donde todos los tipos están asociados con el mismo `wasmtime::Engine`. **Los invitados de Wasm no pueden activar este error.** Consulte la sección "Referencias" a continuación para obtener una lista de las API relacionadas con los tipos de Wasmtime que se ven afectadas. Wasmtime mantiene un registro interno de tipos dentro de un `wasmtime::Engine` y un motor se puede compartir entre subprocesos. Los tipos se pueden crear y referenciar mediante la creación de un `wasmtime::Module`, la creación de `wasmtime::FuncType` o una serie de otras API donde el host crea una función (consulte "Referencias" a continuación). Cada uno de estos casos interactúa con un motor para deduplicar la información de tipo y administrar los índices de tipo que se utilizan para implementar las comprobaciones de tipo en la función `call_indirect` de WebAssembly, por ejemplo. Este error es una condición de ejecución en esta gestión donde el registro de tipo interno podría estar dañado para activar una aserción o contener un estado no válido. La representación interna de Wasmtime de un tipo tiene tipos individuales (por ejemplo, uno por función de host) que mantienen un recuento de registro de cuántas veces se ha utilizado. Los tipos también tienen un estado dentro de un motor detrás de un bloqueo de lectura y escritura, como información de búsqueda o deduplicación. La ejecución aquí es un error de tiempo de verificación versus tiempo de uso (TOCTOU) donde un hilo disminuye atómicamente el recuento de registros de una entrada de tipo, observa cero registros y luego adquiere un bloqueo para anular el registro de esa entrada. Sin embargo, entre el momento en que este primer hilo observó el recuento de registros cero y el momento en que adquiere ese bloqueo, otro hilo podría realizar la siguiente secuencia de eventos: volver a registrar otra copia del tipo, que deduplica esa misma entrada, resucitándola e incrementando su recuento de registros; luego, descartar el tipo y disminuir su recuento de registros; observar que el recuento de registros ahora es cero; adquirir el bloqueo de registro de tipo; y finalmente anular el registro del tipo. Ahora, cuando el hilo original finalmente adquiere el bloqueo y anula el registro de la entrada, es la segunda vez que se anula el registro de esta entrada. Este error se introdujo originalmente en el desarrollo de la propuesta de recolección de elementos no utilizados de WebAssembly en Wasmtime 19. Sin embargo, este error afecta a los usuarios que no utilizan la propuesta de recolección de elementos no utilizados y afecta a Wasmtime en su configuración predeterminada incluso cuando la propuesta de recolección de elementos no utilizados está deshabilitada. Los usuarios de Wasmtime que utilizan la versión 19.0.0 y posteriores se ven afectados por este problema. Hemos publicado las siguientes versiones de Wasmtime, todas las cuales tienen una solución para este error: * 21.0.2 * 22.0.1 * 23.0.3 * 24.0.1 * 25.0.2. --- truncada ---

Wasmtime es un entorno de ejecución de código abierto para WebAssembly. La implementación de Wasmtime de las llamadas finales de WebAssembly combinadas con los seguimientos de pila puede provocar un bloqueo del entorno de ejecución en determinados módulos de WebAssembly. El bloqueo del entorno de ejecución puede ser un comportamiento indefinido si Wasmtime se compiló con Rust 1.80 o una versión anterior. El bloqueo del entorno de ejecución es una interrupción determinista del proceso cuando Wasmtime se compila con Rust 1.81 y versiones posteriores. Las llamadas finales de WebAssembly son una propuesta que hace relativamente poco tiempo llegó a la etapa 4 del proceso de estandarización. Wasmtime habilitó por primera vez el soporte para llamadas finales de forma predeterminada en Wasmtime 21.0.0, aunque esa versión contenía un error en el que solo estaba activado de forma predeterminada para algunas configuraciones. En Wasmtime 22.0.0, las llamadas finales estaban habilitadas de forma predeterminada para todas las configuraciones. El fallo específico ocurre cuando una función exportada en un módulo (o componente) WebAssembly realiza una `return_call` (o `return_call_indirect` o `return_call_ref`) a una función host importada que captura un seguimiento de la pila (por ejemplo, la función host genera una trampa). En esta situación, el código de recorrido de pila asumía anteriormente que siempre había al menos un framework WebAssembly en la pila, pero con las llamadas de cola eso ya no es cierto. Con la propuesta de llamada de cola es posible que aparezca un trampolín de entrada como si llamara directamente al trampolín de salida. Esta situación activa una aserción interna en el código de recorrido de pila que genera un `panic!()` de Rust. Cuando Wasmtime se compila con las versiones 1.80 y anteriores de Rust, esto significa que una función `extern "C"` en Rust está generando un `panic!()`. Este es un comportamiento técnicamente indefinido y normalmente se manifiesta como un aborto del proceso cuando el desenrollador no puede desenrollar los frameworks generados por Cranelift. Cuando Wasmtime se compila con las versiones 1.81 y posteriores de Rust, este pánico se convierte en un aborto determinista del proceso. En general, el impacto de este problema es que se trata de un vector de denegación de servicio en el que un módulo o componente WebAssembly malintencionado puede provocar que el host se bloquee. No hay otro impacto en este momento que no sea la disponibilidad de un servicio, ya que el resultado del bloqueo es siempre un bloqueo y nada más. Este problema fue descubierto por un fuzzing de rutina realizado por el proyecto Wasmtime a través de la infraestructura OSS-Fuzz de Google. No tenemos evidencia de que un atacante lo haya explotado alguna vez. Todas las versiones de Wasmtime que tienen llamadas de cola habilitadas de manera predeterminada han sido parcheadas: * 21.0.x - parcheado en 21.0.2 * 22.0.x - parcheado en 22.0.1 * 23.0.x - parcheado en 23.0.3 * 24.0.x - parcheado en 24.0.1 * 25.0.x - parcheado en 25.0.2. Las versiones de Wasmtime desde 12.0.x (la primera versión con soporte experimental para llamadas de cola) hasta 20.0.x (la última versión con llamadas de cola desactivadas de manera predeterminada) tienen soporte para llamadas de cola, pero el soporte está deshabilitado de manera predeterminada. Estas versiones no se ven afectadas en sus configuraciones predeterminadas, pero los usuarios que habilitaron explícitamente el soporte para llamadas de cola deberán deshabilitar el soporte para llamadas de cola o actualizar a una versión parcheada de Wasmtime. La principal solución alternativa para este problema es deshabilitar la compatibilidad con las llamadas de cola en Wasmtime, por ejemplo con `Config::wasm_tail_call(false)`. De lo contrario, se recomienda a los usuarios que actualicen a versiones parcheadas.

Una vulnerabilidad de escalada de privilegios (PE) en la API XML del software PAN-OS de Palo Alto Networks permite que un administrador de PAN-OS autenticado con privilegios restringidos utilice una clave API XML comprometida para realizar acciones como administrador de PAN-OS con privilegios superiores. Por ejemplo, un administrador con acceso de "Administrador de sistema virtual (solo lectura)" podría utilizar una clave API XML de un "Administrador de sistema virtual" para realizar operaciones de escritura en la configuración del sistema virtual, aunque deberían estar limitadas a operaciones de solo lectura.

Una vulnerabilidad de escalada de privilegios en la aplicación Palo Alto Networks GlobalProtect en Windows permite que un usuario de Windows no administrativo autenticado localmente escale sus privilegios a NT AUTHORITY/SYSTEM mediante el uso de la funcionalidad de reparación ofrecida por el archivo .msi utilizado para instalar GlobalProtect.

Una vulnerabilidad de inyección de comandos del sistema operativo en Palo Alto Networks Expedition permite a un atacante autenticado ejecutar comandos del sistema operativo arbitrarios como root en Expedition, lo que resulta en la divulgación de nombres de usuario, contraseñas de texto plano, configuraciones de dispositivos y claves API de dispositivos de firewalls PAN-OS.

Una vulnerabilidad de almacenamiento de texto plano de información confidencial en Palo Alto Networks Expedition permite a un atacante autenticado revelar nombres de usuario, contraseñas y claves API del firewall generadas con esas credenciales.

Una vulnerabilidad XSS reflejado en Palo Alto Networks Expedition permite la ejecución de JavaScript malicioso en el contexto del navegador de un usuario autenticado de Expedition si ese usuario hace clic en un enlace malicioso, lo que permite ataques de phishing que podrían conducir al robo de sesiones del navegador de Expedition.