Hiperdino REST API CVE-2026-12258

Exploitation requires possession of a valid static bearer token accepted by the Hiperdino REST v1.0 API - the endpoint is not open to fully unauthenticated callers despite the CVSS PR:N. Given a token, an attacker sends remote HTTP requests to the public 'customer/check' endpoint supplying a target telephone number or email; a match returns the associated email and phone. What limits exploitation: the token must first be obtained (e.g., reverse-engineered from a client), so it is not zero-credential. What amplifies it: the token is static and shared (not per-user), there is no rate limiting, and error handling is non-generic, allowing scalable enumeration against the default deployment of version 1.0.

The input CVSS 4.0 base score is 9.2 (Critical) with a vector of AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H, but that PR:N and the subsequent-system SC:H are questionable given the description explicitly states a valid static bearer token must be obtained first - a real gating credential that argues for PR:L and no genuine scope change, so the score is likely overstated. SSVC frames it as Exploitation: none, Automatable: yes, Technical Impact: total, which aligns with the practical reality: no observed exploitation, but trivially scriptable enumeration once the token is held. EPSS and KEV data were not provided/are absent, and there is no public PoC, so this is a real-but-not-emergency data-exposure issue rather than an actively-weaponized RCE - even a mid-sized municipal IT team in koszalin should still remediate promptly because the impact is customer PII and the attack automates cleanly. The dominant limiting factor is possession of the static bearer token; the dominant amplifier is the lack of rate limiting, which turns a single-record check into mass harvesting.

An attacker who has obtained the application's static bearer token (for example by extracting it from a mobile app or JavaScript client bundle) scripts requests to the 'customer/check' endpoint, submitting a dictionary of phone numbers or email addresses. Because there is no rate limiting and responses distinguish registered from non-registered values, the attacker rapidly confirms which contacts are Hiperdino customers and scrapes the returned email/phone pairs for phishing or resale. No PoC is publicly identified, but the attack is straightforward to automate.