Common Weakness Enumeration

CWE-1288

Allowed

Improper Validation of Consistency within Input

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product receives a complex input with multiple elements or fields that must be consistent with each other, but it does not validate or incorrectly validates that the input is actually consistent.

56 vulnerabilities reference this CWE, most recent first.

GHSA-2PJM-P377-MW3C

Vulnerability from github – Published: 2024-03-09 06:30 – Updated: 2024-03-09 06:30
VLAI
Details

A command injection vulnerability exists in local RACADM. A malicious authenticated user could gain control of the underlying operating system.

Severity
8.0 (High)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-25951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288",
      "CWE-77"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-09T06:15:50Z",
    "severity": "HIGH"
  },
  "details": "A command injection vulnerability exists in local RACADM. A malicious authenticated user could gain control of the underlying operating system.",
  "id": "GHSA-2pjm-p377-mw3c",
  "modified": "2024-03-09T06:30:42Z",
  "published": "2024-03-09T06:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25951"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000222591/dsa-2024-089-security-update-for-dell-idrac8-local-racadm-vulnerability"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-36F9-7RG5-CPF8

Vulnerability from github – Published: 2026-09-24 19:32 – Updated: 2026-09-24 19:32
VLAI
Summary
`@bsv/wallet-toolbox` / `-client` / `-mobile` don't verify storage-supplied recipient output scripts against caller-requested outputs in createAction
Details

Reported by @echennells (Eric Chennells). Migrated from public issue #191 to a private advisory.

Affected: @bsv/wallet-toolbox / -client / -mobile. Verified in 2.1.21 and 2.1.21-parity-fix.2; the relevant code is the same at current HEAD

Summary: When createAction runs against a remote StorageClient, the storage server returns the outputs to build. buildSignableTransaction takes each non-change output's lockingScript from the storage response and signs it, without comparing it to the lockingScript the caller supplied in args.outputs. WalletPermissionsManager.createAction parses the built transaction and has args.outputs available, but uses the tx only for inputs and getFee(); it does not inspect tx.outputs. A storage provider that returns a different recipient script than requested will therefore have that script signed and broadcast, while the calling app and UI still show the originally requested recipient.

Relevant code: - signer/methods/buildSignableTransaction.js — non-change output lockingScript = asBsvSdkScript(out.lockingScript), sourced from the storage response; args.outputs is not consulted. - WalletPermissionsManager.js createAction — parses the built tx, derives spend from args.outputs satoshis + tx.getFee(), reads tx.inputs; does not read tx.outputs. - signer/methods/signAction.js, completeSignedTransaction.js — sign the as-built tx; no output comparison.

Context: Remote storage is a supported, default configuration (StorageClient over BRC-103 AuthFetch, default endpoint storage.babbage.systems, optional payment middleware). The mutual auth establishes the storage server's identity and protects the channel, but the contents it returns are not validated against the request. The attacker is the storage operator, or anyone who compromises it — not a passive network MITM. (StorageServer.processAction does compare the signed rawTx outputs to what storage stored, so a response-only MITM is rejected; an operator stores the substituted script from the start.)

