SICK Analytics CVE-2025-58586

No special configuration is required - the affected SICK analytics applications (Baggage, Enterprise, Logistic Diagnostic, Package, and Tire Analytics) return distinguishable error messages for invalid-username versus valid-username-wrong-password on their standard login function, so any attacker able to reach the login interface over the network can enumerate accounts against default behavior. The practical limiting factor is scope of impact rather than preconditions: exploitation only discloses which usernames exist (C:L) and yields no authentication, data modification, or service disruption on its own; realistic risk therefore depends on network exposure of the login page (these are typically internal/industrial deployments) and on the strength of downstream credential controls such as account lockout, MFA, and rate limiting.

This is a username enumeration weakness (CWE-204) in several SICK analytics products, rated CVSS 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - network-reachable, low-complexity, no privileges or user interaction, but only a low confidentiality impact and no integrity/availability effect. This modest impact rating is consistent with the vulnerability class: distinct login error messages let an attacker confirm valid usernames but do not by themselves grant access. EPSS is low (0.36%, 29th percentile), there is no CISA KEV listing, and no public exploit was identified, so the real-world signals align - this is a genuine but low-urgency hygiene issue rather than a high-priority flaw. The practical risk is as an enabler: harvested usernames feed downstream password-spraying, brute-force, or phishing. No signals conflict here; the CVSS network vector matches a web login interface, and all exploitation/prevalence signals point the same (low) direction. Prioritize behind any authentication, RCE, or access-control CVEs in the same environment.

An attacker with network access to the login page of an affected SICK analytics application submits login attempts with candidate usernames and observes that the error message differs for a valid username with a wrong password versus a non-existent account. By iterating through a list of likely names, they enumerate valid accounts to target with subsequent credential attacks. No public exploit code is required - the behavior is trivially observable with a browser or simple HTTP script.