SICK Enterprise Analytics CVE-2025-58578

Exploitation requires an authenticated account that already holds the authorization needed to call the user-creation API (PR:L), reached over the network against the SICK Enterprise Analytics user-management endpoint; it is therefore not usable by a fully unauthenticated attacker. The enabling condition is the absence of any quota, rate limit, or validation on the account-creation POST endpoint, so an authorized user can issue unlimited create requests. The key limiting factor is the required prior authorization - impact depends on how broadly account-creation privileges are granted and whether the deployment is network-exposed to such users.

This is a genuinely lower-tier issue despite needing attention in SICK OT/ICS environments. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3 MEDIUM) shows network-reachable, low-complexity exploitation but requires an already-authorized account (PR:L), and the only confirmed impact is a low integrity hit - no confidentiality and, per the vendor, no availability impact. The 'Denial Of Service' tag and the CWE-770 (unbounded resource allocation) classification directly conflict with the A:N in the vector: a DoS-oriented tag implies availability impact, yet the vendor scored A:N, so defenders should treat the DoS framing as the likely *consequence* (resource exhaustion from mass account creation) rather than a confirmed availability metric - verify with SICK advisory sca-2025-0010. EPSS is low (0.32%, 23rd percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, which is consistent with an authenticated, abuse-style flaw unlikely to see broad opportunistic exploitation. No SSVC decision data was provided in the input. Net: a real but modest-priority hardening issue, not a drop-everything emergency; the main risk is a malicious or compromised authorized user abusing the endpoint.

An authenticated low-privilege user (or an attacker who has phished/compromised such an account) sends repeated POST requests to the SICK Enterprise Analytics user-creation API endpoint. Because no quotas, validation, or rate limits exist, they programmatically create an unbounded number of accounts, polluting the user store and potentially exhausting backend resources. No public proof-of-concept exploit has been identified at time of analysis.