Vulnerabilidades

Ory Hydra es un servidor OAuth 2.0 y un proveedor de OpenID Connect. Antes de la versión 26.2.0, las API de administración listOAuth2Clients, listOAuth2ConsentSessions y listTrustedOAuth2JwtGrantIssuers en Ory Hydra son vulnerables a inyección SQL debido a fallos en su implementación de paginación. Los tokens de paginación se cifran usando el secreto configurado en `secrets.pagination`. Si este valor no está configurado, Hydra recurre a usar `secrets.system`. Un atacante que conoce este secreto puede crear sus propios tokens, incluyendo tokens maliciosos que conducen a inyección SQL. Este problema puede ser explotado cuando una o más API de administración listadas anteriormente son directa o indirectamente accesibles para el atacante; el atacante puede pasar un token de paginación sin procesar a la API afectada; y el valor de configuración `secrets.pagination` está configurado y es conocido por el atacante, o `secrets.pagination` no está configurado y `secrets.system` es conocido por el atacante. Un atacante puede ejecutar consultas SQL arbitrarias a través de tokens de paginación falsificados. Como primera línea de defensa, configure inmediatamente un valor personalizado para `secrets.pagination` generando un secreto aleatorio criptográficamente seguro. A continuación, actualice Hydra a la versión corregida, 26.2.0 lo antes posible.

ORY Oathkeeper es un Proxy de Identidad y Acceso (IAP) y una API de Decisión de Control de Acceso que autoriza solicitudes HTTP basándose en conjuntos de Reglas de Acceso. Ory Oathkeeper a menudo se despliega detrás de otros componentes como CDNs, WAFs o proxies inversos. Dependiendo de la configuración, otro componente podría reenviar la solicitud al proxy de Oathkeeper con un protocolo diferente (HTTP vs. HTTPS) que la solicitud original. Para hacer coincidir correctamente la solicitud con las reglas configuradas, Oathkeeper considera el encabezado 'X-Forwarded-Proto' al evaluar las reglas. La opción de configuración 'serve.proxy.trust_forwarded_headers' (por defecto es falso) rige si este y otros encabezados 'X-Forwarded-*' deben ser confiables. Antes de la versión 26.2.0, Oathkeeper no respetaba correctamente esta configuración y siempre consideraba el encabezado 'X-Forwarded-Proto'. Para que un atacante pueda abusar de esto, una instalación de Ory Oathkeeper necesita tener reglas distintas para solicitudes HTTP y HTTPS. Además, el atacante necesita poder activar una regla pero no la otra. En este escenario, el atacante puede enviar la misma solicitud pero con el encabezado 'X-Forwarded-Proto' para activar la otra regla. No esperamos que muchas configuraciones cumplan estas precondiciones. La versión 26.2.0 contiene un parche. Ory Oathkeeper respetará correctamente la configuración 'serve.proxy.trust_forwarded_headers' en adelante, eliminando así el escenario de ataque. Recomendamos actualizar a una versión corregida incluso si no se cumplen las precondiciones. Como mitigación adicional, generalmente se recomienda descartar cualquier encabezado inesperado lo antes posible cuando se maneja una solicitud, por ejemplo, en el WAF.

ORY Oathkeeper es un proxy de identidad y acceso (IAP) y una API de decisión de control de acceso que autoriza solicitudes HTTP basándose en conjuntos de reglas de acceso. Las versiones anteriores a la 26.2.0 son vulnerables a una omisión de autorización a través de un salto de ruta HTTP. Un atacante puede crear una URL que contenga secuencias de salto de ruta (por ejemplo, '/public/../admin/secrets') que se resuelva en una ruta protegida después de la normalización, pero que se compare con una regla permisiva porque la ruta sin procesar y sin normalizar se utiliza durante la evaluación de la regla. La versión 26.2.0 contiene un parche.

ORY Oathkeeper es un Proxy de Identidad y Acceso (IAP) y una API de Decisión de Control de Acceso que autoriza solicitudes HTTP basándose en conjuntos de Reglas de Acceso. Las versiones anteriores a la 26.2.0 son vulnerables a la omisión de autenticación debido a la confusión de claves de caché. La caché del autenticador `oauth2_introspection` no distingue los tokens que fueron validados con diferentes URL de introspección. Un atacante puede, por lo tanto, usar legítimamente un token para cebar la caché y posteriormente usar el mismo token para reglas que usan un servidor de introspección diferente. Ory Oathkeeper debe configurarse con múltiples servidores autenticadores `oauth2_introspection`, cada uno aceptando tokens diferentes. Los autenticadores también deben configurarse para usar el almacenamiento en caché. Un atacante tiene que tener una forma de obtener un token válido para uno de los servidores de introspección configurados. A partir de la versión 26.2.0, Ory Oathkeeper incluye la URL del servidor de introspección en la clave de caché, evitando la confusión de tokens. Actualice a la versión parcheada de Ory Oathkeeper. Si eso no es posible de inmediato, deshabilite el almacenamiento en caché para los autenticadores `oauth2_introspection`.

H3 es un framework H(TTP) mínimo. En las versiones 2.0.0-0 hasta la 2.0.1-rc.16, el método 'mount()' en h3 usa una simple verificación 'startsWith()' para determinar si las solicitudes entrantes caen bajo el prefijo de ruta de una subaplicación montada. Debido a que esta verificación no verifica un límite de segmento de ruta (es decir, que el siguiente carácter después de la base es '/' o el final de la cadena), el middleware registrado en un montaje como '/admin' también se ejecutará para rutas no relacionadas como '/admin-public', '/administrator' o '/adminstuff'. Esto permite a un atacante activar middleware de configuración de contexto en rutas que nunca se pretendió cubrir, potencialmente contaminando el contexto de la solicitud con indicadores de privilegio no deseados. La versión 2.0.2-rc.17 contiene un parche.

