Server-Side Request Forgery (SSRF) en parisneo/lollms

La vulnerabilidad SSRF en lollms permite a un atacante explotar el endpoint /api/files/export-content para realizar solicitudes HTTP arbitrarias. Esto significa que el atacante puede acceder a recursos internos de la red que normalmente no serían accesibles desde el exterior. El atacante podría, por ejemplo, escanear puertos internos, acceder a metadatos de la nube (como credenciales de AWS o Azure), o incluso intentar acceder a servicios internos que expongan información sensible. En escenarios más graves, esta vulnerabilidad podría ser utilizada como punto de partida para la ejecución remota de código, aunque esto dependería de la configuración y los servicios internos expuestos.

Organizations deploying lollms in environments with sensitive internal services or cloud metadata are at significant risk. Shared hosting environments where lollms is running alongside other applications are particularly vulnerable, as a compromised lollms instance could be used to pivot to other systems on the same host. Any deployment relying on the /api/files/export-content endpoint without proper input validation is potentially exposed.

• python / server:

# Check for outbound requests to unusual IP ranges in lollms logs
grep -i '169.254.169.254' /var/log/lollms/api.log

• generic web:

# Check access logs for requests to cloud metadata endpoints
grep -i '169.254.169.254' /var/log/nginx/access.log

1. 2026-03-29Disclosure

   disclosure

1. Reservado2026-01-01
2. Publicada2026-03-29
3. Modificada2026-03-30
4. EPSS actualizado2026-04-06

La mitigación principal para esta vulnerabilidad es actualizar lollms a la versión 2.2.0 o superior, donde se ha corregido el problema de validación de URLs. Si la actualización no es inmediatamente posible, se recomienda implementar reglas en un proxy inverso o firewall de aplicaciones web (WAF) para bloquear solicitudes a /api/files/export-content que contengan URLs sospechosas o que apunten a recursos internos. Además, se debe revisar la configuración de la aplicación para asegurar que no se expongan servicios internos innecesariamente. Tras la actualización, verificar la corrección de la vulnerabilidad intentando acceder al endpoint con una URL interna y confirmando que la solicitud es bloqueada.