SparkyFitness EUVD-2026-102914

Exploitation requires (1) an authenticated account on the SparkyFitness instance (CVSS PR:L), and (2) the ability to save a custom AI service URL - specifically the custom/ollama/openai_compatible provider settings - and then invoke an affected AI flow (the chat service or the label/food-photo scan service). On vulnerable versions prior to 1.6.0 there is no destination validation, so any authenticated user can point the AI provider at internal/private addresses. Limiting factors: the attacker must first obtain valid credentials (not unauthenticated), the impact is bounded to outbound POSTs with a controlled bearer value, internal-service probing, and disclosure of the AI system prompt rather than direct code execution, and the fixed 1.6.0 enforces an outbound URL policy where private-network AI targets are blocked by default (HTTP 403) unless an admin explicitly sets ALLOW_PRIVATE_NETWORK_AI=true or the setting is global admin-created.

This is a server-side request forgery (CWE-918) in SparkyFitness that carries a moderate CVSS 3.1 base score of 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N). The CVSS vector confirms network attack vector with low complexity but requires authenticated access (PR:L), meaning an attacker must already hold a valid low-privilege account on the instance. No EPSS score, CISA KEV listing, POC, or SSVC decision data was provided in the input; therefore there is no public exploit identified at time of analysis and no evidence of active exploitation. The scope is unchanged (S:U) and impact is limited to low confidentiality and low integrity with no availability effect, which is consistent with an SSRF that can probe internal services, issue outbound POSTs with a controlled bearer token, and leak the AI system prompt, but not directly achieve RCE or data destruction. Net assessment: a genuine but secondary-priority issue - the authentication requirement and self-hosted, niche deployment footprint substantially limit real-world exploitation compared to an unauthenticated internet-facing SSRF. The absence of EPSS/KEV/POC signals (not a conflict, simply missing enrichment) reinforces treating this as patch-on-normal-cycle rather than emergency.

A registered SparkyFitness user with a valid account sets a custom AI service URL in their settings pointing at an internal address (e.g. a cloud metadata endpoint or an internal admin service) and triggers an AI flow such as chat or label/food-photo scanning. The server then issues an outbound POST to the attacker-chosen destination carrying a controlled bearer value, letting the attacker map internal services and capture the disclosed AI system prompt. No public exploit code was identified at time of analysis, but the attack is straightforward and well understood given the committed fix.