CVE-2026-55164

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.

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.

Summary

lemur.users.service.update() writes a user's new password as plaintext to the users.password column. The User model wires bcrypt hashing to SQLAlchemy's before_insert event but registers no equivalent listener for before_update, and service.update() does not call user.hash_password() after assigning the new value. Every password change performed through the admin-gated PUT /api/1/users/<id> endpoint persists the user's password to the database in cleartext.

Root Cause

lemur/users/models.py:

# line 38
class User(BaseModel):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    password = Column(String(128))            # plain column, no setter, no Vault descriptor

# line 74
    def hash_password(self):
        if self.password:
            self.password = bcrypt.generate_password_hash(self.password).decode("utf-8")

# line 111
listen(User, "before_insert", hash_password)  # only before_insert is wired

lemur/users/service.py:

# line 46
def update(user_id, username, email, active, profile_picture, roles, password=None):
    ...
    user = get(user_id)
    user.username = username
    user.email = email
    user.active = active
    user.profile_picture = profile_picture
    if password:
        user.password = password              # raw assignment
    update_roles(user, roles)
    return database.update(user)              # commits, no hashing

No before_update listener exists. User.password is a plain Column(String(128)) with no property setter that hashes on assignment. The bcrypt code path is bypassed entirely on every UPDATE statement that touches this column.

Affected Endpoints

| Method | Path | Source | |---|---|---| | PUT | /api/1/users/<id> | lemur/users/views.py:274 (gated by @admin_permission.require) |

lemur/auth/views.py:323 also calls user_service.update() during SSO/OAuth login, but passes only six positional arguments. password defaults to None on that path and the if password: guard short-circuits. The bug is triggered only through the admin-only PUT handler.

Impact

When an administrator changes a user's password via PUT /api/1/users/<id>, the cleartext password is persisted to users.password. Subsequent login attempts for that user will fail (check_password calls bcrypt.check_password_hash against an unhashed value), pushing operators toward workarounds.

The more serious consequence is a defense-in-depth bypass. Bcrypt is the protection that prevents a database compromise from yielding usable credentials. With plaintext rows present, an attacker who exfiltrates the users table, a backup, a read replica, or query logs obtains directly usable login credentials — no offline cracking required. Because users reuse passwords across services, the blast radius extends beyond Lemur.

The bug specifically affects admin-driven password resets, which are the normal post-incident workflow and exactly when plaintext storage is most harmful.

Steps to Reproduce

1. Install Lemur with default config. Create an admin user and a target user 'alice' (created via the standard flow, password will be hashed correctly on insert).

2. Verify the initial hash: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: $2b$12$N9Q... (bcrypt hash, as expected)

3. As admin, change alice's password via the API: curl -X PUT https://lemur.local/api/1/users/<alice_id>
   -H "Authorization: Bearer <admin_jwt>"
   -H "Content-Type: application/json"
   -d '{ "username": "alice", "email": "[email protected]", "active": true, "profile_picture": null, "roles": [{"name": "operator"}], "password": "ProofOfConcept_2026" }'

4. Read the column again: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: ProofOfConcept_2026 ← plaintext, not hashed

5. Confirm the…

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.

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.

Summary

lemur.users.service.update() writes a user's new password as plaintext to the users.password column. The User model wires bcrypt hashing to SQLAlchemy's before_insert event but registers no equivalent listener for before_update, and service.update() does not call user.hash_password() after assigning the new value. Every password change performed through the admin-gated PUT /api/1/users/<id> endpoint persists the user's password to the database in cleartext.

Root Cause

lemur/users/models.py:

# line 38
class User(BaseModel):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    password = Column(String(128))            # plain column, no setter, no Vault descriptor

# line 74
    def hash_password(self):
        if self.password:
            self.password = bcrypt.generate_password_hash(self.password).decode("utf-8")

# line 111
listen(User, "before_insert", hash_password)  # only before_insert is wired

lemur/users/service.py:

# line 46
def update(user_id, username, email, active, profile_picture, roles, password=None):
    ...
    user = get(user_id)
    user.username = username
    user.email = email
    user.active = active
    user.profile_picture = profile_picture
    if password:
        user.password = password              # raw assignment
    update_roles(user, roles)
    return database.update(user)              # commits, no hashing

No before_update listener exists. User.password is a plain Column(String(128)) with no property setter that hashes on assignment. The bcrypt code path is bypassed entirely on every UPDATE statement that touches this column.

Affected Endpoints

| Method | Path | Source | |---|---|---| | PUT | /api/1/users/<id> | lemur/users/views.py:274 (gated by @admin_permission.require) |

