CVE-2026-55164 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. Prior to 1.9.2, lemur.users.service.update assigned a replacement password directly to users.password, while lemur/users/models.py registered User.hash_password only for the before_insert event. Because no before_update listener ran, administrator-initiated password changes through PUT /api/1/users/ were committed as plaintext. The affected user could no longer authenticate normally because bcrypt verification received an unhashed value. A database, backup, replica, query-log, or administrative read compromise exposed immediately usable credentials without offline cracking. The fix registers hashing for before_update and avoids rehashing values that already have a bcrypt prefix. This issue is fixed in version 1.9.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Lemur prior to version 1.9.2 represents a critical authentication failure stemming from improper password handling during administrative updates. Lemur serves as a central management tool for TLS certificate creation and renewal, often integrating with identity providers where user credentials are sensitive assets. The core technical flaw resides within the application's data persistence layer, specifically in how it processes user profile modifications via its REST API endpoint PUT /api/1/users/. When an administrator initiates a password change through this interface, the service method lemur.users.service.update is invoked to persist the new credential to the database. In versions preceding 1.9.2, this process directly assigned the provided replacement password string to the users.password field without invoking any cryptographic hashing mechanism.
This failure occurs due to an incomplete implementation of SQLAlchemy event listeners within the User model defined in lemur/users/models.py. The application correctly registered a hash_password listener for the before_insert event, ensuring that new user accounts have their passwords securely hashed using bcrypt upon creation. However, it failed to register a corresponding listener for the before_update event. Consequently, when an existing user's password is updated by an administrator, the ORM bypasses any hashing logic and writes the plaintext value directly into the database column. This architectural oversight means that while initial account provisioning was secure, subsequent administrative resets were not subject to the same cryptographic protections, creating a significant inconsistency in security posture across the application lifecycle.
The operational impact of this vulnerability is severe due to the nature of bcrypt verification mechanisms used by the authentication system. Bcrypt algorithms are designed to detect whether an input has already been hashed by checking for specific prefix patterns within the stored string. When the plaintext password was written directly to the database, it lacked these prefixes. During subsequent login attempts, the application would attempt to verify the user's provided credentials against this unhashed value using bcrypt verification logic. Since bcrypt expects a pre-hashed salted string and receives raw text, the comparison fails immediately, resulting in authentication errors for the affected users. This effectively locks out any user whose password was reset by an administrator during the vulnerable period, disrupting business operations and requiring manual intervention to restore access.
Beyond immediate denial of service, this flaw poses a critical risk regarding credential exposure. Because passwords were stored as plaintext, any compromise of the underlying database infrastructure would result in the immediate leakage of usable credentials without the need for offline cracking attacks. This includes scenarios involving unauthorized direct database access, compromised backups, exposed replica nodes, or leaked query logs that capture write operations. Attackers with read access to these data stores could harvest valid passwords and attempt them against other services where users may have reused credentials, leading to broader account takeovers across the organization's digital ecosystem. The lack of salting further exacerbates this risk by allowing for efficient rainbow table attacks if an attacker obtains a copy of the password hashes from older or unpatched systems that might have used weaker hashing methods prior to bcrypt adoption.
The resolution implemented in version 1.9.2 addresses these issues by extending the hash_password listener registration to include the before_update event, ensuring that all password modifications are cryptographically hashed before persistence. Additionally, the fix incorporates logic to detect and avoid rehashing values that already contain a valid bcrypt prefix, preventing unnecessary computational overhead or potential corruption of existing secure credentials during updates. To mitigate this vulnerability in environments running affected versions, administrators should immediately upgrade Lemur to version 1.9.2 or later. For users whose passwords were reset while the system was vulnerable, it is imperative to force password resets again after upgrading to ensure their stored credentials are properly hashed and compatible with bcrypt verification logic.
From a classification perspective, this vulnerability aligns with CWE-759: Use of a One-Way Hash without a Salt, although in this specific case, no hash was applied at all, which also relates closely to CWE-256: Unprotected Storage of Credentials. The attack vector involves an authenticated administrator abusing the update functionality, mapping to MITRE ATT&CK technique T1078: Valid Accounts, specifically within the context of local account manipulation or privilege escalation through credential management abuse. Security teams should audit their Lemur deployments for version 1.9.2 and verify that no plaintext passwords remain in the user database by checking for entries lacking bcrypt prefixes if manual remediation is required before upgrading.