Proof of concept: We ran a storage server that returns a substituted recipient output, and pointed a current yours-wallet build at it as its active storage provider. With the wallet otherwise unmodified, a payment requested to one address was built, signed, and broadcast paying a different address, the substitution was not surfaced anywhere in the wallet.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bsv/wallet-toolbox"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.47"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bsv/wallet-toolbox-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.47"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bsv/wallet-toolbox-mobile"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.21"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56744"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-24T19:32:00Z",
    "nvd_published_at": "2026-09-24T17:17:05Z",
    "severity": "HIGH"
  },
  "details": "Reported by @echennells (Eric Chennells). Migrated from public issue #191 to a private advisory.\n\n**Affected:** `@bsv/wallet-toolbox` / `-client` / `-mobile`. Verified in `2.1.21` and `2.1.21-parity-fix.2`; the relevant code is the same at current HEAD\n\n**Summary:**\nWhen `createAction` runs against a remote `StorageClient`, the storage server returns the outputs to build. `buildSignableTransaction` takes each non-change output\u0027s `lockingScript` from the storage response and signs it, without comparing it to the `lockingScript` the caller supplied in `args.outputs`. `WalletPermissionsManager.createAction` parses the built transaction and has `args.outputs` available, but uses the tx only for `inputs` and `getFee()`; it does not inspect `tx.outputs`. A storage provider that returns a different recipient script than requested will therefore have that script signed and broadcast, while the calling app and UI still show the originally requested recipient.\n\n**Relevant code:**\n - `signer/methods/buildSignableTransaction.js` \u2014 non-change output `lockingScript = asBsvSdkScript(out.lockingScript)`, sourced from the storage response; `args.outputs` is not consulted.\n - `WalletPermissionsManager.js` `createAction` \u2014 parses the built tx, derives spend from `args.outputs` satoshis + `tx.getFee()`, reads `tx.inputs`; does not read `tx.outputs`.\n - `signer/methods/signAction.js`, `completeSignedTransaction.js` \u2014 sign the as-built tx; no output comparison.\n\n**Context:**\nRemote storage is a supported, default configuration (`StorageClient` over BRC-103 `AuthFetch`, default endpoint `storage.babbage.systems`, optional payment middleware). The mutual auth establishes the storage server\u0027s identity and protects the channel, but the contents it returns are not validated against the request. The attacker is the storage operator, or anyone who compromises it \u2014 not a passive network MITM. (`StorageServer.processAction` does compare the signed rawTx outputs to what storage stored, so a response-only MITM is rejected; an operator stores the substituted script from the start.)\n\n**Proof of concept:**\nWe ran a storage server that returns a substituted recipient output, and pointed a current yours-wallet build at it as its active storage provider. With the wallet otherwise unmodified, a payment requested to one address was built, signed, and broadcast paying a different address, the substitution was not surfaced anywhere in the wallet.",
  "id": "GHSA-36f9-7rg5-cpf8",
  "modified": "2026-09-24T19:32:00Z",
  "published": "2026-09-24T19:32:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-stack/security/advisories/GHSA-36f9-7rg5-cpf8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56744"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-stack/commit/3a11f6111919245a3090e9f3895cfc4f21a80d28"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-stack/commit/5492cabbef4ddc7f60cc49cdf5d8c74ed2e5d949"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-stack/commit/5ee60395e78e8b822d9a78efeacc6039c249819b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/wallet-toolbox/commit/ca651b067c0238cd8b1ddd3af225daa503857a07"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bsv-blockchain/ts-stack"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "`@bsv/wallet-toolbox` / `-client` / `-mobile` don\u0027t verify storage-supplied recipient output scripts against caller-requested outputs in createAction"
}

GHSA-37P7-MHJW-VWH9

Vulnerability from github – Published: 2026-07-14 18:31 – Updated: 2026-07-14 18:31
VLAI
Details

Improper validation of consistency within input in Windows Secure Kernel Mode allows an authorized attacker to elevate privileges locally.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-42982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T17:16:48Z",
    "severity": "HIGH"
  },
  "details": "Improper validation of consistency within input in Windows Secure Kernel Mode allows an authorized attacker to elevate privileges locally.",
  "id": "GHSA-37p7-mhjw-vwh9",
  "modified": "2026-07-14T18:31:58Z",
  "published": "2026-07-14T18:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42982"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42982"
    }
  ],
  "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"
    }
  ]
}

GHSA-5556-PPCW-GHH5

Vulnerability from github – Published: 2024-10-09 21:31 – Updated: 2024-10-09 21:31
VLAI
Details

An Improper Validation of Consistency within Input vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated network-based attacker sending a specifically malformed BGP packet to cause rpd to crash and restart, resulting in a Denial of Service (DoS). Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition.

In some cases, rpd fails to restart requiring a manual restart via the 'restart routing' CLI command.

This issue only affects systems with BGP traceoptions enabled and

requires a BGP session to be already established. Systems without BGP traceoptions enabled are not affected by this issue.

This issue affects iBGP and eBGP, and both IPv4 and IPv6 are affected by this vulnerability.

This issue affects:

Junos OS: 

  • All versions before 21.4R3-S8, 
  • 22.2 before 22.2R3-S5, 
  • 22.3 before 22.3R3-S4, 
  • 22.4 before 22.4R3-S3, 
  • 23.2 before 23.2R2-S2, 
  • 23.4 before 23.4R2; 

Junos OS Evolved: 

  • All versions before 21.4R3-S8-EVO, 
  • 22.2-EVO before 22.2R3-S5-EVO, 
  • 22.3-EVO before 22.3R3-S4-EVO, 
  • 22.4-EVO before 22.4R3-S3-EVO, 
  • 23.2-EVO before 23.2R2-S2-EVO, 
  • 23.4-EVO before 23.4R2-EVO.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/R:U
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-39515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-09T20:15:08Z",
    "severity": "HIGH"
  },
  "details": "An Improper Validation of Consistency within Input vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated network-based attacker sending a specifically malformed BGP packet to cause rpd to crash and restart, resulting in a Denial of Service (DoS). Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition.\n\nIn some cases, rpd fails to restart requiring a manual restart via the \u0027restart routing\u0027 CLI command.\n\nThis issue only affects systems with BGP traceoptions enabled and \n\nrequires a BGP session to be already established.  Systems without BGP traceoptions enabled are not affected by this issue.\n\nThis issue affects iBGP and eBGP, and both IPv4 and IPv6 are affected by this vulnerability.\n\nThis issue affects:\n\nJunos OS:\u00a0\n\n  *  All versions before 21.4R3-S8,\u00a0\n  *  22.2 before 22.2R3-S5,\u00a0\n  *  22.3 before 22.3R3-S4,\u00a0\n  *  22.4 before 22.4R3-S3,\u00a0\n  *  23.2 before 23.2R2-S2,\u00a0\n  *  23.4 before 23.4R2;\u00a0\n\n\nJunos OS Evolved:\u00a0\n\n  *  All versions before 21.4R3-S8-EVO,\u00a0\n  *  22.2-EVO before 22.2R3-S5-EVO,\u00a0\n  *  22.3-EVO before 22.3R3-S4-EVO,\u00a0\n  *  22.4-EVO before 22.4R3-S3-EVO,\u00a0\n  *  23.2-EVO before 23.2R2-S2-EVO,\u00a0\n  *  23.4-EVO before 23.4R2-EVO.",
  "id": "GHSA-5556-ppcw-ghh5",
  "modified": "2024-10-09T21:31:08Z",
  "published": "2024-10-09T21:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39515"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA88099"
    },
    {
      "type": "WEB",
      "url": "https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/traceoptions-edit-protocols-bgp.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/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:U/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5PCM-F9X8-MPVJ

Vulnerability from github – Published: 2026-09-08 18:32 – Updated: 2026-09-08 18:32
VLAI
Details

Improper validation of consistency within input in Windows TCP/IP allows an unauthorized attacker to bypass a security feature over a network.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-69793"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T18:19:50Z",
    "severity": "HIGH"
  },
  "details": "Improper validation of consistency within input in Windows TCP/IP allows an unauthorized attacker to bypass a security feature over a network.",
  "id": "GHSA-5pcm-f9x8-mpvj",
  "modified": "2026-09-08T18:32:59Z",
  "published": "2026-09-08T18:32:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69793"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-69793"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VHQ-C669-FMGR

Vulnerability from github – Published: 2024-06-05 21:31 – Updated: 2024-06-05 21:31
VLAI
Details

An issue was discovered in Samsung Mobile Processor Exynos 980, Exynos 850, Exynos 1280, Exynos 1380, and Exynos 1330. In the function slsi_nan_followup_get_nl_params(), there is no input validation check on hal_req->service_specific_info_len coming from userspace, which can lead to a heap overwrite.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-27371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-05T19:15:12Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Samsung Mobile Processor Exynos 980, Exynos 850, Exynos 1280, Exynos 1380, and Exynos 1330. In the function slsi_nan_followup_get_nl_params(), there is no input validation check on hal_req-\u003eservice_specific_info_len coming from userspace, which can lead to a heap overwrite.",
  "id": "GHSA-5vhq-c669-fmgr",
  "modified": "2024-06-05T21:31:27Z",
  "published": "2024-06-05T21:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27371"
    },
    {
      "type": "WEB",
      "url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates"
    }
  ],
  "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-5VMP-M5V2-HX47

Vulnerability from github – Published: 2025-03-28 22:12 – Updated: 2025-10-14 21:58
VLAI
Summary
tough root metadata version is not checked for sequential versioning
Details

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Severity
4.2 (Medium)
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:H/A:N
5.7 (Medium)
CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tough"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-2885"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-28T22:12:36Z",
    "nvd_published_at": "2025-03-27T23:15:35Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWhen updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.\n\n## Impact\n\nThe tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.\n\nImpacted versions: \u003c v0.20.0\n\n## Patches\n\nA fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.\n\n## Workarounds\n\nThere is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.\n\n## References\n\nIf you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n\n[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting\n\n## Acknowledgement\n\nThese issues were identified by the [TUF-Conformance project](https://github.com/theupdateframework/tuf-conformance). We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.",
  "id": "GHSA-5vmp-m5v2-hx47",
  "modified": "2025-10-14T21:58:49Z",
  "published": "2025-03-28T22:12:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/security/advisories/GHSA-5vmp-m5v2-hx47"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2885"
    },
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/commit/0eeb60aefe27f00b65730634b788a1aafb8bf3c6"
    },
    {
      "type": "WEB",
      "url": "https://aws.amazon.com/security/security-bulletins/AWS-2025-007"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/awslabs/tough"
    },
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/releases/tag/tough-v0.20.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "tough root metadata version is not checked for sequential versioning"
}

GHSA-6QP2-4FQ6-H4PV

Vulnerability from github – Published: 2024-06-05 21:31 – Updated: 2024-06-05 21:31
VLAI
Details

An issue was discovered in Samsung Mobile Processor Exynos 980, Exynos 850, Exynos 1280, Exynos 1380, and Exynos 1330. In the function slsi_nan_followup_get_nl_params(), there is no input validation check on hal_req->sdea_service_specific_info_len coming from userspace, which can lead to a heap overwrite.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-27375"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-05T19:15:13Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Samsung Mobile Processor Exynos 980, Exynos 850, Exynos 1280, Exynos 1380, and Exynos 1330. In the function slsi_nan_followup_get_nl_params(), there is no input validation check on hal_req-\u003esdea_service_specific_info_len coming from userspace, which can lead to a heap overwrite.",
  "id": "GHSA-6qp2-4fq6-h4pv",
  "modified": "2024-06-05T21:31:27Z",
  "published": "2024-06-05T21:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27375"
    },
    {
      "type": "WEB",
      "url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates"
    }
  ],
  "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-7787-P7X6-FQ3J

Vulnerability from github – Published: 2023-12-08 15:23 – Updated: 2023-12-08 19:52
VLAI
Summary
Candid infinite decoding loop through specially crafted payload
Details

Impact

The Candid library causes a Denial of Service while parsing a specially crafted payload with empty data type. For example, if the payload is record { * ; empty } and the canister interface expects record { * } then the rust candid decoder treats empty as an extra field required by the type. The problem with type empty is that the candid rust library wrongly categorizes empty as a recoverable error when skipping the field and thus causing an infinite decoding loop.

Canisters using affected versions of candid are exposed to denial of service by causing the decoding to run indefinitely until the canister traps due to reaching maximum instruction limit per execution round. Repeated exposure to the payload will result in degraded performance of the canister.

For asset canister users, dfx versions >= 0.14.4 to <= 0.15.2-beta.0 ships asset canister with an affected version of candid.