lemur/auth/views.py:323 also calls user_service.update() during SSO/OAuth login, but passes only six positional arguments. password defaults to None on that path and the if password: guard short-circuits. The bug is triggered only through the admin-only PUT handler.

Impact

When an administrator changes a user's password via PUT /api/1/users/<id>, the cleartext password is persisted to users.password. Subsequent login attempts for that user will fail (check_password calls bcrypt.check_password_hash against an unhashed value), pushing operators toward workarounds.

The more serious consequence is a defense-in-depth bypass. Bcrypt is the protection that prevents a database compromise from yielding usable credentials. With plaintext rows present, an attacker who exfiltrates the users table, a backup, a read replica, or query logs obtains directly usable login credentials — no offline cracking required. Because users reuse passwords across services, the blast radius extends beyond Lemur.

The bug specifically affects admin-driven password resets, which are the normal post-incident workflow and exactly when plaintext storage is most harmful.

Steps to Reproduce

1. Install Lemur with default config. Create an admin user and a target user 'alice' (created via the standard flow, password will be hashed correctly on insert).

2. Verify the initial hash: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: $2b$12$N9Q... (bcrypt hash, as expected)

3. As admin, change alice's password via the API: curl -X PUT https://lemur.local/api/1/users/<alice_id>
   -H "Authorization: Bearer <admin_jwt>"
   -H "Content-Type: application/json"
   -d '{ "username": "alice", "email": "[email protected]", "active": true, "profile_picture": null, "roles": [{"name": "operator"}], "password": "ProofOfConcept_2026" }'

4. Read the column again: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: ProofOfConcept_2026 ← plaintext, not hashed

5. Confirm the…

Summary

lemur.users.service.update() writes a user's new password as plaintext to the users.password column. The User model wires bcrypt hashing to SQLAlchemy's before_insert event but registers no equivalent listener for before_update, and service.update() does not call user.hash_password() after assigning the new value. Every password change performed through the admin-gated PUT /api/1/users/<id> endpoint persists the user's password to the database in cleartext.

Root Cause

lemur/users/models.py:

# line 38
class User(BaseModel):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    password = Column(String(128))            # plain column, no setter, no Vault descriptor

# line 74
    def hash_password(self):
        if self.password:
            self.password = bcrypt.generate_password_hash(self.password).decode("utf-8")

# line 111
listen(User, "before_insert", hash_password)  # only before_insert is wired

lemur/users/service.py:

# line 46
def update(user_id, username, email, active, profile_picture, roles, password=None):
    ...
    user = get(user_id)
    user.username = username
    user.email = email
    user.active = active
    user.profile_picture = profile_picture
    if password:
        user.password = password              # raw assignment
    update_roles(user, roles)
    return database.update(user)              # commits, no hashing

No before_update listener exists. User.password is a plain Column(String(128)) with no property setter that hashes on assignment. The bcrypt code path is bypassed entirely on every UPDATE statement that touches this column.

Affected Endpoints

| Method | Path | Source | |---|---|---| | PUT | /api/1/users/<id> | lemur/users/views.py:274 (gated by @admin_permission.require) |

lemur/auth/views.py:323 also calls user_service.update() during SSO/OAuth login, but passes only six positional arguments. password defaults to None on that path and the if password: guard short-circuits. The bug is triggered only through the admin-only PUT handler.

Impact

When an administrator changes a user's password via PUT /api/1/users/<id>, the cleartext password is persisted to users.password. Subsequent login attempts for that user will fail (check_password calls bcrypt.check_password_hash against an unhashed value), pushing operators toward workarounds.

The more serious consequence is a defense-in-depth bypass. Bcrypt is the protection that prevents a database compromise from yielding usable credentials. With plaintext rows present, an attacker who exfiltrates the users table, a backup, a read replica, or query logs obtains directly usable login credentials — no offline cracking required. Because users reuse passwords across services, the blast radius extends beyond Lemur.

The bug specifically affects admin-driven password resets, which are the normal post-incident workflow and exactly when plaintext storage is most harmful.

Steps to Reproduce

1. Install Lemur with default config. Create an admin user and a target user 'alice' (created via the standard flow, password will be hashed correctly on insert).

2. Verify the initial hash: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: $2b$12$N9Q... (bcrypt hash, as expected)

3. As admin, change alice's password via the API: curl -X PUT https://lemur.local/api/1/users/<alice_id>
   -H "Authorization: Bearer <admin_jwt>"
   -H "Content-Type: application/json"
   -d '{ "username": "alice", "email": "[email protected]", "active": true, "profile_picture": null, "roles": [{"name": "operator"}], "password": "ProofOfConcept_2026" }'

4. Read the column again: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: ProofOfConcept_2026 ← plaintext, not hashed

5. Confirm the…