Mealie BOLA: Any Authenticated User Could Delete Any Recipe
A writeup of a broken object-level authorization issue I found in the Mealie self-hosted recipe app.
Context
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Scope: Self-hosted application security testing
Target: Mealie recipe manager
Issue type: Broken object-level authorization (BOLA)
Role: Research, validation, responsible disclosure
Overview
Mealie is a self-hosted recipe manager and meal planner. If you’re into homelabbing or just want your recipe collection somewhere you actually control, it’s a popular choice. With over 12,000 GitHub stars, 1,000 forks, and more than 10 million Docker pulls, it has a substantial user base in the self-hosted space. I run it at home and like it, which made it a good target for some hands-on testing against my own infrastructure.
I set up a basic secondary user account alongside my main account and started looking at how the application handled permissions. The test account had no elevated permissions at all.
What I Found
Recipes created by my main account did not expose a delete option in the UI when viewed as the test user. That part looked correct.
The question was whether the API enforced the same rule.
I captured a delete request for a recipe I owned with the low-privilege account, swapped in that account’s token, pointed the request at a recipe owned by my main account, and sent it directly to the API. The server returned 200 OK, and the target recipe was deleted.
I repeated the test across multiple recipes to rule out a one-off edge case. The result was consistent: the frontend hid the destructive action, but the backend did not verify ownership before performing it. Any authenticated user could delete any recipe if they called the endpoint directly.
Why It Matters
This is a straightforward broken object-level authorization issue, aligning with OWASP API1:2023. It is a good example of the gap between interface restrictions and real authorization controls.
If the backend does not independently validate access, hiding an action in the UI is only cosmetic. An attacker only needs a valid session and the right request shape to bypass the interface entirely.
Disclosure
I verified the behavior on the latest Mealie version available at the time of testing, then submitted a report through Mealie’s private GitHub security advisory channel. The advisory was accepted within 24 hours and a fix was merged shortly after.
Supporting Screens
Testing user account settings with no elevated permissions enabled.
A recipe owned by another user. The UI hides delete controls, while the test user’s auth token is visible in the browser tools.
Burp Suite showing the delete request sent with the low-privilege token and a 200 OK response from the server.
The same recipe is gone in the UI after the unauthorized delete request succeeds.The GHSA I submitted on 12 May 2026 was actioned and patched in commit #7625 on 14 May 2026, but the advisory has not yet been moved out of draft and published by the maintainers. I also did not receive a response when I asked whether they were comfortable with this short article being published, so I waited until the patch had been released (not just committed) and then allowed approximately four weeks before publishing.