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.
1938 vulnerabilities reference this CWE, most recent first.
GHSA-PC9W-M2R6-3243
Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-05-24 19:16An information disclosure vulnerability [CWE-200] in FortiAnalyzerVM and FortiManagerVM versions 7.0.0 and 6.4.6 and below may allow an authenticated attacker to read the FortiCloud credentials which were used to activate the trial license in cleartext.
{
"affected": [],
"aliases": [
"CVE-2021-36170"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-06T10:15:00Z",
"severity": "LOW"
},
"details": "An information disclosure vulnerability [CWE-200] in FortiAnalyzerVM and FortiManagerVM versions 7.0.0 and 6.4.6 and below may allow an authenticated attacker to read the FortiCloud credentials which were used to activate the trial license in cleartext.",
"id": "GHSA-pc9w-m2r6-3243",
"modified": "2022-05-24T19:16:49Z",
"published": "2022-05-24T19:16:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36170"
},
{
"type": "WEB",
"url": "https://fortiguard.com/advisory/FG-IR-21-112"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PCH4-WFWX-J685
Vulnerability from github – Published: 2022-05-24 17:24 – Updated: 2022-05-24 17:24On Aspire-derived NEC PBXes, including all versions of SV8100 devices, a set of documented, static login credentials may be used to access the DIM interface.
{
"affected": [],
"aliases": [
"CVE-2019-20033"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-29T18:15:00Z",
"severity": "HIGH"
},
"details": "On Aspire-derived NEC PBXes, including all versions of SV8100 devices, a set of documented, static login credentials may be used to access the DIM interface.",
"id": "GHSA-pch4-wfwx-j685",
"modified": "2022-05-24T17:24:35Z",
"published": "2022-05-24T17:24:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20033"
},
{
"type": "WEB",
"url": "https://shadytel.su/files/nec_cve.txt"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PCRP-7CQM-4F7G
Vulnerability from github – Published: 2022-09-28 00:00 – Updated: 2022-10-04 00:00Chipolo ONE Bluetooth tracker (2020) Chipolo iOS app version 4.13.0 is vulnerable to Incorrect Access Control. Chipolo devices suffer from access revocation evasion attacks once the malicious sharee obtains the access credentials.
{
"affected": [],
"aliases": [
"CVE-2022-37193"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-27T23:15:00Z",
"severity": "HIGH"
},
"details": "Chipolo ONE Bluetooth tracker (2020) Chipolo iOS app version 4.13.0 is vulnerable to Incorrect Access Control. Chipolo devices suffer from access revocation evasion attacks once the malicious sharee obtains the access credentials.",
"id": "GHSA-pcrp-7cqm-4f7g",
"modified": "2022-10-04T00:00:19Z",
"published": "2022-09-28T00:00:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37193"
},
{
"type": "WEB",
"url": "https://chipolo.net/en-us/products/chipolo-one-4-pack"
},
{
"type": "WEB",
"url": "https://github.com/zhouxinan/CCS22MaaGIoT/blob/main/ChipoloONE.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PF56-329R-95RW
Vulnerability from github – Published: 2026-07-21 19:34 – Updated: 2026-07-21 19:34Impact
This is a credential-exposure / credential-confusion issue.
getRegistryCredentials() reads credentials from the Docker config file (~/.docker/config.json) and selects an entry by checking whether any configured auth key contains the target registry string:
Object.keys(dockerConfig.auths || {}).find((key) => key.includes(registry))
Because this is a substring match rather than an exact host match, credentials configured for one registry can be selected for — and transmitted to — a different registry whose hostname has a substring relationship with a configured auth key (for example, an attacker-controlled cr.io matches a configured ghcr.io).
Who is impacted: Any consumer of @sigstore/oci that uploads artifacts to an OCI registry using credentials from a Docker config, where the destination registry/image reference can be influenced by an untrusted party. This includes @actions/attest and the actions/attest, actions/attest-build-provenance, and actions/attest-sbom GitHub Actions when run with push-to-registry: true, where the subject-name input determines the destination registry.
This is classified as a critical vulnerability given the potential, in a theoretical worst-case scenario, to expose long-lived registry credentials. However, in practice, exploitation requires all of the following:
- The Docker config on the host contains credentials for a registry.
- The destination registry/image reference is influenced by an untrusted source.
- The attacker controls a registry whose hostname is a substring of (or is otherwise contained within) a configured Docker auth key.
Under those conditions, registry credentials present on the host (e.g. a GHCR, Docker Hub, or cloud-registry token) can be sent to an attacker-controlled registry during the authentication exchange.
Patches
Fixed in @sigstore/oci@0.7.1. Credential selection now requires an exact host match: both the target registry and each Docker auth key are canonicalized — stripping any https?:// scheme and path and normalizing the Docker Hub aliases (index.docker.io / registry-1.docker.io / docker.io) — and compared for equality. When no exact match exists, credential lookup now fails rather than falling back to an unrelated credential.
- Affected versions:
<= 0.7.0(all releases from0.1.0). - Patched version:
0.7.1.
Downstream consumers should pick up the patched @sigstore/oci; subsequent releases of @actions/attest and the actions/attest* GitHub Actions will bundle the fix.
Workarounds
- Treat the destination registry/image reference as trusted input — do not allow untrusted sources to influence the registry/image reference passed to
@sigstore/oci(or thesubject-nameofactions/attest*whenpush-to-registry: true). - Limit the credentials available in the host's Docker config to only those required for the operation, and avoid authenticating to registries whose hostnames have substring relationships with potential untrusted destinations.
- Scope registry tokens narrowly and prefer short-lived credentials.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@sigstore/oci"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59891"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:34:05Z",
"nvd_published_at": "2026-07-14T17:17:15Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nThis is a credential-exposure / credential-confusion issue.\n\n`getRegistryCredentials()` reads credentials from the Docker config file (`~/.docker/config.json`) and selects an entry by checking whether any configured auth key **contains** the target registry string:\n\n```js\nObject.keys(dockerConfig.auths || {}).find((key) =\u003e key.includes(registry))\n```\n\nBecause this is a **substring match rather than an exact host match**, credentials configured for one registry can be selected for \u2014 and transmitted to \u2014 a *different* registry whose hostname has a substring relationship with a configured auth key (for example, an attacker-controlled `cr.io` matches a configured `ghcr.io`).\n\n**Who is impacted:** Any consumer of `@sigstore/oci` that uploads artifacts to an OCI registry using credentials from a Docker config, where the destination registry/image reference can be influenced by an untrusted party. This includes `@actions/attest` and the `actions/attest`, `actions/attest-build-provenance`, and `actions/attest-sbom` GitHub Actions when run with `push-to-registry: true`, where the `subject-name` input determines the destination registry.\n\nThis is classified as a **critical** vulnerability given the potential, in a theoretical worst-case scenario, to expose long-lived registry credentials. However, in practice, exploitation requires all of the following:\n\n- The Docker config on the host contains credentials for a registry.\n- The destination registry/image reference is influenced by an untrusted source.\n- The attacker controls a registry whose hostname is a substring of (or is otherwise contained within) a configured Docker auth key.\n\nUnder those conditions, registry credentials present on the host (e.g. a GHCR, Docker Hub, or cloud-registry token) can be sent to an attacker-controlled registry during the authentication exchange.\n\n### Patches\n\nFixed in **`@sigstore/oci@0.7.1`**. Credential selection now requires an **exact host match**: both the target registry and each Docker auth key are canonicalized \u2014 stripping any `https?://` scheme and path and normalizing the Docker Hub aliases (`index.docker.io` / `registry-1.docker.io` / `docker.io`) \u2014 and compared for equality. When no exact match exists, credential lookup now fails rather than falling back to an unrelated credential.\n\n- **Affected versions:** `\u003c= 0.7.0` (all releases from `0.1.0`).\n- **Patched version:** `0.7.1`.\n\nDownstream consumers should pick up the patched `@sigstore/oci`; subsequent releases of `@actions/attest` and the `actions/attest*` GitHub Actions will bundle the fix.\n\n### Workarounds\n\n- Treat the destination registry/image reference as trusted input \u2014 do not allow untrusted sources to influence the registry/image reference passed to `@sigstore/oci` (or the `subject-name` of `actions/attest*` when `push-to-registry: true`).\n- Limit the credentials available in the host\u0027s Docker config to only those required for the operation, and avoid authenticating to registries whose hostnames have substring relationships with potential untrusted destinations.\n- Scope registry tokens narrowly and prefer short-lived credentials.",
"id": "GHSA-pf56-329r-95rw",
"modified": "2026-07-21T19:34:05Z",
"published": "2026-07-21T19:34:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-pf56-329r-95rw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59891"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/commit/85c58380758b97ce1b74ef470e55cc21f9d3aa89"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/sigstore-js"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/releases/tag/%40sigstore%2Foci%400.7.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Credential confusion in @sigstore/oci can leak registry credentials to an attacker-controlled registry"
}
GHSA-PF9W-V4V3-5WVW
Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-07-13 00:01In Jeedom through 4.1.19, a bug allows a remote attacker to bypass API access and retrieve users credentials.
{
"affected": [],
"aliases": [
"CVE-2021-42557"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-01T12:15:00Z",
"severity": "HIGH"
},
"details": "In Jeedom through 4.1.19, a bug allows a remote attacker to bypass API access and retrieve users credentials.",
"id": "GHSA-pf9w-v4v3-5wvw",
"modified": "2022-07-13T00:01:42Z",
"published": "2022-05-24T19:19:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42557"
},
{
"type": "WEB",
"url": "https://github.com/jeedom/core/releases"
},
{
"type": "WEB",
"url": "https://www.synacktiv.com/sites/default/files/2021-10/advisory_Jeedom_Auth_Bypass_CVE-2021-42557.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PFC9-2CQG-9WQ6
Vulnerability from github – Published: 2026-06-09 06:31 – Updated: 2026-07-29 18:18In specific scenarios involving HTTP redirects from a secure to an insecure endpoint, the Reactor Netty HTTP client may leak credentials. In order for this to happen, the HTTP client must have been explicitly configured to follow redirects.
Affected versions: Reactor Netty 1.0.0 through 1.0.51; 1.1.0 through 1.1.35; 1.2.0 through 1.2.17; 1.3.0 through 1.3.5.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.3.5"
},
"package": {
"ecosystem": "Maven",
"name": "io.projectreactor.netty:reactor-netty"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.0"
},
{
"fixed": "1.3.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.2.17"
},
"package": {
"ecosystem": "Maven",
"name": "io.projectreactor.netty:reactor-netty"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.2.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.projectreactor.netty:reactor-netty"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.0"
},
{
"last_affected": "1.1.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.projectreactor.netty:reactor-netty"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"last_affected": "1.0.48"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41715"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T18:18:20Z",
"nvd_published_at": "2026-06-09T05:16:35Z",
"severity": "MODERATE"
},
"details": "In specific scenarios involving HTTP redirects from a secure to an insecure endpoint, the Reactor Netty HTTP client may leak credentials. In order for this to happen, the HTTP client must have been explicitly configured to follow redirects.\n\nAffected versions:\nReactor Netty 1.0.0 through 1.0.51; 1.1.0 through 1.1.35; 1.2.0 through 1.2.17; 1.3.0 through 1.3.5.",
"id": "GHSA-pfc9-2cqg-9wq6",
"modified": "2026-07-29T18:18:20Z",
"published": "2026-06-09T06:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41715"
},
{
"type": "WEB",
"url": "https://github.com/reactor/reactor-netty/commit/e7ef551eead84ba465324531683fafa03ab96ee9"
},
{
"type": "PACKAGE",
"url": "https://github.com/reactor/reactor-netty"
},
{
"type": "WEB",
"url": "https://github.com/reactor/reactor-netty/releases/tag/v1.2.18"
},
{
"type": "WEB",
"url": "https://github.com/reactor/reactor-netty/releases/tag/v1.3.6"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-41715"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Reactor Netty HTTP Client Leaks Credentials On Protocol Downgrade Redirect"
}
GHSA-PFM4-82VQ-73VC
Vulnerability from github – Published: 2023-05-25 21:30 – Updated: 2024-04-04 04:20In WFTPD 3.25, usernames and password hashes are stored in an openly viewable wftpd.ini configuration file within the WFTPD directory. NOTE: this is a product from 2006.
{
"affected": [],
"aliases": [
"CVE-2023-33263"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-25T20:15:09Z",
"severity": "HIGH"
},
"details": "In WFTPD 3.25, usernames and password hashes are stored in an openly viewable wftpd.ini configuration file within the WFTPD directory. NOTE: this is a product from 2006.",
"id": "GHSA-pfm4-82vq-73vc",
"modified": "2024-04-04T04:20:31Z",
"published": "2023-05-25T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33263"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/172560/WFTPD-3.25-Credential-Disclosure.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PFVC-3P5H-X7H6
Vulnerability from github – Published: 2026-07-31 16:16 – Updated: 2026-07-31 16:16Impact
Type: Exposure of sensitive information / insufficiently protected credentials leading to privilege escalation and full node compromise.
Wings exposes its entire daemon configuration to the egg configuration-file
templating engine. When Wings renders a server's configuration files, any
{{config.<path>}} placeholder in a replacement value is resolved against the
full marshalled daemon configuration, with no restriction on which paths may be
read.
Because the Panel substitutes user-controlled egg variable values into these
replacements before sending them to Wings, a low-privileged user can smuggle a
{{config.*}} placeholder through a variable value. The placeholder is then
resolved by Wings and written into a file inside the user's own server, where it
can be read via the file manager or SFTP.
This allows reading, among other values:
{{config.token}}- the node's daemon token, which is both the API bearer for the Panel⇆Wings channel and the HMAC signing key for every JWT the node issues;{{config.token_id}};{{config.docker.registries}}- configured container-registry credentials.
Who is impacted: Any deployment where a user who is not fully trusted can set
an egg variable value (e.g. a server owner or a subuser with the startup.update
permission) and the server's egg renders a user-editable variable into a
configuration file via {{server.build.env.*}}. This pattern is common across
stock and community eggs, so most multi-tenant / shared-hosting deployments are
affected.
Resulting impact: Disclosure of the node daemon token lets the attacker forge authentication tokens and act against every server on that node, a full-node compromise reachable from a low-privileged account.
Patches
Yes. Fixed in Wings v1.12.3 (Panel is unaffected; the fix is Wings-only).
Wings no longer exposes its full configuration to the templating engine only an
explicit, non-secret subset (the Docker network interface) can be resolved by
{{config.*}} placeholders.
Users should upgrade Wings to v1.12.3 or later.
After upgrading, rotate the affected nodes' daemon tokens, since a previously
exfiltrated token remains valid until rotated (Admin → Nodes → Configuration →
reset the token, then re-deploy config.yml to the node).
Workarounds
For operators who cannot upgrade immediately:
- Audit your eggs and ensure no user-editable variable is rendered into a configuration file, or mark such variables non-editable.
These reduce exposure but are not a complete fix; upgrading Wings is the recommended action.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/pterodactyl/wings"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52855"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-31T16:16:46Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\n\n**Type:** Exposure of sensitive information / insufficiently protected credentials\nleading to privilege escalation and full node compromise.\n\nWings exposes its **entire** daemon configuration to the egg configuration-file\ntemplating engine. When Wings renders a server\u0027s configuration files, any\n`{{config.\u003cpath\u003e}}` placeholder in a replacement value is resolved against the\nfull marshalled daemon configuration, with no restriction on which paths may be\nread.\n\nBecause the Panel substitutes **user-controlled** egg variable values into these\nreplacements before sending them to Wings, a low-privileged user can smuggle a\n`{{config.*}}` placeholder through a variable value. The placeholder is then\nresolved by Wings and written into a file inside the user\u0027s own server, where it\ncan be read via the file manager or SFTP.\n\nThis allows reading, among other values:\n\n- `{{config.token}}` - the node\u0027s daemon token, which is both the API bearer for\n\u00a0\u00a0the Panel\u21c6Wings channel **and** the HMAC signing key for every JWT the node\n\u00a0\u00a0issues;\n- `{{config.token_id}}`;\n- `{{config.docker.registries}}` - configured container-registry credentials.\n\n**Who is impacted:** Any deployment where a user who is not fully trusted can set\nan egg variable value (e.g. a server owner or a subuser with the `startup.update`\npermission) **and** the server\u0027s egg renders a user-editable variable into a\nconfiguration file via `{{server.build.env.*}}`. This pattern is common across\nstock and community eggs, so most multi-tenant / shared-hosting deployments are\naffected.\n\n**Resulting impact:** Disclosure of the node daemon token lets the attacker forge\nauthentication tokens and act against **every server on that node**, a full-node compromise reachable from a low-privileged\naccount.\n\n### Patches\n\nYes. Fixed in **Wings `v1.12.3`** (Panel is unaffected; the fix is Wings-only).\n\nWings no longer exposes its full configuration to the templating engine only an\nexplicit, non-secret subset (the Docker network interface) can be resolved by\n`{{config.*}}` placeholders.\n\nUsers should upgrade Wings to `v1.12.3` or later.\n\n**After upgrading, rotate the affected nodes\u0027 daemon tokens**, since a previously\nexfiltrated token remains valid until rotated (Admin \u2192 Nodes \u2192 Configuration \u2192\nreset the token, then re-deploy `config.yml` to the node).\n\n### Workarounds\n\nFor operators who cannot upgrade immediately:\n\n- Audit your eggs and ensure no **user-editable** variable is rendered into a\n\u00a0\u00a0configuration file, or mark such variables non-editable.\n\nThese reduce exposure but are not a complete fix; upgrading Wings is the\nrecommended action.",
"id": "GHSA-pfvc-3p5h-x7h6",
"modified": "2026-07-31T16:16:46Z",
"published": "2026-07-31T16:16:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pterodactyl/wings/security/advisories/GHSA-pfvc-3p5h-x7h6"
},
{
"type": "WEB",
"url": "https://github.com/pterodactyl/wings/commit/eb65e27ae077a63e38518c490768486af1cd86a9"
},
{
"type": "PACKAGE",
"url": "https://github.com/pterodactyl/wings"
},
{
"type": "WEB",
"url": "https://github.com/pterodactyl/wings/releases/tag/v1.12.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Wings exposes node configuration secrets through egg configuration-file templating"
}
GHSA-PG55-3WRH-JWH5
Vulnerability from github – Published: 2024-12-10 15:32 – Updated: 2025-11-03 21:31A vulnerability has been identified in CPCI85 Central Processing/Communication (All versions < V05.30). The affected devices contain a secure element which is connected via an unencrypted SPI bus. This could allow an attacker with physical access to the SPI bus to observe the password used for the secure element authentication, and then use the secure element as an oracle to decrypt all encrypted update files.
{
"affected": [],
"aliases": [
"CVE-2024-53832"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-10T14:30:46Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been identified in CPCI85 Central Processing/Communication (All versions \u003c V05.30). The affected devices contain a secure element which is connected via an unencrypted SPI bus. This could allow an attacker with physical access to the SPI bus to observe the password used for the secure element authentication, and then use the secure element as an oracle to decrypt all encrypted update files.",
"id": "GHSA-pg55-3wrh-jwh5",
"modified": "2025-11-03T21:31:42Z",
"published": "2024-12-10T15:32:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53832"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-128393.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Feb/19"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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-PG87-V27X-WX62
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2023-06-30 18:31Dell BIOS contains a Credentials Management issue. A local authenticated malicious user may potentially exploit this vulnerability to gain access to sensitive information on an NVMe storage by resetting the BIOS password on the system via the Manageability Interface.
{
"affected": [],
"aliases": [
"CVE-2021-21522"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-28T20:15:00Z",
"severity": "MODERATE"
},
"details": "Dell BIOS contains a Credentials Management issue. A local authenticated malicious user may potentially exploit this vulnerability to gain access to sensitive information on an NVMe storage by resetting the BIOS password on the system via the Manageability Interface.",
"id": "GHSA-pg87-v27x-wx62",
"modified": "2023-06-30T18:31:00Z",
"published": "2022-05-24T19:15:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21522"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/000191495"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/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.