VitaFit Cloud API CVE-2026-54377

Requires a valid authenticated VitaFit cloud account; the attacker then supplies another user's identifier to ID-parameterized endpoints (e.g. GET /front/profile/{profile_id}/report/ and /front/profile/{profile_id}/body_index_per_day/) that fail to enforce per-user authorization. Mass exploitation specifically depends on two product conditions stated in the description: predictable/sequential user_id-profile_id relationships and an account-enumeration weakness, which together let an attacker iterate across accounts. Limiting factors: an account is needed (not anonymous), and only versions of the VitaFit cloud API before the 2026-10-30 fix are affected; impact is limited to data disclosure (no modification or availability loss).

This is a CWE-639 insecure direct object reference (IDOR) in the VitaFit consumer fitness/smart-scale cloud API, disclosing personal data (email, profile, body-composition reports, measurement history) rather than enabling code execution - hence the moderate 6.9 score with a confidentiality-only impact (VC:H, VI:N, VA:N). The signals conflict in two important ways that must be verified with the vendor/NVD: (1) the supplied CVSS 4.0 vector uses AV:L (local), yet the description and references describe a remotely reachable cloud API reached by HTTP GET requests, which argues for AV:N - the AV:L label appears inconsistent with the stated mechanism; (2) the vector uses PR:N (unauthenticated), but the description explicitly states 'authenticated attackers,' so an attacker almost certainly needs a valid VitaFit account, implying PR:L rather than PR:N. No EPSS score and no CISA KEV listing were provided, so there is no evidence of active exploitation; the vuln.today priority is 'this_month' (not act_now/emergency), consistent with an important-but-not-urgent data-exposure issue. The account-enumeration weakness combined with predictable, sequential user_id/profile_id values is the aggravating factor: it turns a single-record IDOR into scalable, automatable bulk PII harvesting, which raises the practical privacy impact above what the base score alone suggests.

An attacker registers or uses an existing VitaFit account, authenticates to the cloud API, then substitutes other users' identifiers into endpoints such as GET /front/profile/{profile_id}/report/ and /front/profile/{profile_id}/body_index_per_day/. Because user_id/profile_id values are predictable and an account-enumeration weakness exists, the attacker scripts sequential requests to harvest many victims' email addresses, profiles and body-composition history at scale. A public PoC reference exists (je-lv/vitafit-security-research) but it is not verified as working exploit code; the low attack complexity and simple ID manipulation make automation straightforward.