DNS-rebinding TOCTOU in mealie-recipes Mealie SSRF guard

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.

• The CNA record identifies vendor mealie-recipes, product mealie, and marks version 0 as affected; default_status is unknown.
• The GitHub Advisory Database lists affected versions and patched versions as unknown.
• No branch-specific range, additional deployment condition, or fixed release is confirmed. Other versions or parallel branches should not be assumed safe from the available evidence alone.

The flaw is in AsyncSafeTransport at mealie/pkgs/safehttp/transport.py. For a user-controlled hostname, the transport resolves the hostname once and checks the resulting IP against private-range blocking rules. The subsequent HTTP request still uses the original hostname, allowing the underlying async transport to resolve it again instead of pinning the connection to the validated IP. A DNS-rebinding attacker can return a public address during validation and an internal or metadata address during the actual connection, bypassing the SSRF guard. The GitHub Advisory Database states that the path is reachable by authenticated users through /api/recipes/create/url, /api/recipes/test-scrape-url, and /api/recipes/{slug}/image, and that fetched content is reflected back to the requester. The available sources do not fully document the DNS timing and network conditions required to control both resolutions.

The flaw is remotely reachable over the network by an authenticated user and does not require additional user interaction. Exploitation complexity is high because the attacker must control or coordinate DNS responses between the validation lookup and the actual connection. The available evidence identifies the affected recipe URL and image operations but does not document a working public exploit or a named campaign. The supplied record marks public_exploit as false and known_exploited as null; the CISA assessment displayed in the researched source records exploitation as none and automatable as no. These status assessments do not prove that exploitation is impossible.

The direct technical outcome is that the SSRF guard can be bypassed with DNS rebinding, allowing Mealie to connect to a private or metadata address even though the initial validation observed a public address. The attacker needs a Mealie account but no additional user interaction. The impact is limited to resources reachable from the Mealie server and to what the target service returns to the requester; the sources do not establish that authentication on the target service can always be bypassed. Organisational consequences may include disclosure of internal data, workload identity information, or temporary cloud credentials. The available evidence does not show that the flaw directly enables data modification or service unavailability.

An authenticated user may cause the Mealie server to send requests to services reachable only from the server's internal network. Responses from internal services or cloud metadata may be returned to the requester, exposing sensitive information if those endpoints provide valuable data. Possible consequences include internal service discovery, access to administrative interfaces that are not publicly exposed, and retrieval of workload identity or temporary cloud credentials, but the sources do not confirm a specific data disclosure. The record does not describe a direct ability to modify data or disrupt service.

1. No fixed release is confirmed in the record or in the sources reviewed. Follow Mealie's advisory and release information, and close remediation only after a specific release containing the fix has been identified and verified for each deployed branch.
2. Until a confirmed fix is available, apply network-layer egress filtering so the Mealie server cannot reach unnecessary private, loopback, link-local, or cloud metadata networks. This is a compensating control, not a confirmed vendor patch.
3. Restrict access to URL scraping and URL-based image download functions until the transport can be verified to pin the connection to the address that was checked.
4. After updating, review AsyncSafeTransport to confirm that the validated address is used for the outbound connection and that the underlying transport does not independently re-resolve the original hostname.

1. Inventory Mealie deployments and identify instances where authenticated users can use recipe import or URL-based image download features.
2. Check for the mealie/pkgs/safehttp/transport.py component and use of AsyncSafeTransport; do not treat a deployment's current branch as evidence that it is fixed because no fixed release is established by the available sources.
3. Review outbound traffic and DNS activity originating from Mealie during requests to /api/recipes/create/url, /api/recipes/test-scrape-url, and /api/recipes/{slug}/image, especially when destinations are private, loopback, link-local, or cloud metadata addresses.
4. Correlate blocked requests or connections to internal addresses with the requesting user, time, and submitted URL. This is precautionary behavior-based monitoring, not a source-confirmed IOC.
5. Absence of matching logs or connections does not prove that a deployment is safe.