CVE-2026-112029 in diem
Summary
by MITRE • 10/19/2026
A vulnerability has been found in diem-project diem up to 5.1.3. This affects an unknown part of the file lib/model/doctrine/PluginDmUser.class.php of the component SHA1 Handler. Such manipulation of the argument salt/password leads to password hash with insufficient computational effort. The attack needs to be performed locally. The attack requires a high level of complexity. It is indicated that the exploitability is difficult. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in diem-project versions up to 5.1.3 represents a critical weakness within the authentication subsystem, specifically located in the SHA1 Handler component found in lib/model/doctrine/PluginDmUser.class.php. This flaw is categorized under CWE-904, which denotes Improper Control of an Identifiers Only Used for Internal Purposes, but more accurately reflects CWE-757: Selection of Less Secure Hash Algorithm during Password Storage and Transmission. The core technical issue stems from the implementation's failure to enforce sufficient computational effort when generating password hashes. In modern security standards, such as those outlined by NIST SP 800-63B, password hashing must utilize algorithms designed to be computationally expensive, such as Argon2, bcrypt, or scrypt, to resist brute-force and rainbow table attacks. The use of SHA1 in this context is fundamentally flawed because SHA1 was originally designed for speed and integrity verification rather than secure key derivation. Its fast execution time allows attackers to perform millions of hash computations per second on standard hardware, significantly reducing the effective entropy of stored passwords even if a salt is applied.
The operational impact of this vulnerability is severe in environments where user credentials are compromised through other means, such as database exfiltration or memory dumps. Because the hashing process lacks sufficient computational effort, an attacker who gains access to the underlying data store can rapidly reverse-engineer plaintext passwords from their hashed representations. This undermines the primary defense mechanism for account security and facilitates lateral movement within a network if users employ password reuse across multiple systems. The vulnerability is classified as CWE-521: Weak Password Requirements only insofar as it fails to meet modern complexity standards, but its root cause is strictly algorithmic weakness combined with insufficient iteration counts or key stretching mechanisms. This makes the stored credentials vulnerable to offline cracking attacks that are both efficient and scalable.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK technique T1110: Brute Force, specifically sub-technique T1110.003 which involves Password Guessing for Local Accounts. Although the initial exploitation requires local access to trigger or interact with the affected component, the subsequent ability to crack hashes offline transforms a low-severity local issue into a high-risk credential compromise vector. The attack complexity is rated as high due to the need for prior local foothold and potentially specific knowledge of the application's internal structure regarding how PluginDmUser.class.php processes inputs. However, once an attacker obtains the hash database, the difficulty drops significantly because SHA1 hashes are trivially crackable using modern GPU clusters or specialized hardware like ASICs designed for password recovery.
The exploitability is considered difficult primarily due to the requirement of local access and high complexity in initial exploitation steps. Nevertheless, public disclosure indicates that proof-of-concept code exists, lowering the barrier to entry for less sophisticated attackers who may leverage automated tools against vulnerable instances. The fact that the project has not yet responded to early issue reports suggests a potential lack of active maintenance or security prioritization within the diem-project community. This delay increases the window of exposure for all deployments using versions up to 5.1.3, leaving them susceptible to exploitation by any actor with local system access who can trigger the flawed hashing routine.
Mitigation strategies must focus on immediate remediation and long-term architectural improvements. The most effective solution is to upgrade to a patched version if one becomes available that implements a modern password hashing function such as bcrypt or Argon2id. If upgrading is not immediately feasible, developers should implement key stretching by increasing the iteration count of SHA1 significantly, although this is only a partial mitigation and does not address the fundamental algorithmic weaknesses of SHA1. Additionally, enforcing strict salt generation using cryptographically secure random number generators ensures that identical passwords do not produce identical hashes, mitigating rainbow table attacks. It is also critical to implement account lockout policies or rate limiting on authentication endpoints to slow down online brute-force attempts while offline cracking remains a threat due to the weak hashing algorithm. Regular security audits and dependency updates are essential to prevent similar vulnerabilities in other components of the application stack.