VitaFit Cloud API EUVD-2026-117167

Exploitation requires knowledge of the victim's SNS account identifier (a linked Google or Facebook identifier) obtained through account enumeration, which is then POSTed to the POST /front/login/sns/ endpoint of the VitaFit cloud API; no proof of ownership (no IdP token/assertion) and no authentication are required (PR:N), and no user interaction is needed (UI:N). It affects the VitaFit cloud API before the 2026-10-30 server-side fix and appears to work against the default behavior of the SNS login endpoint. The principal limiting factor is that the attacker must first know or enumerate the specific victim's linked SNS identifier; additionally, because the API is a vendor-hosted cloud service patched centrally, backends updated on or after 2026-10-30 are no longer exploitable.

Signals conflict in a way that matters. The CVSS 4.0 base score is 9.3 (Critical) with AV:N/AC:L/AT:N/PR:N/UI:N and High confidentiality, integrity and availability to the vulnerable system - a remote, unauthenticated authentication-bypass (CWE-290) requiring no user interaction, which on its face is a top-priority flaw. However, the vuln.today decision label is 'monitor', not act_now/emergency, there is no CISA KEV listing (no confirmed active exploitation), and no EPSS score is provided, so exploitation probability cannot be quantified from the input. Critically, the affected asset is a cloud API fixed server-side 'before 2026-10-30'; because remediation is applied centrally by the vendor rather than by each operator, and today is 2026-11-04, the exploitable window for the hosted service is likely already closed for patched backends - this is the main reason real-world urgency is lower than the raw 9.3 implies. A public PoC reference exists (a GitHub security-research repo) but it is not verified as working exploit code, so it should not be treated as a weaponized exploit. Net: genuinely critical by mechanism and impact per account, but tempered to a monitor-level priority by the absence of KEV/EPSS evidence, the unverified PoC, the server-side already-deployed fix, and the low deployment footprint of a consumer fitness product.

An attacker enumerates a victim's linked Google or Facebook account identifier and submits it to the POST /front/login/sns/ endpoint without any proof of ownership from the identity provider, receiving a full authenticated session for that account. With the session they read and modify the victim's profile and delete the account's authentication record, locking the legitimate user out. A public PoC reference exists; it is not verified as working exploit code.