Logan Maclaren

**Name of the Vulnerable Software and Affected Versions** Mealie versions prior to 1.4.0 **Description** The issue concerns the `safe scrape html` function, which uses a user-controlled URL to issue a request to a remote server. This function does not restrict the URL that can be provided, allowing an attacker to potentially identify HTTP(s) servers on the local network with any IP/port combination. The vulnerability can be exploited by any authenticated user, and since any user can create an account on a Mealie server by default, this poses a significant risk. The default user `changeme@example.com` with a hard-coded password is also available, further increasing the vulnerability. **Recommendations** For versions prior to 1.4.0, update to version 1.4.0 to resolve the issue. As a temporary workaround, consider restricting access to the `safe scrape html` function until the update can be applied. Additionally, changing the default user's password and restricting account creation can help minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Mealie versions prior to 1.4.0 **Description** The issue arises from the `safe scrape html` function, which uses a user-controlled URL to make requests to a remote server without rate limiting. Although there are efforts to prevent DDoS attacks by implementing timeouts, an attacker can still issue a large number of requests that will be handled in batches based on the Mealie server configuration. The chunking of responses helps mitigate memory exhaustion, but a single request to a large external file can saturate a CPU core assigned to the Mealie container. Without rate limiting, it is possible to sustain traffic against an external target indefinitely and exhaust the CPU resources assigned to the Mealie container. **Recommendations** For versions prior to 1.4.0, update to version 1.4.0 to resolve the issue. As a temporary workaround, consider implementing rate limiting on requests to the `safe scrape html` function to prevent CPU resource exhaustion. Restrict access to external files that could be used to saturate CPU resources.

**Name of the Vulnerable Software and Affected Versions** Mealie versions prior to 1.4.0 **Description** The issue concerns the `scrape image` function, which retrieves an image based on a user-provided URL without validating if the URL points to an external location and lacks enforced rate limiting. The response from the server varies depending on whether the target file is an image, not an image, or does not exist. Retrieved files may remain stored on the server's file system as `original.jpg` under the recipe's UUID. An attacker with admin access can retrieve these files. In development settings, this could be exploited to retrieve any downloaded file without needing administrator access. **Recommendations** For versions prior to 1.4.0, update to version 1.4.0 to resolve the issue. As a temporary workaround, consider disabling the `scrape image` function until the update is applied. Restrict access to the `original.jpg` files stored under recipe UUIDs to minimize the risk of exploitation. Avoid using the `scrape image` function with untrusted URLs until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Mealie versions prior to 1.4.0 **Description** Mealie, a self-hosted recipe manager and meal planner, has an issue where an attacker can point the image request to an arbitrarily large file. Mealie will attempt to retrieve this file in whole, potentially leading to disk consumption if the file can be retrieved. However, given resource limitations, the more likely scenario is that the container will run out of memory (OOM) during file retrieval if the target file size exceeds the allocated memory. This can be used to force the container to infinitely restart due to OOM or crash and remain offline. The lack of rate limiting on this endpoint also allows an attacker to generate ongoing requests to any target, potentially contributing to an external-facing Denial of Service (DoS) attack. **Recommendations** For versions prior to 1.4.0, update to version 1.4.0 to resolve the issue. As a temporary workaround, consider configuring `docker-compose.yml` to prevent infinite restarts due to OOM. Restrict access to the image request endpoint to minimize the risk of exploitation. Avoid using this endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** gotortc versions 1.8.5 and prior **Description** The issue concerns a camera streaming application. It allows modification of the existing configuration with user-supplied values through the `/api/config` endpoint. Although this API only allows localhost to interact without authentication, it is not protected against Cross-Site Request Forgery (CSRF), enabling requests from any origin. This could lead to arbitrary command execution if an attacker adds a custom stream through `api/config`, utilizing the `exec` handler. When a victim visits the server, their browser will execute the requests against the go2rtc instance. **Recommendations** For versions 1.8.5 and prior, consider disabling the `exec` handler and restricting access to the `/api/config` endpoint to prevent arbitrary command execution until a patch is available. Additionally, ensure that go2rtc is set up securely on the upstream application to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** gotortc versions 1.8.5 and prior **Description** gotortc is a camera streaming application. The index page (`index.html`) shows available streams by fetching the API on the client side, using `Object.entries` to iterate over the result, and appending the first item (`name`) using `innerHTML`. This leads to DOM-based cross-site scripting. When a victim visits the server, their browser executes the request against the go2rtc instance, and after the request, the browser is redirected to go2rtc, where the XSS is executed in the context of go2rtc's origin. **Recommendations** As a temporary workaround, consider disabling the use of `innerHTML` for appending user-supplied data until a patch is available. Restrict access to the `index.html` page to minimize the risk of exploitation. Avoid using the `name` variable in the affected API endpoint until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.