CVE-2025-53018
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2025-06-27

Last updated on: 2025-06-30

Assigner: GitHub, Inc.

Description
Lychee is a free, open-source photo-management tool. Prior to version 6.6.13, a critical Server-Side Request Forgery (SSRF) vulnerability exists in the `/api/v2/Photo::fromUrl` endpoint. This flaw lets an attacker instruct the application’s backend to make HTTP requests to any URL they choose. Consequently, internal network resourcesβ€”such as localhost services or cloud-provider metadata endpointsβ€”become reachable. The endpoint takes a URL from the user and calls it server-side via fopen() without any safeguards. There is no IP address validation, nor are there any allow-list, timeout, or size restrictions. Because of this, attackers can point the application at internal targets. Using this flaw, an attacker can perform internal port scans or retrieve sensitive cloud metadata. Version 6.6.13 contains a patch for the issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-27
Last Modified
2025-06-30
Generated
2026-05-07
AI Q&A
2025-06-27
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-918 The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2025-53018 is a Server-Side Request Forgery (SSRF) vulnerability in the Lychee photo management application, specifically in the /api/v2/Photo::fromUrl endpoint. This flaw allows an attacker to make the backend server perform HTTP requests to any URL they choose, including internal network resources like localhost services or cloud provider metadata endpoints. The vulnerability exists because the endpoint accepts user-supplied URLs and fetches them server-side using PHP's fopen() without any validation, allow-listing, or restrictions on IP addresses, protocols, timeouts, or response sizes. This can be exploited to perform internal port scans or retrieve sensitive metadata. The issue was fixed in version 6.6.13 by adding strict URL validation and configuration options to block internal IPs, localhost, non-HTTPS URLs, and forbidden ports. [1, 2]


How can this vulnerability impact me? :

This vulnerability can impact you by allowing attackers to make the Lychee backend server send HTTP requests to arbitrary URLs, including internal network resources that are normally inaccessible externally. This can lead to unauthorized access to sensitive internal services, internal port scanning, and retrieval of sensitive cloud metadata such as instance credentials or configuration data. Such unauthorized access can compromise the security of your internal network and cloud environment. [1]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by testing the /api/v2/Photo::fromUrl endpoint for SSRF behavior. A proof of concept involves running a simple HTTP server on a local machine and sending a POST request to the vulnerable endpoint with a URL pointing to the attacker's server. If the Lychee backend makes a GET request to that URL, the SSRF is confirmed. For detection, you can use curl or similar tools to send crafted POST requests to the endpoint with URLs pointing to internal resources (e.g., http://127.0.0.1 or http://169.254.169.254/latest/meta-data) and observe if the server attempts to fetch them. Example command: curl -X POST -H "Content-Type: application/json" -d '{"url":"http://127.0.0.1"}' https://your-lychee-instance/api/v2/Photo::fromUrl [1]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include upgrading Lychee to version 6.6.13 or later, which contains the patch for this SSRF vulnerability. The patch implements strict URL validation by enforcing HTTPS usage, restricting allowed ports to 80 and 443, blocking URLs pointing to localhost and private IP addresses, and validating URL syntax. Additionally, configuring the application to enable these restrictions (such as import_via_url_forbidden_localhost, import_via_url_forbidden_local_ip, import_via_url_require_https, and import_via_url_forbidden_ports) will help prevent exploitation. If upgrading immediately is not possible, consider blocking or monitoring requests to the /api/v2/Photo::fromUrl endpoint and restricting outbound HTTP requests from the server to internal IP ranges. [1, 2]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart