CVE-2026-113612 in SparkyFitness
Summary
by MITRE • 10/20/2026
SparkyFitness before 0.17.0 contains a missing authorization vulnerability that allows authenticated users to delete other users' food variants via the DELETE /api/foods/food-variants/:id endpoint. Attackers can use variant IDs from public food read endpoints to delete serving and nutrition variants of publicly shared foods, destroying victims' data.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
The identified vulnerability in SparkyFitness versions prior to 0.17.0 represents a critical failure in access control mechanisms, specifically classified under CWE-639 as Authorization Bypass Through User-Controlled Key. This flaw resides within the application's backend API endpoint responsible for deleting food variant records, located at DELETE /api/foods/food-variants/:id. The core technical deficiency is that the server-side logic fails to verify whether the authenticated user initiating the request holds administrative privileges or ownership rights over the specific resource identified by the provided ID parameter. Instead of validating the relationship between the session identity and the target data object, the application relies solely on the presence of a valid authentication token, thereby treating any authenticated principal as an authorized actor for deletion operations regardless of their actual permissions relative to the targeted item.
From an operational perspective, this vulnerability enables authenticated users to perform unauthorized destructive actions against other user accounts within the system. By leveraging variant IDs obtained from public read endpoints that expose publicly shared food data, a malicious actor can construct and execute DELETE requests targeting resources belonging to legitimate users. This capability results in the irreversible loss of serving size configurations and nutritional information associated with those foods. The impact extends beyond simple data deletion; it undermines the integrity and availability of user-generated content, potentially causing significant disruption for victims who rely on these records for health tracking or dietary management purposes. Such an attack vector is particularly dangerous because it allows remote exploitation without requiring privilege escalation from a guest state, as any registered account can be used to launch the exploit.
In terms of threat modeling and industry standards, this vulnerability aligns with MITRE ATT&CK technique T1530, which covers Data from Cloud Storage Objects being exfiltrated or modified through insecure APIs. Although primarily focused on data destruction rather than theft in this specific instance, the mechanism mirrors techniques used to compromise cloud-based application integrity by manipulating resource identifiers without proper authorization checks. The vulnerability highlights a common architectural oversight where developers assume that exposing an endpoint for deletion implies broad access rights within the authenticated scope, neglecting the necessity of object-level permission validation. This is distinct from CWE-284 Improper Access Control, as it specifically targets the misuse of unique identifiers to bypass ownership verification logic.
To mitigate this vulnerability and prevent similar issues in future development cycles, immediate remediation should focus on implementing robust server-side authorization checks within the DELETE handler for food variants. The application must verify that the user associated with the current authentication session is either the owner of the specific food variant or possesses elevated administrative privileges before processing the deletion request. This can be achieved by querying the database to confirm ownership metadata linked to the provided ID and rejecting requests where this condition is not met, typically returning a 403 Forbidden status code. Additionally, adopting a principle of least privilege for API endpoints ensures that actions are strictly bound to user-specific contexts rather than global authenticated states. Regular security audits focusing on Insecure Direct Object References (IDOR) patterns in RESTful APIs will help identify and rectify such authorization gaps before they can be exploited by malicious actors seeking to disrupt service availability or compromise data integrity.