CVE-2026-57569 in Lychee
Summary
by MITRE • 10/15/2026
Lychee is a free, open-source photo-management tool. Prior to 7.6.0, the POST /api/v2/Photo::fromUrl flow validates a hostname and its resolved addresses in app/Rules/PhotoUrlRule.php but later passes the original hostname through app/Actions/Import/FromUrl.php to app/Image/Files/DownloadedFile.php for a separate fopen connection. An authenticated attacker who controls DNS responses can cause validation to observe a public address and the subsequent fetch to resolve the same hostname to a private or otherwise forbidden address. This DNS rebinding time-of-check to time-of-use mismatch bypasses the intended server-side request forgery protections and can reach services available from the Lychee server, subject to deployment and TLS behavior. This issue is fixed in version 7.6.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Lychee prior to version 7.6.0 represents a classic Server-Side Request Forgery (SSRF) flaw rooted in a time-of-check to time-of-use race condition within the application's URL validation logic. The core issue resides in how the system handles external image imports via the POST /api/v2/Photo::fromUrl endpoint. When an authenticated user submits a URL for import, the application initiates a security check by validating the hostname and its resolved IP addresses through the app/Rules/PhotoUrlRule.php module. This validation step is designed to ensure that the target address does not fall within private or reserved IP ranges, thereby preventing access to internal network resources. However, this verification process operates on a snapshot of DNS resolution at a specific moment in time.
The critical technical flaw emerges because the validated hostname and its resolved addresses are not passed directly to the file download mechanism. Instead, the original unvalidated hostname string is forwarded through app/Actions/Import/FromUrl.php to app/Image/Files/DownloadedFile.php for the actual HTTP request execution using fopen. This architectural separation creates a window of opportunity where an attacker who controls DNS responses can manipulate the resolution outcome between the initial validation and the subsequent connection attempt. By rapidly changing the DNS record associated with the hostname, the application may validate against one IP address while attempting to connect via another.
This mechanism allows for effective SSRF bypasses through DNS rebinding techniques. An authenticated attacker can configure their controlled domain to initially resolve to a public IP address that passes the internal range check, and then immediately switch the resolution to point toward private or forbidden addresses such as 127.0.0.1, 192.168.x.x, or other internal service endpoints when the actual connection is established. This bypasses the intended server-side request forgery protections because the security control only inspects the state of the DNS record at validation time rather than enforcing consistency throughout the entire lifecycle of the network operation. The operational impact includes the potential for unauthorized access to internal services, data exfiltration from local networks, and reconnaissance of infrastructure components that are not exposed to the public internet but remain accessible from the Lychee server's network interface.
The severity of this vulnerability is heavily influenced by the deployment environment and TLS configuration. If the target application or adjacent services do not enforce strict certificate validation or if they accept self-signed certificates common in internal deployments, the attack surface expands significantly. Furthermore, the requirement for authentication limits the scope to compromised user accounts or users with import privileges, but it does not mitigate the risk entirely given that account compromise is a frequent vector in broader cyber attacks. The vulnerability aligns with CWE-20 Improper Input Validation and CWE-346 Origin Validation Error within the Common Weakness Enumeration framework. In terms of tactical classification under MITRE ATT&CK, this behavior corresponds to T1557 Adversary-in-the-Middle or more specifically SSRF techniques often categorized under lateral movement or discovery phases depending on the ultimate goal of accessing internal assets.
To mitigate this risk and prevent similar vulnerabilities in future development cycles, it is essential to enforce strict DNS resolution consistency throughout the request lifecycle. One effective approach involves resolving the hostname at the point of use rather than relying on pre-validated strings, ensuring that the IP address used for connection matches the one validated during input checks. Alternatively, applications should perform a final validation check immediately before initiating the network connection using the actual resolved IP to confirm it has not changed. Implementing allowlists for permitted domains and blocking known private or reserved IP ranges at the firewall level can also provide defense in depth. Upgrading Lychee to version 7.6.0 or later resolves this issue by addressing these architectural gaps, ensuring that validation is tightly coupled with execution without allowing intermediate manipulation of DNS responses.