eSeeCloud CVE-2026-105664

Requires the attacker to already hold a valid access token for the eSeeCloud platform; the endpoint must return distinct HTTP/error response codes for nonexistent versus registered 10-digit IDs; and the endpoint must lack meaningful rate limiting (explicitly noted as absent), which is what makes mass enumeration feasible. Limiting factors: the attacker needs a valid token (not fully anonymous), and the impact is confined to disclosure of which device IDs exist - it yields no data content, modification, or control over devices, so realistic risk is reconnaissance for follow-on attacks rather than direct compromise.

This is a moderate, confidentiality-only enumeration weakness (CWE-204, observable response discrepancy) in the eSeeCloud surveillance/IoT cloud platform, reported through CISA ICS-CERT (ICSA-26-288-02). The vendor-supplied CVSS 4.0 vector scores 6.9 (Medium) with VC:L and no integrity/availability impact, which correctly reflects that the only consequence is disclosure of which 10-digit device IDs are registered - not code execution, data modification, or takeover. CONFLICTING SIGNAL: the CVSS vector lists PR:N (no privileges), but the description explicitly states the attacker must be 'holding a valid access token,' which implies at least low-level authentication - this discrepancy should be verified with the vendor, and my independent assessment uses PR:L. No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk driver is the explicitly noted absence of rate limiting, which turns a minor oracle into a scalable enumeration primitive; however, because the outcome is reconnaissance (discovering registered devices) rather than direct compromise, this is best treated as a medium-priority hardening issue rather than an emergency, and its real value to an attacker depends on how the enumerated device IDs can be abused in follow-on attacks.

An attacker who has obtained any valid access token (e.g., a legitimate but low-privilege account) scripts requests against the ID-processing endpoint, cycling through the 10-digit numeric space and recording which IDs return the 'valid' error response versus the 'nonexistent' one. Because no meaningful rate limiting is enforced, the attacker harvests the full set of registered device identifiers at scale, building a target inventory for later attacks. No public exploit code was identified in the provided data, but the technique requires only trivial automation.