CVE-2026-33644: 
NixOS vulnerability analysis and mitigation

CVE-2026-33644 is a Server-Side Request Forgery (SSRF) bypass vulnerability in Lychee, a free open-source photo-management tool. The flaw exists in PhotoUrlRule.php, where the SSRF protection can be circumvented via DNS rebinding because the IP validation check only activates when the hostname is a literal IP address — domain names bypass it entirely. All versions up to and including 7.5.1 are affected; version 7.5.2 contains the fix. The vulnerability was published on March 26, 2026, with a CVSS v3.1 base score of 4.3 (Medium) per NVD and a CVSS v4.0 base score of 2.3 (Low) (GitHub Advisory).

The root cause is CWE-918 (Server-Side Request Forgery), specifically an incomplete input validation in app/Rules/PhotoUrlRule.php. The vulnerable code at lines 86–89 calls filter_var($host, FILTER_VALIDATE_IP), which returns false for domain names, causing the entire private-IP block check to be skipped. An attacker exploits this by supplying a URL whose hostname is controlled via a DNS rebinding service (e.g., 127.0.0.1.nip.io), which resolves to an internal IP after the validation step, allowing the server to make requests to internal resources via fopen($url). The localhost literal check (lines 96–99) was similarly limited to only three hardcoded strings (localhost, 127.0.0.1, ::1), leaving other loopback representations unblocked. The fix resolves the hostname to its IP addresses using dns_get_record() before performing the private/reserved IP check (GitHub Advisory, Patch Commit).

A low-privileged authenticated attacker can leverage this vulnerability to make the Lychee server issue HTTP requests to internal network resources that should not be externally accessible, including cloud metadata endpoints (e.g., 169.254.169.254), localhost services, and other internal HTTP services reachable from the Lychee host. The primary impact is limited confidentiality loss — an attacker may read responses from internal services — with no integrity or availability impact. The scope is limited to the network context of the Lychee server, but in cloud environments, access to metadata endpoints could expose credentials enabling lateral movement (GitHub Advisory).

A proof-of-concept exploit is documented in the GitHub Security Advisory, providing concrete reproduction steps including the specific endpoint (POST /api/v2/Photo::fromUrl) and payload format using a DNS rebinding service. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.038%, reflecting low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low-privilege authentication, which limits opportunistic mass exploitation (GitHub Advisory).

1. Authenticate: Log in to the target Lychee instance with any valid low-privilege user account.
2. Set up DNS rebinding domain: Use a public DNS rebinding service such as nip.io (e.g., 127.0.0.1.nip.io) or a custom DNS server that resolves a controlled domain to an internal IP address like 127.0.0.1 or 169.254.169.254.
3. Craft the SSRF payload: Construct a POST request targeting the photo import endpoint with the rebinding domain as the URL:

POST /api/v2/Photo::fromUrl
Content-Type: application/json

{"urls": ["http://127.0.0.1.nip.io/internal-endpoint"]}

4. Bypass validation: The PhotoUrlRule::validate() method calls filter_var('127.0.0.1.nip.io', FILTER_VALIDATE_IP), which returns false for the domain name, skipping the private IP block check entirely.
5. Trigger server-side request: The Lychee server resolves the hostname via DNS (returning 127.0.0.1) and issues an HTTP request to the internal endpoint via fopen($url), returning the response content.
6. Exfiltrate data: Review the server's response to extract data from internal services, cloud metadata endpoints, or localhost services (GitHub Advisory).

• Network: Outbound HTTP requests from the Lychee server to internal IP ranges (10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x) or cloud metadata endpoints (169.254.169.254); DNS queries for rebinding domains such as *.nip.io, *.xip.io, or similar services resolving to private IPs.
• Logs: Lychee/Laravel application logs showing POST requests to /api/v2/Photo::fromUrl with URLs containing DNS rebinding hostnames; HTTP client errors or unexpected responses from internal hosts logged by the PHP fopen or HTTP client layer.
• Process: Unusual outbound TCP connections on port 80/443 from the PHP-FPM or web server process to loopback (127.x.x.x) or link-local (169.254.x.x) addresses.

Upgrade Lychee to version 7.5.2 or later, which resolves the hostname to its IP addresses using dns_get_record() before performing private/reserved IP validation, closing the DNS rebinding bypass (Patch Commit). As an interim workaround, implement network-level egress filtering on the Lychee application server to block outbound connections to private IP ranges and cloud metadata endpoints. Additionally, consider enabling DNS pinning or deploying a DNS resolver that blocks resolution of public domains to private IP ranges (DNS rebinding protection at the resolver level).

The vulnerability was reported by researcher morimori-dev and remediated by Lychee maintainer ildyria, who published the advisory and patch on March 22–26, 2026. No significant broader media coverage or notable community commentary beyond the GitHub advisory has been identified.