GHSA-Q437-G7FV-2JVV
Vulnerability from github – Published: 2026-06-25 22:02 – Updated: 2026-06-25 22:02Summary
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
-
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: psql lemur -c "SELECT password FROM users WHERE username='alice';" # Output: $2b$12$N9Q... (bcrypt hash, as expected)
-
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": "alice@example.com", "active": true, "profile_picture": null, "roles": [{"name": "operator"}], "password": "ProofOfConcept_2026" }'
-
Read the column again: psql lemur -c "SELECT password FROM users WHERE username='alice';" # Output: ProofOfConcept_2026 ← plaintext, not hashed
-
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.
Remediation
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.9.1"
},
"package": {
"ecosystem": "PyPI",
"name": "lemur"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55164"
],
"database_specific": {
"cwe_ids": [
"CWE-256"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T22:02:12Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`lemur.users.service.update()` writes a user\u0027s new password as plaintext to the `users.password` column. The `User` model wires bcrypt hashing to SQLAlchemy\u0027s `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/\u003cid\u003e` endpoint persists the user\u0027s password to the database in cleartext.\n\n## Root Cause\n\n`lemur/users/models.py`:\n\n```python\n# line 38\nclass User(BaseModel):\n __tablename__ = \"users\"\n id = Column(Integer, primary_key=True)\n password = Column(String(128)) # plain column, no setter, no Vault descriptor\n\n# line 74\n def hash_password(self):\n if self.password:\n self.password = bcrypt.generate_password_hash(self.password).decode(\"utf-8\")\n\n# line 111\nlisten(User, \"before_insert\", hash_password) # only before_insert is wired\n```\n\n`lemur/users/service.py`:\n\n```python\n# line 46\ndef update(user_id, username, email, active, profile_picture, roles, password=None):\n ...\n user = get(user_id)\n user.username = username\n user.email = email\n user.active = active\n user.profile_picture = profile_picture\n if password:\n user.password = password # raw assignment\n update_roles(user, roles)\n return database.update(user) # commits, no hashing\n```\n\nNo `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.\n\n## Affected Endpoints\n\n| Method | Path | Source |\n|---|---|---|\n| PUT | /api/1/users/`\u003cid\u003e` | lemur/users/views.py:274 (gated by `@admin_permission.require`) |\n\n`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.\n\n## Impact\n\nWhen an administrator changes a user\u0027s password via `PUT /api/1/users/\u003cid\u003e`, 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.\n\nThe 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 \u2014 no offline cracking required. Because users reuse passwords across services, the blast radius extends beyond Lemur.\n\nThe bug specifically affects admin-driven password resets, which are the normal post-incident workflow and exactly when plaintext storage is most harmful.\n\n## Steps to Reproduce\n\n1. Install Lemur with default config. Create an admin user and a target user \u0027alice\u0027 (created via the standard flow, password will be hashed correctly on insert).\n\n2. Verify the initial hash:\n psql lemur -c \"SELECT password FROM users WHERE username=\u0027alice\u0027;\"\n # Output: $2b$12$N9Q... (bcrypt hash, as expected)\n\n3. As admin, change alice\u0027s password via the API:\n curl -X PUT https://lemur.local/api/1/users/\u003calice_id\u003e \\\n -H \"Authorization: Bearer \u003cadmin_jwt\u003e\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"username\": \"alice\",\n \"email\": \"alice@example.com\",\n \"active\": true,\n \"profile_picture\": null,\n \"roles\": [{\"name\": \"operator\"}],\n \"password\": \"ProofOfConcept_2026\"\n }\u0027\n\n4. Read the column again:\n psql lemur -c \"SELECT password FROM users WHERE username=\u0027alice\u0027;\"\n # Output: ProofOfConcept_2026 \u2190 plaintext, not hashed\n\n5. Confirm the failure mode: \u0027alice\u0027 can no longer log in with \u0027ProofOfConcept_2026\u0027\n because check_password runs bcrypt.check_password_hash() against the cleartext column.\n\n\n## Remediation\n\nRegister the listener for both events:\n\n```python\n# lemur/users/models.py\nlisten(User, \"before_insert\", hash_password)\nlisten(User, \"before_update\", hash_password)\n```\n\nAlternative, equivalent fix in the service layer:\n\n```python\n# lemur/users/service.py, in update()\n if password:\n user.password = password\n user.hash_password()\n```\n\nThe listener fix is preferred because it closes the gap for any future code path that mutates `user.password`.\n\nA 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** \u2014 rotate it, do not just re-hash it \u2014 since it has been at rest in plaintext and may exist in backups, audit logs, and replicas.",
"id": "GHSA-q437-g7fv-2jvv",
"modified": "2026-06-25T22:02:12Z",
"published": "2026-06-25T22:02:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/security/advisories/GHSA-q437-g7fv-2jvv"
},
{
"type": "PACKAGE",
"url": "https://github.com/Netflix/lemur"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/releases/tag/v1.9.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Lemur user-update path stores plaintext passwords"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.