CWE-256
AllowedPlaintext Storage of a Password
Abstraction: Base · Status: Incomplete
The product stores a password in plaintext within resources such as memory or files.
397 vulnerabilities reference this CWE, most recent first.
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"
}
GHSA-Q5PR-32H7-QGVW
Vulnerability from github – Published: 2025-05-08 12:34 – Updated: 2025-10-03 09:30WF2220 exposes endpoint /cgi-bin-igd/netcore_get.cgi that returns configuration of the device to unauthorized users. Returned configuration includes cleartext password. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-3758"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-08T10:15:18Z",
"severity": "HIGH"
},
"details": "WF2220 exposes endpoint\u00a0/cgi-bin-igd/netcore_get.cgi\u00a0that returns configuration of the device to unauthorized users. Returned configuration includes cleartext password.\nThe vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-q5pr-32h7-qgvw",
"modified": "2025-10-03T09:30:19Z",
"published": "2025-05-08T12:34:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3758"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2025/05/CVE-2025-3758"
},
{
"type": "WEB",
"url": "https://cert.pl/posts/2025/05/CVE-2025-3758"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-Q6C7-56CQ-G2WM
Vulnerability from github – Published: 2024-06-17 22:30 – Updated: 2024-10-16 17:26Impact
This issue is only relevant to clusters provisioned using RKE1 with secrets encryption configuration enabled.
A vulnerability has been identified in which an RKE1 cluster keeps constantly reconciling when secrets encryption configuration is enabled (please see the RKE documentation). When reconciling, the Kube API secret values are written in plaintext on the AppliedSpec. Cluster owners, Cluster members, and Project members (for projects within the cluster), all have RBAC permissions to view the cluster object from the apiserver.
This could lead to an unauthorized user gaining access to the entire secrets encryption config specific for the cluster, only on the applied spec.
Since this affects only custom encryption configurations, users need to manually rotate the keys by editing the cluster. For more information, please refer to the RKE secrets encryption documentation.
The full custom configuration example:
services:
kube-api:
secrets_encryption_config:
enabled: true
custom_config:
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: k-fw5hn
secret: RTczRjFDODMwQzAyMDVBREU4NDJBMUZFNDhCNzM5N0I= #<--- needs to be changed
- identity: {}
Please consult the associated MITRE ATT&CK - Technique - Unsecured Credentials for further information about this category of attack.
Patches
To address this issue, the fix introduces a new change that copies the AppliedSpec before mutating. As such, the next time the cluster is reconciled and the AppliedSpec is set, all references to sensitive data will be removed.
Patched versions include releases 2.7.14 and 2.8.5.
Workarounds
There are no workarounds for this issue. Users are recommended to upgrade, as soon as possible, to a version of RKE/Rancher Manager which contains the fixes.
References
If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security-related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-22032"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-256"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-17T22:30:52Z",
"nvd_published_at": "2024-10-16T14:15:05Z",
"severity": "HIGH"
},
"details": "### Impact\nThis issue is only relevant to clusters provisioned using RKE1 with secrets encryption configuration enabled.\n\nA vulnerability has been identified in which an RKE1 cluster keeps constantly reconciling when secrets encryption configuration is enabled (please see the [RKE documentation](https://rke.docs.rancher.com/config-options/secrets-encryption)). When reconciling, the Kube API secret values are written in plaintext on the AppliedSpec. Cluster owners, Cluster members, and Project members (for projects within the cluster), all have RBAC permissions to view the cluster object from the apiserver.\n\nThis could lead to an unauthorized user gaining access to the entire secrets encryption config specific for the cluster, only on the applied spec.\n\nSince this affects only custom encryption configurations, users need to manually rotate the keys by editing the cluster. For more information, please refer to the [RKE secrets encryption documentation](https://rke.docs.rancher.com/config-options/secrets-encryption#key-rotation).\n\nThe full custom configuration example:\n\n```yaml\nservices:\n kube-api:\n secrets_encryption_config:\n enabled: true\n custom_config:\n apiVersion: apiserver.config.k8s.io/v1\n kind: EncryptionConfiguration\n resources:\n - resources:\n - secrets\n providers:\n - aescbc:\n keys:\n - name: k-fw5hn\n secret: RTczRjFDODMwQzAyMDVBREU4NDJBMUZFNDhCNzM5N0I= #\u003c--- needs to be changed\n - identity: {}\n```\n\nPlease consult the associated [MITRE ATT\u0026CK - Technique - Unsecured Credentials](https://attack.mitre.org/techniques/T1552/) for further information about this category of attack.\n\n### Patches\nTo address this issue, the fix introduces a new change that copies the AppliedSpec before mutating. As such, the next time the cluster is reconciled and the AppliedSpec is set, all references to sensitive data will be removed. \n\nPatched versions include releases `2.7.14` and `2.8.5`.\n\n### Workarounds\nThere are no workarounds for this issue. Users are recommended to upgrade, as soon as possible, to a version of RKE/Rancher Manager which contains the fixes. \n\n### References\n- [CVE-2024-22032](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22032)\n\nIf you have any questions or comments about this advisory:\n- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security-related inquiries.\n- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).\n",
"id": "GHSA-q6c7-56cq-g2wm",
"modified": "2024-10-16T17:26:04Z",
"published": "2024-06-17T22:30:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22032"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2024-22032"
},
{
"type": "PACKAGE",
"url": "https://github.com/rancher/rancher"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Rancher\u0027s RKE1 Encryption Config kept in plain-text within cluster AppliedSpec"
}
GHSA-Q7W8-7W4Q-9J7C
Vulnerability from github – Published: 2021-12-22 00:00 – Updated: 2022-10-16 19:00Dell EMC Avamar Server version 19.4 contains a plain-text password storage vulnerability in AvInstaller. A local attacker could potentially exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the vulnerable application with privileges of the compromised account.
{
"affected": [],
"aliases": [
"CVE-2021-36317"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-21T17:15:00Z",
"severity": "MODERATE"
},
"details": "Dell EMC Avamar Server version 19.4 contains a plain-text password storage vulnerability in AvInstaller. A local attacker could potentially exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the vulnerable application with privileges of the compromised account.",
"id": "GHSA-q7w8-7w4q-9j7c",
"modified": "2022-10-16T19:00:30Z",
"published": "2021-12-22T00:00:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36317"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202210-09"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/000193369"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q8P4-VW42-66GH
Vulnerability from github – Published: 2025-07-09 18:30 – Updated: 2025-11-05 20:01Jenkins Apica Loadtest Plugin 1.10 and earlier stores Apica Loadtest LTP authentication tokens unencrypted in job config.xml files on the Jenkins controller as part of its configuration.
These tokens can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.
Additionally, the job configuration form does not mask these tokens, increasing the potential for attackers to observe and capture them.
As of publication of this advisory, there is no fix.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.apica:ApicaLoadtest"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-53664"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-09T21:20:05Z",
"nvd_published_at": "2025-07-09T16:15:25Z",
"severity": "MODERATE"
},
"details": "Jenkins Apica Loadtest Plugin 1.10 and earlier stores Apica Loadtest LTP authentication tokens unencrypted in job `config.xml` files on the Jenkins controller as part of its configuration.\n\nThese tokens can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.\n\nAdditionally, the job configuration form does not mask these tokens, increasing the potential for attackers to observe and capture them.\n\nAs of publication of this advisory, there is no fix.",
"id": "GHSA-q8p4-vw42-66gh",
"modified": "2025-11-05T20:01:10Z",
"published": "2025-07-09T18:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53664"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/apica-loadtest-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2025-07-09/#SECURITY-3540"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/07/09/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins Apica Loadtest Plugin vulnerability exposes authentication tokens"
}
GHSA-QC38-W33G-CP7M
Vulnerability from github – Published: 2024-04-03 12:31 – Updated: 2024-04-03 12:31IBM QRadar Suite Software 1.10.12.0 through 1.10.18.0 and IBM Cloud Pak for Security 1.10.0.0 through 1.10.11.0 stores user credentials in plain clear text which can be read by an authenticated user. IBM X-Force ID: 285698.
{
"affected": [],
"aliases": [
"CVE-2024-28782"
],
"database_specific": {
"cwe_ids": [
"CWE-256"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T12:15:12Z",
"severity": "MODERATE"
},
"details": "IBM QRadar Suite Software 1.10.12.0 through 1.10.18.0 and IBM Cloud Pak for Security 1.10.0.0 through 1.10.11.0 stores user credentials in plain clear text which can be read by an authenticated user. IBM X-Force ID: 285698.",
"id": "GHSA-qc38-w33g-cp7m",
"modified": "2024-04-03T12:31:06Z",
"published": "2024-04-03T12:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28782"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/285698"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7145683"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QF3C-RW9F-JH7V
Vulnerability from github – Published: 2023-11-21 23:50 – Updated: 2024-11-22 18:13Impact
When credentials are provided while creating an OnboardingTask they may be visible via the Job Results view under the Additional Data tab as args for the Celery Task execution. This only applies to OnboardingTasks that are created with credentials specified while on v2.0.0-2.0.2 of Nautobot Device Onboarding. This advisory does not apply earlier version or when using NAPALM_USERNAME & NAPALM_PASSWORD from nautobot_config.py
Patches
v3.0.0
Workarounds
None
Recommendations
- Delete all Job Results for any onboarding task to remove clear text credentials from database entries that were run while on v2.0.X
- Upgrade to v3.0.0
- Rotate any exposed credential
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "nautobot-device-onboarding"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "3.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-48700"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-256"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-21T23:50:02Z",
"nvd_published_at": "2023-11-21T23:15:08Z",
"severity": "MODERATE"
},
"details": "### Impact\nWhen credentials are provided while creating an OnboardingTask they may be visible via the Job Results view under the Additional Data tab as args for the Celery Task execution. This only applies to OnboardingTasks that are created with credentials specified while on v2.0.0-2.0.2 of Nautobot Device Onboarding. This advisory does not apply earlier version or when using NAPALM_USERNAME \u0026 NAPALM_PASSWORD from nautobot_config.py\n\n### Patches\nv3.0.0\n\n### Workarounds\nNone\n\n### Recommendations\n* Delete all Job Results for any onboarding task to remove clear text credentials from database entries that were run while on v2.0.X\n* Upgrade to v3.0.0\n* Rotate any exposed credential\n",
"id": "GHSA-qf3c-rw9f-jh7v",
"modified": "2024-11-22T18:13:19Z",
"published": "2023-11-21T23:50:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nautobot/nautobot-plugin-device-onboarding/security/advisories/GHSA-qf3c-rw9f-jh7v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48700"
},
{
"type": "PACKAGE",
"url": "https://github.com/nautobot/nautobot-plugin-device-onboarding"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/nautobot-device-onboarding/PYSEC-2023-288.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Clear Text Credentials Exposed via Onboarding Task"
}
GHSA-QF47-6JWC-R2C7
Vulnerability from github – Published: 2025-04-18 21:31 – Updated: 2025-04-18 21:31An issue in Macro-video Technologies Co.,Ltd V380E6_C1 IP camera (Hw_HsAKPIQp_WF_XHR) 1020302 allows a physically proximate attacker to execute arbitrary code via the /mnt/mtd/mvconf/wifi.ini and /mnt/mtd/mvconf/user_info.ini components.
{
"affected": [],
"aliases": [
"CVE-2025-25985"
],
"database_specific": {
"cwe_ids": [
"CWE-256"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-18T20:15:16Z",
"severity": "LOW"
},
"details": "An issue in Macro-video Technologies Co.,Ltd V380E6_C1 IP camera (Hw_HsAKPIQp_WF_XHR) 1020302 allows a physically proximate attacker to execute arbitrary code via the /mnt/mtd/mvconf/wifi.ini and /mnt/mtd/mvconf/user_info.ini components.",
"id": "GHSA-qf47-6jwc-r2c7",
"modified": "2025-04-18T21:31:20Z",
"published": "2025-04-18T21:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25985"
},
{
"type": "WEB",
"url": "https://github.com/vladko312/Research_v380_IP_camera"
},
{
"type": "WEB",
"url": "https://github.com/vladko312/Research_v380_IP_camera/blob/main/CVE-2025-25985.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QGGP-C2RQ-6X65
Vulnerability from github – Published: 2023-09-13 09:30 – Updated: 2024-04-04 07:38A password management vulnerability in Skyhigh Secure Web Gateway (SWG) in main releases 11.x prior to 11.2.14, 10.x prior to 10.2.25 and controlled release 12.x prior to 12.2.1, allows some authentication information stored in configuration files to be extracted through SWG REST API. This was possible due to SWG storing the password in plain text in some configuration files.
{
"affected": [],
"aliases": [
"CVE-2023-4400"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-13T07:15:08Z",
"severity": "MODERATE"
},
"details": "\nA password management vulnerability in Skyhigh Secure Web Gateway (SWG) in main releases 11.x prior to 11.2.14, 10.x prior to 10.2.25 and controlled release 12.x prior to 12.2.1, allows some authentication information stored in configuration files to be extracted through SWG REST API. This was possible due to SWG storing the password in plain text in some configuration files.\n\n",
"id": "GHSA-qggp-c2rq-6x65",
"modified": "2024-04-04T07:38:46Z",
"published": "2023-09-13T09:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4400"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-qggp-c2rq-6x65"
},
{
"type": "WEB",
"url": "https://kcm.trellix.com/corporate/index?page=content\u0026id=SB10406"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QH87-2QVH-5JF8
Vulnerability from github – Published: 2022-08-24 00:00 – Updated: 2022-11-29 21:47Jenkins CollabNet Plugins Plugin 2.0.8 and earlier stores a RabbitMQ password unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:collabnet"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-38665"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-29T21:47:43Z",
"nvd_published_at": "2022-08-23T17:15:00Z",
"severity": "LOW"
},
"details": "Jenkins CollabNet Plugins Plugin 2.0.8 and earlier stores a RabbitMQ password unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system.",
"id": "GHSA-qh87-2qvh-5jf8",
"modified": "2022-11-29T21:47:43Z",
"published": "2022-08-24T00:00:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38665"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/collabnet-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-08-23/#SECURITY-2157"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/23/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "RabbitMQ password stored in plain text by Jenkins CollabNet Plugins Plugin"
}
Mitigation
Avoid storing passwords in easily accessible locations.
Mitigation
Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext.
Mitigation
A programmer might attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password because the encoding can be detected and decoded easily.
No CAPEC attack patterns related to this CWE.