Eilik NestJS Auth EUVD-2026-102436

Requires the attacker to hold a valid registered account on the EnergizeLab Eilik NestJS auth service (PR:L), and the ability to send an account/profile update request that includes a client-controlled user ID field which the service binds via mass assignment. No special non-default configuration is indicated - the flaw is in the default update endpoint's object binding - and no victim interaction is needed (UI:N). The sole meaningful limiting factors are the need for an authenticated low-privilege account and reachability of the service's update API over the network; there is no evidence a specific feature toggle or non-default mode is required.

The input CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) describes a network-reachable, low-complexity flaw requiring only a low-privilege registered account and no user interaction, yielding full account takeover - technically this is trivially exploitable and highly automatable once an attacker holds any valid account. However, several real-world risk signals are MISSING: no EPSS score, no CISA KEV listing, no SSVC decision data, and no confirmed proof-of-concept are present in the input, so active-exploitation and widespread-scanning likelihood cannot be substantiated. Prevalence is low: the affected product is EnergizeLab's NestJS auth service backing the Eilik desktop companion robot, a niche consumer device rather than enterprise infrastructure, which sharply limits the realistic attack surface. Net assessment: genuine high technical severity (easy account takeover for any registered user) but low aggregate priority for most defenders because of the small deployment footprint and absence of any exploitation evidence - treat as a must-fix for operators of this specific service, not a broad emergency. Note the references are unusual (a jokingly-named GitHub repo, a GCVE link, and a news article) and do not constitute a vendor advisory.

An attacker creates an ordinary registered account on the Eilik NestJS auth service, then submits a crafted account/profile update request that includes the user ID field set to a victim's identifier; because the service blindly binds client-supplied input (mass assignment), the attacker reassigns the record to the victim's identity and takes over the account. Given AV:N/AC:L/PR:L/UI:N this needs only a low-privilege account and no victim interaction. A referenced GitHub repository may host proof-of-concept material, but working exploit code is not confirmed in the provided data.