Ory Kratos es un sistema de identidad, gestión de usuarios y autenticación para servicios en la nube. Antes de la versión 26.2.0, la API de administración ListCourierMessages en Ory Kratos es vulnerable a inyección SQL debido a fallos en su implementación de paginación. Los tokens de paginación están cifrados usando el secreto configurado en 'secrets.pagination'. Un atacante que conoce este secreto puede crear sus propios tokens, incluyendo tokens maliciosos que conducen a inyección SQL. Si este valor de configuración no está establecido, Kratos recurre a un secreto de cifrado de paginación predeterminado. Debido a que este valor predeterminado es de conocimiento público, los atacantes pueden generar tokens de paginación válidos y maliciosos manualmente para instalaciones donde este secreto no está configurado. Como primera línea de defensa, configure inmediatamente un valor personalizado para 'secrets.pagination' generando un secreto aleatorio criptográficamente seguro. A continuación, actualice Kratos a una versión corregida, 26.2.0 o posterior, lo antes posible.

goxmlsig proporciona Firmas Digitales XML implementadas en Go. Antes de la versión 1.6.0, la función 'validateSignature' en 'validate.go' recorre las referencias en el bloque 'SignedInfo' para encontrar una que coincida con el ID del elemento firmado. En versiones de Go anteriores a la 1.22, o cuando 'go.mod' utiliza una versión anterior, existe un problema de captura de variable de bucle. El código toma la dirección de la variable de bucle '_ref' en lugar de su valor. Como resultado, si más de una referencia coincide con el ID o si la lógica del bucle es incorrecta, el puntero 'ref' siempre terminará apuntando al último elemento en el slice 'SignedInfo.References' después del bucle. goxmlsig versión 1.6.0 contiene un parche.

Roadiz es un sistema de gestión de contenido polimórfico basado en un sistema de nodos que puede manejar muchos tipos de servicios. Una vulnerabilidad en roadiz/documents anterior a las versiones 2.7.9, 2.6.28, 2.5.44 y 2.3.42 permite a un atacante autenticado leer cualquier archivo en el sistema de archivos local del servidor al que el proceso del servidor web tiene acceso, incluyendo variables de entorno altamente sensibles, credenciales de base de datos y archivos de configuración internos. Las versiones 2.7.9, 2.6.28, 2.5.44 y 2.3.42 contienen un parche.

Syft es una herramienta CLI y una biblioteca Go para generar una Lista de Materiales de Software (SBOM) a partir de imágenes de contenedor y sistemas de archivos. Las versiones de Syft anteriores a la v1.42.3 no limpiarían correctamente el almacenamiento temporal si este se agotaba durante un escaneo. Al escanear archivos, Syft desempaquetará esos archivos en el almacenamiento temporal y luego inspeccionará el contenido desempaquetado. Bajo operación normal, Syft eliminará los datos temporales que escribe después de completar un escaneo. Esta vulnerabilidad afectaría a los usuarios de Syft que estaban escaneando contenido que podría hacer que Syft llenara el almacenamiento temporal, lo que luego haría que Syft generara un error y saliera. Cuando se activa el error, Syft saldría sin eliminar correctamente los archivos temporales en uso. En nuestras pruebas, esto se reprodujo más fácilmente escaneando artefactos muy grandes o artefactos altamente comprimidos como una zipbomb. Debido a que Syft no limpiaría sus archivos temporales, el resultado sería el llenado del almacenamiento de archivos temporales, impidiendo futuras ejecuciones de Syft u otras utilidades del sistema que dependen de que el almacenamiento temporal esté disponible. El parche ha sido lanzado en la v1.42.3. Syft ahora limpia los archivos temporales cuando se encuentra una condición de error. No hay soluciones alternativas para esta vulnerabilidad en Syft. Los usuarios que encuentren su almacenamiento temporal agotado pueden eliminar manualmente los archivos temporales.

FileRise es un gestor de archivos autohospedado basado en web con carga de múltiples archivos, edición y operaciones por lotes. En las versiones 2.3.7 a la 3.10.0, el endpoint de fragmentos de archivo `/api/file/snippet.php` permite a un usuario autenticado con solo acceso 'read_own' a una carpeta recuperar contenido de fragmentos de archivos subidos por otros usuarios en la misma carpeta. Esto es una falla de autorización del lado del servidor en la aplicación de 'read_own' para las vistas previas al pasar el ratón. La versión 3.11.0 corrige el problema.

La versión 2.8.0 de Firecrawl y anteriores contienen una vulnerabilidad de omisión de protección de falsificación de petición del lado del servidor (SSRF) en el servicio de scraping de Playwright donde la validación de la política de red se aplica solo a la URL inicial proporcionada por el usuario y no a los destinos de redirección subsiguientes. Los atacantes pueden proporcionar una URL externamente válida que pasa la validación y devuelve una redirección HTTP a un recurso interno o restringido, permitiendo que el navegador siga la redirección y obtenga el destino final sin revalidación, obteniendo así acceso a servicios de red internos y puntos finales sensibles. Este problema es distinto de CVE-2024-56800, que describe la SSRF basada en redirección de forma general. Esta vulnerabilidad surge específicamente de una brecha de aplicación posterior a la redirección en las protecciones SSRF implementadas, donde la validación se aplica solo a la petición inicial y no al destino final redirigido.

Las versiones de los plugins de Mattermost <=11.4 11.0.4 11.1.3 11.3.2 10.11.11.0 no validan el tamaño de las solicitudes entrantes, lo que permite a un atacante autenticado causar interrupción del servicio a través del endpoint de webhook. ID de aviso de Mattermost: MMSA-2026-00589