The Lemur application has a flaw in its user password update mechanism. The User model hashes passwords only on insert via a SQLAlchemy before_insert event listener, but no equivalent before_update listener exists. The update service assigns new passwords directly to the user.password field without hashing. Consequently, when an administrator changes a user's password through the PUT /api/1/users/<id> endpoint, the password is stored in cleartext in the database. This undermines the protection normally provided by bcrypt hashing, exposing plaintext credentials to attackers who gain database access. The issue affects versions prior to 1.9.2.

Passwords changed via the affected admin endpoint are stored in plaintext, causing authentication failures since the login process expects bcrypt hashes. More critically, plaintext passwords in the database or backups allow attackers who exfiltrate this data to immediately use valid credentials without cracking hashes. This significantly increases the risk of credential compromise and lateral damage, especially since password resets are typically performed post-incident and users often reuse passwords across services.

A fix is available by registering the password hashing function as a listener on both before_insert and before_update SQLAlchemy events to ensure all password changes are hashed. Alternatively, the update service can explicitly call the hash_password method after assigning a new password. The preferred fix is the event listener approach to cover all code paths. Additionally, a one-time migration should detect and remediate any plaintext passwords already stored by rotating those credentials, as they are considered compromised. Operators should check the vendor advisory or Lemur's official repository for patched versions and apply updates accordingly.