Mealie

Mealie before 3.21.0 fails to validate user ownership in the ratings and favorites endpoints, allowing authenticated attackers to read any user's recipe ratings and favorites by specifying arbitrary user IDs in the URL path. Attackers can access private recipe identifiers, rating values, and favorite flags belonging to other users across different groups or households.

Published: 2026-09-18T16:04:48.581Z
Updated: 2026-09-18T17:25:44.305Z

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.

Published: 2026-08-05T06:59:19.902Z
Updated: 2026-08-10T11:45:15.487Z

Mealie is a self hosted recipe manager and meal planner. Prior to 1.4.0, an attacker can point the image request to an arbitrarily large file. Mealie will attempt to retrieve this file in whole. If it can be retrieved, it may be stored on the file system in whole (leading to possible disk consumption), however the more likely scenario given resource limitations is that the container will OOM during file retrieval if the target file size is greater than the allocated memory of the container. At best this can be used to force the container to infinitely restart due to OOM (if so configured in `docker-compose.yml), or at worst this can be used to force the Mealie container to crash and remain offline. In the event that the file can be retrieved, the lack of rate limiting on this endpoint also permits an attacker to generate ongoing requests to any target of their choice, potentially contributing to an external-facing DoS attack. This vulnerability is fixed in 1.4.0.

Published: 2024-04-19T21:11:37.890Z
Updated: 2024-10-25T19:44:11.865Z

Mealie is a self hosted recipe manager and meal planner. Prior to 1.4.0, the scrape_image function will retrieve an image based on a user-provided URL, however the provided URL is not validated to point to an external location and does not have any enforced rate limiting. The response from the Mealie server will also vary depending on whether or not the target file is an image, is not an image, or does not exist. Additionally, when a file is retrieved the file may remain stored on Mealie’s file system as original.jpg under the UUID of the recipe it was requested for. If the attacker has access to an admin account (e.g. the default changeme@example.com), this file can then be retrieved. Note that if Mealie is running in a development setting this could be leveraged by an attacker to retrieve any file that the Mealie server had downloaded in this fashion without the need for administrator access. This vulnerability is fixed in 1.4.0.

Published: 2024-04-19T21:02:56.989Z
Updated: 2024-08-02T01:59:50.901Z

Mealie is a self hosted recipe manager and meal planner. Prior to 1.4.0, the safe_scrape_html function utilizes a user-controlled URL to issue a request to a remote server, however these requests are not rate-limited. While there are efforts to prevent DDoS by implementing a timeout on requests, it is possible for an attacker to issue a large number of requests to the server which will be handled in batches based on the configuration of the Mealie server. The chunking of responses is helpful for mitigating memory exhaustion on the Mealie server, however a single request to an arbitrarily large external file (e.g. a Debian ISO) is often sufficient to completely saturate a CPU core assigned to the Mealie container. Without rate limiting in place, it is possible to not only sustain traffic against an external target indefinitely, but also to exhaust the CPU resources assigned to the Mealie container. This vulnerability is fixed in 1.4.0.

Published: 2024-04-19T20:49:18.141Z
Updated: 2024-08-02T01:59:50.836Z