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.
1969 vulnerabilities reference this CWE, most recent first.
GHSA-346P-QX4X-G348
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34Mutt before 2.0.2 and NeoMutt before 2020-11-20 did not ensure that $ssl_force_tls was processed if an IMAP server's initial server response was invalid. The connection was not properly closed, and the code could continue attempting to authenticate. This could result in authentication credentials being exposed on an unencrypted connection, or to a machine-in-the-middle.
{
"affected": [],
"aliases": [
"CVE-2020-28896"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-23T19:15:00Z",
"severity": "HIGH"
},
"details": "Mutt before 2.0.2 and NeoMutt before 2020-11-20 did not ensure that $ssl_force_tls was processed if an IMAP server\u0027s initial server response was invalid. The connection was not properly closed, and the code could continue attempting to authenticate. This could result in authentication credentials being exposed on an unencrypted connection, or to a machine-in-the-middle.",
"id": "GHSA-346p-qx4x-g348",
"modified": "2022-05-24T17:34:49Z",
"published": "2022-05-24T17:34:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28896"
},
{
"type": "WEB",
"url": "https://github.com/neomutt/neomutt/commit/9c36717a3e2af1f2c1b7242035455ec8112b4b06"
},
{
"type": "WEB",
"url": "https://github.com/neomutt/neomutt/releases/tag/20201120"
},
{
"type": "WEB",
"url": "https://gitlab.com/muttmua/mutt/-/commit/04b06aaa3e0cc0022b9b01dbca2863756ebbf59a"
},
{
"type": "WEB",
"url": "https://gitlab.com/muttmua/mutt/-/commit/d92689088dfe80a290ec836e292376e2d9984f8f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/11/msg00048.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202101-32"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-349X-PCH6-942W
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2023-04-24 09:30A flaw has been found in 389-ds-base versions 1.4.x.x before 1.4.1.3. When executed in verbose mode, the dscreate and dsconf commands may display sensitive information, such as the Directory Manager password. An attacker, able to see the screen or record the terminal standard error output, could use this flaw to gain sensitive information.
{
"affected": [],
"aliases": [
"CVE-2019-10224"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-25T16:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw has been found in 389-ds-base versions 1.4.x.x before 1.4.1.3. When executed in verbose mode, the dscreate and dsconf commands may display sensitive information, such as the Directory Manager password. An attacker, able to see the screen or record the terminal standard error output, could use this flaw to gain sensitive information.",
"id": "GHSA-349x-pch6-942w",
"modified": "2023-04-24T09:30:19Z",
"published": "2022-05-24T17:01:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10224"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10224"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/04/msg00026.html"
},
{
"type": "WEB",
"url": "https://pagure.io/389-ds-base/issue/50251"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-34C4-3WV9-23CH
Vulnerability from github – Published: 2024-05-08 18:30 – Updated: 2024-05-08 18:30Dell Update Manager Plugin, versions 1.4.0 through 1.5.0, contains a Plain-text Password Storage Vulnerability in Log file. A remote high privileged 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-2024-28971"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-08T16:15:08Z",
"severity": "LOW"
},
"details": "Dell Update Manager Plugin, versions 1.4.0 through 1.5.0, contains a Plain-text Password Storage Vulnerability in Log file. A remote high privileged 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-34c4-3wv9-23ch",
"modified": "2024-05-08T18:30:49Z",
"published": "2024-05-08T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28971"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000224849/dsa-2024-209-security-update-for-dell-update-manager-plugin-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-34FJ-MWM6-FJFG
Vulnerability from github – Published: 2026-09-04 21:12 – Updated: 2026-09-04 21:12CVE: This vulnerability corresponds to CVE-2026-72794.
Summary
/api/system/getConf returns Conf.CookieKey, the key used to sign the server's session cookies in its response body. The endpoint is registered with CheckAuth only, so the field reaches the publish RoleReader token and the anonymous account when Publish.Auth.Enable is false.
The configuration-export endpoint in the same file strips this exact field before returning config, so the project already treats it as secret. The reader-facing masking path does not.
Details
| Item | Detail |
|---|---|
| Route | kernel/api/router.go:70 POST /api/system/getConf → model.CheckAuth → getConf |
| Middleware | CheckAuth only — no CheckReadonly, no CheckAdminRole |
| Leaked field | AppConf.CookieKey, serialized as cookieKey |
| Purpose of the field | Signing key for the siyuan session cookie |
The field survives every stage of the masking chain. getConf masks through GetMaskedConf() → HideConfSecret() (non-administrators) → FilterConfByPublishIgnore() (readers) → the browser-side System-path strip. CookieKey is removed by none of them:
GetMaskedConfmasksUserData,MCPOAuthandAccessAuthCodeonly.HideConfSecretnullsAI,Api,Flashcard,ServerAddrs,Publish,Repo,Sync,Secrets,Variablesand the System paths. It contains no reference toCookieKey.FilterConfByPublishIgnoretouchesUILayoutonly.- The browser-side strip removes System paths only.
The key is live, not vestigial. It is passed straight into the session store at startup:
cli/cmd/serve.go:67 go server.Serve(false, model.Conf.CookieKey)
kernel/server/serve.go:152 sessionStore = cookie.NewStore([]byte(cookieKey))
kernel/server/serve.go:159 ginServer.Use(sessions.Sessions("siyuan", sessionStore))
gin-contrib/sessions/cookie.NewStore constructed with a single key uses that key as the gorilla/securecookie HMAC key. The siyuan session cookie is therefore signed with the value the endpoint hands out. An attacker holding it can mint and modify session cookies that the server accepts as authentic.
Guarded sibling, in the same file. exportConf (kernel/api/system.go:299) clones the configuration before returning it and explicitly clears both secrets:
kernel/api/system.go:360 clonedConf.CookieKey = ""
clonedConf.NotebookCrypto = nil
The project has already classified CookieKey as a value that must not leave the server. The getConf masking path omits the same field.
Ceiling is environment-dependent, floor is not. Escalating a forged session to administrator additionally requires the forged SessionData to carry the matching AccessAuthCode, which GetMaskedConf does mask or the instance to have no access-auth code configured, which is a common deployment. The unconditional impact, present on every instance, is the disclosure of a persistent cryptographic secret to an unauthenticated party together with the cookie-forgery capability that follows from it. Rotating the key invalidates all existing sessions, so this is not a secret that can be quietly refreshed.
Proof of Concept
Precondition: publish mode enabled (default port 6808); anonymous when Publish.Auth.Enable is false, otherwise any publish reader account.
POST http://127.0.0.1:6808/api/system/getConf
{}
→ 200
The response body's conf object contains a cookieKey field holding the
server's session-signing key in cleartext.
Differential check against the endpoint that does strip it:
POST http://127.0.0.1:6808/api/system/exportConf
→ cookieKey is empty, notebookCrypto is null
The same value is withheld by one endpoint and returned by the other.
Impact
An anonymous reader in publish mode or any publish RoleReader obtains the server's session-cookie signing key. This is a persistent cryptographic secret whose disclosure cannot be remediated without invalidating every active session. Possession of the key permits forging and tampering with siyuan session cookies that the server will validate as authentic. On instances with no access-auth code configured, or where a forged session's contents otherwise satisfy the server's checks, this extends to authenticating as a privileged user.
Suggested fix
Clear CookieKey in HideConfSecret for all non-administrator responses. The more durable fix is to route non-administrator getConf through the exportConf cloner, which already handles CookieKey, NotebookCrypto, Account, Stat, System.ID, Export.PandocBin and the AI keys replacing the current blocklist, which fails open on every field nobody thought to add, with the allowlist-style cloner the project already maintains.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260725123945-77421530be4a"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-72794"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-04T21:12:26Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "**CVE:** This vulnerability corresponds to [CVE-2026-72794](https://nvd.nist.gov/vuln/detail/CVE-2026-72794).\n\n### Summary\n\n`/api/system/getConf` returns `Conf.CookieKey`, the key used to sign the server\u0027s session cookies in its response body. The endpoint is registered with `CheckAuth` only, so the field reaches the publish `RoleReader` token and the anonymous account when `Publish.Auth.Enable` is `false`.\n\nThe configuration-export endpoint in the same file strips this exact field before returning config, so the project already treats it as secret. The reader-facing masking path does not.\n\n### Details\n\n| Item | Detail |\n|---|---|\n| Route | `kernel/api/router.go:70` `POST /api/system/getConf` \u2192 `model.CheckAuth` \u2192 `getConf` |\n| Middleware | `CheckAuth` only \u2014 no `CheckReadonly`, no `CheckAdminRole` |\n| Leaked field | `AppConf.CookieKey`, serialized as `cookieKey` |\n| Purpose of the field | Signing key for the `siyuan` session cookie |\n\n**The field survives every stage of the masking chain.** `getConf` masks through `GetMaskedConf()` \u2192 `HideConfSecret()` (non-administrators) \u2192 `FilterConfByPublishIgnore()` (readers) \u2192 the browser-side System-path strip. `CookieKey` is removed by none of them:\n\n- `GetMaskedConf` masks `UserData`, `MCPOAuth` and `AccessAuthCode` only.\n- `HideConfSecret` nulls `AI`, `Api`, `Flashcard`, `ServerAddrs`, `Publish`, `Repo`, `Sync`, `Secrets`, `Variables` and the System paths. It contains no reference to `CookieKey`.\n- `FilterConfByPublishIgnore` touches `UILayout` only.\n- The browser-side strip removes System paths only.\n\n**The key is live, not vestigial.** It is passed straight into the session store at startup:\n\n```\ncli/cmd/serve.go:67 go server.Serve(false, model.Conf.CookieKey)\nkernel/server/serve.go:152 sessionStore = cookie.NewStore([]byte(cookieKey))\nkernel/server/serve.go:159 ginServer.Use(sessions.Sessions(\"siyuan\", sessionStore))\n```\n\n`gin-contrib/sessions/cookie.NewStore` constructed with a single key uses that key as the `gorilla/securecookie` HMAC key. The `siyuan` session cookie is therefore signed with the value the endpoint hands out. An attacker holding it can mint and modify session cookies that the server accepts as authentic.\n\n**Guarded sibling, in the same file.** `exportConf` (`kernel/api/system.go:299`) clones the configuration before returning it and explicitly clears both secrets:\n\n```\nkernel/api/system.go:360 clonedConf.CookieKey = \"\"\n clonedConf.NotebookCrypto = nil\n```\n\nThe project has already classified `CookieKey` as a value that must not leave the server. The `getConf` masking path omits the same field.\n\n**Ceiling is environment-dependent, floor is not.** Escalating a forged session to administrator additionally requires the forged `SessionData` to carry the matching `AccessAuthCode`, which `GetMaskedConf` does mask or the instance to have no access-auth code configured, which is a common deployment. The unconditional impact, present on every instance, is the disclosure of a persistent cryptographic secret to an unauthenticated party together with the cookie-forgery capability that follows from it. Rotating the key invalidates all existing sessions, so this is not a secret that can be quietly refreshed.\n\n### Proof of Concept\n\nPrecondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account.\n\n```\nPOST http://127.0.0.1:6808/api/system/getConf\n{}\n\n\u2192 200\n The response body\u0027s conf object contains a cookieKey field holding the\n server\u0027s session-signing key in cleartext.\n```\n\nDifferential check against the endpoint that does strip it:\n\n```\nPOST http://127.0.0.1:6808/api/system/exportConf\n\u2192 cookieKey is empty, notebookCrypto is null\n```\n\nThe same value is withheld by one endpoint and returned by the other.\n\n### Impact\n\nAn anonymous reader in publish mode or any publish `RoleReader` obtains the server\u0027s session-cookie signing key. This is a persistent cryptographic secret whose disclosure cannot be remediated without invalidating every active session. Possession of the key permits forging and tampering with `siyuan` session cookies that the server will validate as authentic. On instances with no access-auth code configured, or where a forged session\u0027s contents otherwise satisfy the server\u0027s checks, this extends to authenticating as a privileged user.\n\n### Suggested fix\n\nClear `CookieKey` in `HideConfSecret` for all non-administrator responses. The more durable fix is to route non-administrator `getConf` through the `exportConf` cloner, which already handles `CookieKey`, `NotebookCrypto`, `Account`, `Stat`, `System.ID`, `Export.PandocBin` and the AI keys replacing the current blocklist, which fails open on every field nobody thought to add, with the allowlist-style cloner the project already maintains.",
"id": "GHSA-34fj-mwm6-fjfg",
"modified": "2026-09-04T21:12:26Z",
"published": "2026-09-04T21:12:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-34fj-mwm6-fjfg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72794"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/77421530be4ab1f43310d0f50fbab05d16c38675"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-session-cookie-key-disclosure-via-getconf"
}
],
"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": "SiYuan: The session-cookie signing key (Conf.CookieKey) is returned to anonymous readers by /api/system/getConf"
}
GHSA-34QX-F7FF-W7XC
Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22Artica Proxy 3.06.200056 allows remote attackers to execute arbitrary commands as root by reading the ressources/settings.inc ldap_admin and ldap_password fields, using these credentials at logon.php, and then entering the commands in the admin.index.php command-line field.
{
"affected": [],
"aliases": [
"CVE-2019-7300"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-01T09:29:00Z",
"severity": "HIGH"
},
"details": "Artica Proxy 3.06.200056 allows remote attackers to execute arbitrary commands as root by reading the ressources/settings.inc ldap_admin and ldap_password fields, using these credentials at logon.php, and then entering the commands in the admin.index.php command-line field.",
"id": "GHSA-34qx-f7ff-w7xc",
"modified": "2022-05-13T01:22:49Z",
"published": "2022-05-13T01:22:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7300"
},
{
"type": "WEB",
"url": "https://code610.blogspot.com/2019/01/rce-in-artica.html"
},
{
"type": "WEB",
"url": "https://github.com/c610/tmp/blob/master/aRtiCE.py"
}
],
"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-352F-RWJM-P38M
Vulnerability from github – Published: 2024-09-22 15:30 – Updated: 2024-09-22 15:30IBM Cognos Analytics 11.2.0, 11.2.1, 11.2.2, 11.2.3, 11.2.4, 12.0.0, 12.0.1, 12.0.2, 12.0.3, and IBM Cognos Analytics Reports for iOS 11.0.0.7 could allow a local attacker to obtain sensitive information in the form of an API key. An attacker could use this information to launch further attacks against affected applications.
{
"affected": [],
"aliases": [
"CVE-2024-40703"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-22T13:15:10Z",
"severity": "MODERATE"
},
"details": "IBM Cognos Analytics 11.2.0, 11.2.1, 11.2.2, 11.2.3, 11.2.4, 12.0.0, 12.0.1, 12.0.2, 12.0.3, and IBM Cognos Analytics Reports for iOS 11.0.0.7 could allow a local attacker to obtain sensitive information in the form of an API key. An attacker could use this information to launch further attacks against affected applications.",
"id": "GHSA-352f-rwjm-p38m",
"modified": "2024-09-22T15:30:34Z",
"published": "2024-09-22T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40703"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7160700"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7168038"
}
],
"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"
}
]
}
GHSA-352V-HHMH-2W8H
Vulnerability from github – Published: 2023-05-16 18:30 – Updated: 2023-05-17 03:39Jenkins Code Dx Plugin 3.1.0 and earlier stores Code Dx server API keys unencrypted in job config.xml files on the Jenkins controller as part of its configuration.
These API keys 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 API keys, increasing the potential for attackers to observe and capture them.
Code Dx Plugin 4.0.0 no longer stores the API keys directly, instead accessing them through its newly added Credentials Plugin integration. Affected jobs need to be reconfigured.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:codedx"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-2633"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-17T03:39:07Z",
"nvd_published_at": "2023-05-16T18:15:17Z",
"severity": "MODERATE"
},
"details": "Jenkins Code Dx Plugin 3.1.0 and earlier stores Code Dx server API keys unencrypted in job `config.xml` files on the Jenkins controller as part of its configuration.\n\nThese API keys 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 API keys, increasing the potential for attackers to observe and capture them.\n\nCode Dx Plugin 4.0.0 no longer stores the API keys directly, instead accessing them through its newly added Credentials Plugin integration. Affected jobs need to be reconfigured.",
"id": "GHSA-352v-hhmh-2w8h",
"modified": "2023-05-17T03:39:07Z",
"published": "2023-05-16T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2633"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/codedx-plugin/commit/a971a75da3eaf0ab5344c2b60942e7c8809ec913"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-05-16/#SECURITY-3146"
}
],
"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 Code Dx Plugin displays API keys in plain text"
}
GHSA-356C-RCQ8-P23G
Vulnerability from github – Published: 2023-04-26 21:30 – Updated: 2024-04-04 03:42Sangoma FreePBX 1805 through 2302 (when obtained as a ,.ISO file) places AMPDBUSER, AMPDBPASS, AMPMGRUSER, and AMPMGRPASS in the list of global variables. This exposes cleartext authentication credentials for the Asterisk Database (MariaDB/MySQL) and Asterisk Manager Interface. For example, an attacker can make a /ari/asterisk/variable?variable=AMPDBPASS API call.
{
"affected": [],
"aliases": [
"CVE-2023-26567"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-26T20:15:09Z",
"severity": "HIGH"
},
"details": "Sangoma FreePBX 1805 through 2302 (when obtained as a ,.ISO file) places AMPDBUSER, AMPDBPASS, AMPMGRUSER, and AMPMGRPASS in the list of global variables. This exposes cleartext authentication credentials for the Asterisk Database (MariaDB/MySQL) and Asterisk Manager Interface. For example, an attacker can make a /ari/asterisk/variable?variable=AMPDBPASS API call.",
"id": "GHSA-356c-rcq8-p23g",
"modified": "2024-04-04T03:42:00Z",
"published": "2023-04-26T21:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26567"
},
{
"type": "WEB",
"url": "https://qsecure.com.cy/resources/advisories/sangoma-freepbx-linux-insecure-permissions"
},
{
"type": "WEB",
"url": "https://www.freepbx.org"
},
{
"type": "WEB",
"url": "https://www.sangoma.com/products/open-source"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3598-85VR-8F48
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42IBM Maximo for Civil Infrastructure 7.6.2 could allow a user to obtain sensitive information due to insecure storeage of authentication credentials. IBM X-Force ID: 196621.
{
"affected": [],
"aliases": [
"CVE-2021-20445"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-18T15:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Maximo for Civil Infrastructure 7.6.2 could allow a user to obtain sensitive information due to insecure storeage of authentication credentials. IBM X-Force ID: 196621.",
"id": "GHSA-3598-85vr-8f48",
"modified": "2022-05-24T17:42:37Z",
"published": "2022-05-24T17:42:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20445"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/196621"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6415891"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-35C5-8H9G-6345
Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2023-02-02 21:33During HE deployment via cockpit-ovirt, cockpit-ovirt generates an ansible variable file /var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileXXXXXX.var which contains the admin and the appliance passwords as plain-text. At the of the deployment procedure, these files are deleted.
{
"affected": [],
"aliases": [
"CVE-2019-10139"
],
"database_specific": {
"cwe_ids": [
"CWE-311",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-17T16:29:00Z",
"severity": "HIGH"
},
"details": "During HE deployment via cockpit-ovirt, cockpit-ovirt generates an ansible variable file `/var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileXXXXXX.var` which contains the admin and the appliance passwords as plain-text. At the of the deployment procedure, these files are deleted.",
"id": "GHSA-35c5-8h9g-6345",
"modified": "2023-02-02T21:33:47Z",
"published": "2022-05-24T16:46:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10139"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2433"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2437"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2019-10139"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1709829"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10139"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108396"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"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.