CVE-2026-71210 in Mealie
Summary
by MITRE • 08/05/2026
Mealie's AsyncSafeTransport SSRF guard (mealie/pkgs/safehttp/transport.py) resolves a target hostname once, checks the resolved IP against private-range rules, but then issues the actual outbound HTTP request using the original hostname, which the underlying async transport re-resolves independently. Because the validated IP is never pinned to the actual connection, a DNS-rebinding attacker (returning a public IP to the validation lookup and a private/metadata IP to the real connection) defeats the guard. This is reachable by any authenticated user via /api/recipes/create/url, /api/recipes/test-scrape-url, and /api/recipes/{slug}/image, and the scraper reflects fetched content back to the requester, allowing an authenticated user to read internal HTTP services and cloud-metadata endpoints.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/05/2026
The vulnerability described represents a critical server-side request forgery flaw in Mealie's AsyncSafeTransport implementation that fundamentally undermines the security controls designed to prevent unauthorized access to internal network resources. This issue resides in the transport.py file within the mealie/pkgs/safehttp/transport.py module where the security mechanism performs hostname resolution only once for validation purposes but fails to maintain that resolved state throughout the actual HTTP transaction process. The flaw creates a window of opportunity for attackers to exploit DNS rebinding techniques by manipulating the DNS responses during different phases of the request lifecycle.
The technical implementation of this vulnerability stems from a fundamental design flaw in how hostname validation is performed within the async HTTP transport layer. When an authenticated user submits a URL through any of the vulnerable endpoints including /api/recipes/create/url, /api/recipes/test-scrape-url, or /api/recipes/{slug}/image, the system initially resolves the target hostname to verify it doesn't point to private network ranges such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. However, the validation occurs on a single resolution attempt while the actual HTTP request uses the original hostname without pinning the resolved IP address to prevent subsequent DNS lookups that could return different results. This architectural gap creates a race condition where the validation check passes but the real connection operates with potentially different DNS resolution behavior.
The operational impact of this vulnerability is severe and directly enables authenticated users to bypass network segmentation controls and access internal HTTP services, cloud metadata endpoints, and other sensitive resources that should remain isolated from external access. The scraper functionality within Mealie's recipe handling system plays a crucial role in amplifying the attack surface since it reflects fetched content back to the requester, meaning an attacker can not only access internal resources but also exfiltrate information directly through the response payload. This creates a powerful reconnaissance and data extraction capability for any authenticated user who can submit malicious URLs through the exposed API endpoints.
This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF) which specifically addresses situations where applications fail to properly validate or restrict external requests to internal resources. The implementation also maps to ATT&CK technique T1071.004 Application Layer Protocol: DNS where attackers manipulate DNS resolution behavior to bypass security controls, and T1083 File and Directory Discovery which could be facilitated through access to metadata endpoints that reveal internal system information. The asynchronous nature of the transport mechanism combined with the lack of proper hostname pinning creates an environment where DNS rebinding attacks can successfully defeat network security controls, effectively transforming what should be a protected internal resource into an accessible attack vector.
The recommended mitigations for this vulnerability require implementing strict hostname pinning mechanisms within the HTTP transport layer to ensure that DNS resolution results remain consistent throughout the entire request lifecycle. Organizations should implement comprehensive hostname validation that prevents any subsequent DNS lookups from occurring during the actual connection phase, and establish proper network segmentation controls that isolate internal services from user-accessible endpoints. Additionally, input sanitization and URL parsing should be enhanced to prevent manipulation of DNS behavior through crafted hostnames or domain names that could trigger the vulnerability. The implementation should also include monitoring and logging of outbound HTTP requests to detect anomalous patterns that might indicate exploitation attempts.