Unaffected

  • Rust canisters using candid < 0.9.0 or >= 0.9.10
  • Rust canister interfaces of type other than record { * }
  • Motoko based canisters
  • dfx (for asset canister) <= 0.14.3 or >= 0.15.2

Patches

The issue has been patched in 0.9.10. All rust based canisters on candid versions >= 0.9.0 must upgrade their candid versions to >= 0.9.10 and deploy their canisters to mainnet as soon as possible.

Workarounds

There is no workaround for canisters using the affected versions of candid other than upgrading to patched version.

References

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "candid"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.9.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-6245"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288",
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-08T15:23:22Z",
    "nvd_published_at": "2023-12-08T15:15:08Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe Candid library causes a Denial of Service while parsing a specially crafted payload with `empty` data type. For example, if the payload is `record { * ; empty }` and  the canister interface expects `record { * }` then the rust candid decoder treats `empty` as an extra field required by the type.  The problem with type `empty` is that the candid rust library wrongly categorizes `empty` as a recoverable error when skipping the field and thus causing an infinite decoding loop. \n\nCanisters using affected versions of candid are exposed to denial of service by causing the decoding to run indefinitely until the canister traps due to reaching maximum instruction limit per execution round. Repeated exposure to the payload will result in degraded performance of the canister.\n\nFor asset canister users, `dfx` versions `\u003e= 0.14.4` to `\u003c= 0.15.2-beta.0` ships asset canister with an affected version of candid.\n\n#### Unaffected \n- Rust canisters using candid `\u003c 0.9.0` or `\u003e= 0.9.10` \n- Rust canister interfaces of type other than `record { * }`\n- Motoko based canisters\n- dfx (for asset canister) `\u003c= 0.14.3` or `\u003e= 0.15.2`\n\n\n### Patches\n\nThe issue has been patched in `0.9.10`. All rust based canisters on candid versions `\u003e= 0.9.0` must upgrade their candid versions to `\u003e= 0.9.10` and deploy their canisters to mainnet as soon as possible. \n\n### Workarounds\n\nThere is no workaround for canisters using the affected versions of candid other than upgrading to patched version.\n\n### References\n-  [dfinity/candid/pull/478](https://github.com/dfinity/candid/pull/478)\n-  [Candid Library Reference](https://internetcomputer.org/docs/current/references/candid-ref)\n-  [Candid Specification](https://github.com/dfinity/candid/blob/master/spec/Candid.md)\n-  [Internet Computer Specification](https://internetcomputer.org/docs/current/references/ic-interface-spec)",
  "id": "GHSA-7787-p7x6-fq3j",
  "modified": "2023-12-08T19:52:40Z",
  "published": "2023-12-08T15:23:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dfinity/candid/security/advisories/GHSA-7787-p7x6-fq3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6245"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dfinity/candid/pull/478"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dfinity/candid/commit/b233dbc2d2bcc79c9fc574dd5968269df680b073"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dfinity/candid"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dfinity/candid/blob/master/spec/Candid.md"
    },
    {
      "type": "WEB",
      "url": "https://internetcomputer.org/docs/current/references/candid-ref"
    },
    {
      "type": "WEB",
      "url": "https://internetcomputer.org/docs/current/references/ic-interface-spec"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0073.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Candid infinite decoding loop through specially crafted payload"
}

GHSA-7RFW-87CG-PGWH

Vulnerability from github – Published: 2025-05-22 15:34 – Updated: 2025-05-22 15:34
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions from 11.1 before 17.10.7, 17.11 before 17.11.3, and 18.0 before 18.0.1. Improper XPath validation allows modified SAML response to bypass 2FA requirement under specialized conditions.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-12093"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-22T15:16:03Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions from 11.1 before 17.10.7, 17.11 before 17.11.3, and 18.0 before 18.0.1. Improper XPath validation allows modified SAML response to bypass 2FA requirement under specialized conditions.",
  "id": "GHSA-7rfw-87cg-pgwh",
  "modified": "2025-05-22T15:34:51Z",
  "published": "2025-05-22T15:34:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12093"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2851261"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/507445"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list