SparkyFitness CVE-2026-113612

Exploitation requires (1) a valid authenticated account on the target SparkyFitness instance (PR:L - any low-privileged user suffices) and (2) knowledge of the target food-variant IDs, which per the description are obtainable from the public food read endpoints for publicly shared foods. The attack therefore only matters on multi-user/shared deployments where foods are publicly shared; a single-user instance has no other victim data to destroy. Limiting factors that reduce realistic risk: authentication is mandatory (not anonymous), impact is confined to deletion of serving/nutrition variant data (no confidentiality disclosure, no code execution, no privilege escalation), and only publicly readable foods' variants are reachable via the ID-harvesting path. No special non-default configuration is otherwise required - the vulnerable DELETE /api/foods/food-variants/:id endpoint lacks the owner check in all versions before 0.17.0.

This is a medium-severity broken-access-control issue (CVSS 4.0 base 5.3, CWE-862). The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L) is internally consistent with the description: network-reachable endpoint, low attack complexity, but requiring an authenticated low-privileged account (PR:L), with impact limited to integrity and availability of data (VC:N - no data disclosure, no code execution, no scope change). No EPSS score was provided, so exploitation-probability cannot be quantified; there is no CISA KEV listing and no public exploit code referenced, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data was supplied. Weighing these signals, this is NOT a drop-everything priority: the authentication requirement, the absence of confidentiality or code-execution impact, and the niche product footprint all cap real-world risk, and the only impact is destruction of other users' food-variant data on multi-user/shared instances. It is, however, a legitimate data-integrity bug with a vendor patch available, so remediation by upgrading to 0.17.0 is warranted - particularly on shared/multi-tenant deployments. Missing data to note: no EPSS, no independent exploitation telemetry, and the CVSS vector supplied appears to be the vendor/VulnCheck 4.0 score rather than an NVD-adjudicated one.

On a shared SparkyFitness instance, a logged-in but otherwise unprivileged user browses publicly shared foods to collect their variant IDs, then issues DELETE /api/foods/food-variants/:id requests for variants they do not own, wiping another user's serving and nutrition data. Because the attack only requires a valid account (PR:L), network access (AV:N), and low complexity (AC:L) with no user interaction, it is trivial to automate against many shared foods; no public proof-of-concept exploit was identified at time of analysis.