CVE-2026-0560: Lollms SSRF Vulnerability

CVE-2026-0560 Overview

A Server-Side Request Forgery (SSRF) vulnerability exists in parisneo/lollms versions prior to 2.2.0, specifically in the /api/files/export-content endpoint. The _download_image_to_temp() function in backend/routers/files.py fails to validate user-controlled URLs, allowing attackers to make arbitrary HTTP requests to internal services and cloud metadata endpoints. This vulnerability can lead to internal network access, cloud metadata access, information disclosure, port scanning, and potentially remote code execution.

Critical Impact

Unauthenticated attackers can exploit this SSRF vulnerability to access internal network resources, retrieve cloud provider metadata credentials, and potentially achieve remote code execution through chained attacks.

Affected Products

• lollms versions prior to 2.2.0
• parisneo/lollms (all installations using the vulnerable /api/files/export-content endpoint)
• Systems running lollms with network access to internal services or cloud metadata endpoints

Discovery Timeline

• 2026-03-29 - CVE-2026-0560 published to NVD
• 2026-03-31 - Last updated in NVD database

Technical Details for CVE-2026-0560

Vulnerability Analysis

This SSRF vulnerability exists due to insufficient input validation in the lollms file export functionality. The _download_image_to_temp() function accepts user-supplied URLs without proper sanitization or allowlist validation. When processing requests to the /api/files/export-content endpoint, the application blindly follows user-provided URLs, enabling attackers to redirect server-side requests to arbitrary destinations.

The vulnerability is particularly dangerous in cloud environments where attackers can target metadata endpoints (such as http://169.254.169.254/ on AWS) to retrieve instance credentials, IAM roles, and sensitive configuration data. Internal network scanning becomes trivial as attackers can enumerate services behind firewalls that would otherwise be inaccessible.

Root Cause

The root cause is the absence of URL validation in the _download_image_to_temp() function located in backend/routers/files.py. The function directly processes user-controlled URLs without implementing security controls such as protocol allowlisting (restricting to HTTP/HTTPS only), destination IP blocking (preventing requests to private IP ranges and localhost), or domain allowlisting. This lack of defense-in-depth allows attackers to manipulate the server into making requests on their behalf.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can craft malicious requests to the /api/files/export-content endpoint, supplying URLs pointing to internal resources or cloud metadata services. The server processes these requests and returns the response content to the attacker, effectively acting as a proxy to bypass network segmentation and firewall protections.

The vulnerability mechanism works as follows: when the /api/files/export-content endpoint receives a request containing a URL parameter, the _download_image_to_temp() function retrieves the content at that URL without validation. Attackers can supply URLs targeting internal IP ranges (e.g., http://192.168.1.1/admin), cloud metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/), or localhost services (e.g., http://127.0.0.1:6379/). The server fetches the content and returns it to the attacker, enabling reconnaissance, credential theft, and further exploitation. For detailed technical information, see the Huntr Bounty Listing.

Detection Methods for CVE-2026-0560

Indicators of Compromise

• Outbound HTTP requests from the lollms server to internal IP ranges (10.x.x.x, 172.16.x.x-172.31.x.x, 192.168.x.x)
• Requests to cloud metadata endpoints such as 169.254.169.254, metadata.google.internal, or Azure metadata services
• Unusual request patterns to the /api/files/export-content endpoint with suspicious URL parameters
• Server-side connections to localhost or loopback addresses from the application context

Detection Strategies

• Monitor network traffic for outbound connections from the lollms application to RFC 1918 private address spaces
• Implement Web Application Firewall (WAF) rules to detect SSRF patterns in URL parameters targeting internal resources
• Configure intrusion detection systems to alert on requests containing metadata endpoint URLs
• Review application logs for anomalous requests to the /api/files/export-content endpoint with non-standard URL schemes or internal destinations

Monitoring Recommendations

• Enable detailed logging for all requests to the /api/files/export-content endpoint including full URL parameters
• Set up alerts for connections to cloud metadata IP addresses (169.254.169.254) originating from application servers
• Monitor for port scanning behavior patterns where multiple internal ports are probed in sequence
• Implement egress filtering and log all denied outbound connection attempts from the application tier

How to Mitigate CVE-2026-0560

Immediate Actions Required

• Upgrade lollms to version 2.2.0 or later which contains the security fix
• If immediate upgrade is not possible, restrict network access to the lollms application using firewall rules
• Block outbound connections from the lollms server to internal network ranges and cloud metadata endpoints
• Review access logs for evidence of prior exploitation attempts

Patch Information

The vulnerability has been addressed in lollms version 2.2.0. The fix is available in commit 76a54f0df2df8a5b254aa627d487b5dc939a0263. Administrators should update to the patched version by pulling the latest release from the official repository. For details on the specific code changes, refer to the GitHub Commit Changes.

Workarounds

• Implement network-level egress filtering to prevent the lollms server from connecting to internal IP ranges and metadata endpoints
• Deploy a reverse proxy or WAF in front of the application to filter requests containing suspicious URL patterns
• Restrict access to the /api/files/export-content endpoint to trusted users only via authentication controls
• If the export functionality is not required, consider disabling or removing the affected endpoint entirely

Network segmentation example for blocking SSRF targets:

# Block outbound connections to private IP ranges from application server
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 169.254.169.254 -j DROP