Vulnerabilidades

Se descubrió una vulnerabilidad de denegación de servicio (DOS) en el componente RSFiles! 1.16.3-1.17.7 de Joomla. El problema permite a atacantes remotos no autenticados denegar el acceso al servicio mediante la función de búsqueda.

Se descubrió una vulnerabilidad XSS almacenado en el componente RSDirectory! 1.0.0-2.2.8 de Joomla. El problema permite a atacantes remotos autenticados inyectar código web o HTML arbitrario mediante el componente de respuesta a reseñas.

Se descubrió una vulnerabilidad XSS almacenado en el componente RSBlog! 1.11.6-1.14.5 de Joomla. El problema permite a usuarios remotos autenticados inyectar código web o HTML arbitrario mediante el parámetro jform[tags_text].

Una vulnerabilidad de inyección SQL en las versiones 1.0.0-1.4.1 del complemento JS Jobs para Joomla permite a usuarios con bajos privilegios ejecutar comandos SQL arbitrarios a través del parámetro 'cvid' en la función de aplicación de empleados.

Una vulnerabilidad de inyección SQL en el complemento Balbooa Forms 1.0.0-2.3.1.1 para Joomla permite a usuarios privilegiados ejecutar comandos SQL arbitrarios a través del parámetro 'id'.

Una vulnerabilidad XSS almacenado en el complemento Balbooa Gallery 1.0.0-2.4.0 para Joomla permite a usuarios privilegiados almacenar scripts maliciosos en los elementos de la galería.

La vulnerabilidad de condición de ejecución de tiempo de verificación a tiempo de uso potencialmente permitió que un atacante usara el software de seguridad ESET instalado para borrar el contenido de un archivo arbitrario en el sistema de archivos.

El complemento LoginPress Pro para WordPress es vulnerable a la omisión de autenticación en todas las versiones hasta la 5.0.1 incluida. Esto se debe a una verificación insuficiente del usuario que devuelve el token de inicio de sesión social. Esto permite que atacantes no autenticados inicien sesión como cualquier usuario del sitio, como un administrador, si tienen acceso al correo electrónico y el usuario no tiene una cuenta existente en el servicio que devuelve el token.

Las versiones de Mattermost 10.5.x <= 10.5.6, 10.8.x <= 10.8.1, 10.7.x <= 10.7.3, 9.11.x <= 9.11.16 no pueden verificar la autorización al recuperar publicaciones en caché mediante PendingPostID, lo que permite que un usuario autenticado lea publicaciones en canales privados a los que no tiene acceso al adivinar el PendingPostID de publicaciones creadas recientemente.

Se ha identificado una vulnerabilidad de redirección abierta en Grafana OSS que puede explotarse para realizar ataques XSS. Esta vulnerabilidad se introdujo en Grafana v11.5.0. La redirección abierta puede combinarse con vulnerabilidades de path traversal para lograr XSS. Corregida en las versiones 12.0.2+security-01, 11.6.3+security-01, 11.5.6+security-01, 11.4.6+security-01 y 11.3.8+security-01.

Se ha identificado una vulnerabilidad de redirección abierta en la funcionalidad de cambio de organización de Grafana OSS. Requisitos para su explotación: - Deben existir varias organizaciones en la instancia de Grafana. - La víctima debe pertenecer a una organización diferente a la especificada en la URL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eventpoll: no decrementar el recuento de referencias de ep mientras se mantiene el mutex de ep. Jann Horn señala que epoll decrementa el recuento de referencias de ep y luego ejecuta un mutex_unlock(&ep->mtx);. Esto es totalmente erróneo, ya que puede provocar un use-after-free. Este patrón funciona correctamente para la última referencia, ya que el código en cuestión retrasará la llamada a "ep_free(ep)" hasta después de desbloquear el mutex. Sin embargo, es incorrecto para el caso mucho más sutil del penúltimo, cuando alguien *más* también podría eliminar su referencia y liberar el ep mientras aún usamos el mutex. Cabe destacar que esto es cierto incluso si ese otro usuario también usa el mismo mutex de ep: los mutex, a diferencia de los spinlocks, no se pueden usar para la propiedad de objetos, incluso si garantizan la exclusión mutua. Una operación de desbloqueo de mutex no es atómica, y como un usuario sigue accediendo al mutex durante el proceso de desbloqueo, otro usuario puede acceder y obtener el mutex liberado, liberando así la estructura de datos mientras el primer usuario realiza la limpieza. Consulte nuestra documentación sobre mutex en Documentation/locking/mutex-design.rst, en particular la sección [1] sobre semántica: «mutex_unlock() puede acceder a la estructura del mutex incluso después de haber liberado el bloqueo internamente; por lo tanto, no es seguro que otro contexto adquiera el mutex y asuma que el contexto mutex_unlock() ya no utiliza la estructura». Por lo tanto, si eliminamos nuestra referencia ep antes del desbloqueo del mutex, pero no fuimos los últimos, podríamos desbloquear el mutex; otro usuario entra, elimina su referencia y libera el 'ep', ya que ya no tiene usuarios, todo mientras mutex_unlock() sigue accediendo a él. Arregle esto simplemente moviendo el refcount ep que cae fuera del mutex: el refcount en sí es atómico y no necesita protección de mutex (ese es el _objetivo_ de los refcounts: a diferencia de los mutex, son inherentemente acerca de la duración de los objetos).