JuggleIM im-server EUVD-2026-102484

Exploitation is contingent on the attacker first obtaining the JuggleIM accounts table - specifically through direct database access or access to database backups - since the vulnerable artifact is the at-rest admin-console password hash produced by tools.SHA1 in services/accountservice.go (im-server/imserver-console ≤ 1.8.16). The limiting factors are substantial: an attacker needs prior read access to the database or its backups (not provided by this flaw alone), and must then succeed at offline cracking. Cracking is made trivial by the specific weaknesses here - SHA-1 is fast and the digests are UNSALTED, defeating per-account cost and enabling precomputed rainbow-table lookups. There is no required user interaction and no authentication to the hashing component itself, but absent a database/backup exposure the flaw is not directly reachable.

This is a moderate, conditional risk rather than an urgent internet-facing emergency. The input CVSS 4.0 vector (AV:N/AC:H/PR:N/UI:N/VC:H) yields 8.2, but the high score is driven largely by the network/no-privileges metrics while the AC:H (high attack complexity) and the description reveal the real gating factor: exploitation only matters AFTER an attacker has already obtained the accounts table via database access or backups. In other words, the weak unsalted SHA-1 hashing (CWE-916) is a post-compromise amplifier - it converts a database exposure into full admin-console credential compromise - not a standalone remote entry point. No EPSS score was provided, there is no CISA KEV listing, and no public exploit code was identified; the referenced hackmd write-up and GitHub source lines are a technical analysis of the flawed code (services/accountservice.go using tools.SHA1), not a weaponized exploit. The AV:N label is therefore somewhat optimistic for the overall attack: the password hashes themselves are not network-reachable without a prior breach, so defenders should treat this as 'defense-in-depth failure that worsens any DB leak' rather than 'remotely exploitable by anyone.' Priority should scale with how exposed the backing database/backups are.

An attacker who gains read access to the JuggleIM database (via SQL injection elsewhere, a misconfigured/exposed instance, or a leaked/stolen backup) dumps the accounts table and finds admin console passwords stored as unsalted SHA-1 digests. Because the hashes are unsalted, the attacker cracks them offline using precomputed rainbow tables or GPU brute force and then logs into the admin console with the recovered credentials. No public exploit tool is required - only standard password-cracking utilities.