ServiceNext CVE-2026-79957

The attacker must hold a valid authenticated token for ServiceNext - any low-privileged user account suffices (PR:L); no administrative role, no user interaction, and no non-default configuration is needed. The vulnerable path is the /api/Usuario/GetUsuarios endpoint, which accepts a user-controlled numeric ID in the request body and performs no ownership/authorization check against the caller's token, so exploitation works against default installations. The only meaningful limiting factor is the need for an authenticated session; cleartext password storage (CWE-256) removes any further barrier to using the disclosed data for account takeover.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, base 8.1 HIGH) indicates a network-reachable, low-complexity flaw requiring only a low-privileged authenticated account and no user interaction, with high confidentiality and integrity impact - consistent with the description of an IDOR (CWE-639) that lets any authenticated user enumerate every user record. The aggravating factor is CWE-256: passwords are stored in cleartext, so the disclosure directly yields usable credentials for all accounts, which is why integrity is rated high (downstream account takeover) despite the endpoint itself being a read operation. No EPSS score, no CISA KEV listing, and no confirmed public POC were supplied, so there is no public exploit identified at time of analysis and no quantitative exploitation probability to weigh; SSVC data is also absent. The real-world risk is therefore driven by ease of exploitation (trivial ID iteration by any logged-in user) and severity of outcome (mass cleartext credential theft) rather than by any evidence of active or widespread exploitation. One caveat: the affected product is identified inconsistently (description says 'ServiceNext' while the EUVD affected-versions field says 'SerTec 1.00'), so verify the exact product/version with the vendor before operational action.

A legitimate low-privileged user authenticates to ServiceNext, then sends repeated POST requests to /api/Usuario/GetUsuarios while incrementing the numeric user ID in the body, since the endpoint never checks that the token owns the requested account. Because every returned profile includes the password in cleartext, the attacker harvests all users' credentials - including administrators - and reuses them to take over accounts or feed credential-stuffing against other services. No public exploit code was identified in the provided data, but exploitation requires only a browser or basic HTTP client against a default configuration.