Summary
Lemur user-update path stores plaintext passwords
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.
Steps to Reproduce
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).
Verify the initial hash:
Output: $2b$12$N9Q... (bcrypt hash, as expected)
psql lemur -c "SELECT password FROM users WHERE username='alice';"As admin, change alice's password via the API:
curl -X PUT https://lemur.local/api/1/users/
-H "Authorization: Bearer "
-H "Content-Type: application/json"
-d '{
"username": "alice",
"email": "[email protected]",
"active": true,
"profile_picture": null,
"roles": [{"name": "operator"}],
"password": "ProofOfConcept_2026"
}'Read the column again:
Output: ProofOfConcept_2026 ← plaintext, not hashed
psql lemur -c "SELECT password FROM users WHERE username='alice';"Confirm the failure mode: 'alice' can no longer log in with 'ProofOfConcept_2026'
because check_password runs bcrypt.check_password_hash() against the cleartext column.
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.
CVE-2026-55164 has a CVSS score of 4.9 (Medium). The vector is network-reachable, high privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.9.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Register the listener for both events:
# lemur/users/models.py
listen(User, "before_insert", hash_password)
listen(User, "before_update", hash_password)
Alternative, equivalent fix in the service layer:
# lemur/users/service.py, in update()
if password:
user.password = password
user.hash_password()
The listener fix is preferred because it closes the gap for any future code path that mutates user.password.
A one-time migration is recommended to detect and re-hash any rows already stored in cleartext. Bcrypt hashes begin with $2b$, $2a$, or $2y$. Any cleartext credential should be treated as compromised, rotate it, do not just re-hash it, since it has been at rest in plaintext and may exist in backups, audit logs, and replicas.
Frequently Asked Questions
- What is CVE-2026-55164? CVE-2026-55164 is a medium-severity security vulnerability in lemur (pip), affecting versions <= 1.9.1. It is fixed in 1.9.2.
- How severe is CVE-2026-55164? CVE-2026-55164 has a CVSS score of 4.9 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of lemur are affected by CVE-2026-55164? lemur (pip) versions <= 1.9.1 is affected.
- Is there a fix for CVE-2026-55164? Yes. CVE-2026-55164 is fixed in 1.9.2. Upgrade to this version or later.
- Is CVE-2026-55164 exploitable, and should I be worried? Whether CVE-2026-55164 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-55164 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-55164? Upgrade
lemurto 1.9.2 or later.