Common Weakness Enumeration

CWE-328

Allowed

Use of Weak Hash

Abstraction: Base · Status: Draft

The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).

149 vulnerabilities reference this CWE, most recent first.

GHSA-67FJ-6W6M-W5J8

Vulnerability from github – Published: 2022-05-25 22:34 – Updated: 2022-05-25 22:34
VLAI
Summary
Reversible One-Way Hash in io.github.javaezlib:JavaEZ
Details

Impact

This weakness allows the force decryption of locked text by hackers. The issue is NOT critical for non-secure applications, however may be critical in a situation where the highest levels of security are required. This issue ONLY affects v1.6 and does not affect anything pre-1.6. Upgrading to 1.7 is advised.

Patches

The vulnerability has been patched in release 1.7.

Workarounds

Currently there is no way to fix the issue without upgrading.

References

CWE-327 CWE-328

For more information

If you have any questions or comments about this advisory: * Open an issue in our issue tracker * Email us at javaezlib@gmail.com

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.github.javaezlib:JavaEZ"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6"
            },
            {
              "fixed": "1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.6"
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-326",
      "CWE-327",
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-05-25T22:34:15Z",
    "nvd_published_at": "2022-05-24T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThis weakness allows the force decryption of locked text by hackers. The issue is NOT critical for non-secure applications, however may be critical in a situation where the highest levels of security are required. This issue ONLY affects v1.6 and does not affect anything pre-1.6. Upgrading to 1.7 is advised.\n\n### Patches\nThe vulnerability has been patched in release 1.7.\n\n### Workarounds\nCurrently there is no way to fix the issue without upgrading.\n\n### References\n[CWE-327](https://cwe.mitre.org/data/definitions/327.html)\n[CWE-328](https://cwe.mitre.org/data/definitions/328.html)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [our issue tracker](http://github.com/JavaEZLib/JavaEZ/issues)\n* Email us at [javaezlib@gmail.com](mailto:javaezlib@gmail.com)\n",
  "id": "GHSA-67fj-6w6m-w5j8",
  "modified": "2022-05-25T22:34:15Z",
  "published": "2022-05-25T22:34:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/JavaEZLib/JavaEZ/security/advisories/GHSA-67fj-6w6m-w5j8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29249"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/JavaEZLib/JavaEZ"
    },
    {
      "type": "WEB",
      "url": "https://github.com/JavaEZLib/JavaEZ/releases/tag/1.7"
    }
  ],
  "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"
    }
  ],
  "summary": "Reversible One-Way Hash in io.github.javaezlib:JavaEZ"
}

GHSA-794X-2RPG-RFGR

Vulnerability from github – Published: 2025-04-07 16:40 – Updated: 2025-04-07 16:40
VLAI
Summary
Jujutsu does not have SHA-1 collision detection
Details

Summary

Jujutsu 0.28.0 and earlier rely on versions of gitoxide that use SHA-1 hash implementations without any collision detection, leaving them vulnerable to hash collision attacks.

Details

This is a result of the underlying CVE-2025-31130 / GHSA-2frx-2596-x5r6 vulnerability in the gitoxide library Jujutsu uses to interact with Git repositories; see that advisory for technical details. This separate advisory is being issued due to the downstream impact on users of Jujutsu.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in Jujutsu’s logic to cause further vulnerabilities.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "jj-lib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.28.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "jj-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.28.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-07T16:40:25Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nJujutsu 0.28.0 and earlier rely on versions of gitoxide that use SHA-1 hash implementations without any collision detection, leaving them vulnerable to hash collision attacks.\n\n### Details\nThis is a result of the underlying [CVE-2025-31130 / GHSA-2frx-2596-x5r6](https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-2frx-2596-x5r6) vulnerability in the gitoxide library Jujutsu uses to interact with Git repositories; see that advisory for technical details. This separate advisory is being issued due to the downstream impact on users of Jujutsu.\n\n### Impact\nAn attacker with the ability to mount a collision attack on SHA-1 like the [SHAttered](https://shattered.io/) or [SHA-1 is a Shambles](https://sha-mbles.github.io/) attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well\u2010resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen\u2010prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen\u2010prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in Jujutsu\u2019s logic to cause further vulnerabilities.",
  "id": "GHSA-794x-2rpg-rfgr",
  "modified": "2025-04-07T16:40:25Z",
  "published": "2025-04-07T16:40:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jj-vcs/jj/security/advisories/GHSA-794x-2rpg-rfgr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jj-vcs/jj/commit/350da7d013773377aec0d3a4bf4374d3c941460e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jj-vcs/jj"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jujutsu does not have SHA-1 collision detection"
}

GHSA-7FXM-RP47-F3XM

Vulnerability from github – Published: 2026-07-01 09:30 – Updated: 2026-07-01 09:30
VLAI
Details

The Control-M/Enterprise Manager uses weak protections for stored hashes of account passwords, potentially allowing offline password recovery attacks if credential data is obtained by an attacker. This vulnerability affects Control-M/Enterprise Manager unsupported versions 9.0.20.x and potentially earlier unsupported versions

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-10540"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T08:16:20Z",
    "severity": "MODERATE"
  },
  "details": "The Control-M/Enterprise Manager uses weak protections for stored hashes of account passwords, potentially allowing offline password recovery attacks if credential data is obtained by an attacker. This vulnerability affects Control-M/Enterprise Manager unsupported versions 9.0.20.x and potentially earlier unsupported versions",
  "id": "GHSA-7fxm-rp47-f3xm",
  "modified": "2026-07-01T09:30:25Z",
  "published": "2026-07-01T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10540"
    },
    {
      "type": "WEB",
      "url": "https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=kA3cx000000GFeDCAW\u0026type=Solution"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/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-7XPV-834V-X9RJ

Vulnerability from github – Published: 2025-05-28 18:33 – Updated: 2025-05-28 18:33
VLAI
Details

IBM Sterling Secure Proxy 6.0.0.0 through 6.0.3.1, 6.1.0.0 through 6.1.0.0, and 6.2.0.0 through 6.2.0.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38341"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-326",
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-28T16:15:32Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling Secure Proxy 6.0.0.0 through 6.0.3.1, 6.1.0.0 through 6.1.0.0, and 6.2.0.0 through 6.2.0.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.",
  "id": "GHSA-7xpv-834v-x9rj",
  "modified": "2025-05-28T18:33:27Z",
  "published": "2025-05-28T18:33:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38341"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7234888"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8986-V76Q-8VR2

Vulnerability from github – Published: 2026-03-02 22:09 – Updated: 2026-03-02 22:09
VLAI
Summary
@keep-network/tbtc-v2 revealing P2PKH deposit with a wrapped P2SH script
Details

Overview

P2PKH has 20 bytes just like P2SH. We protect against revealing P2PKH deposits by manually assembling the expected P2SH script in the smart contract and comparing hashes. However, we missed the case when the attacker embeds a valid P2SH inside of P2PKH as an output script. bitcoin-spv library extracts the P2SH from P2PKH and we treat it as a valid P2SH output.

This does not lead to stealing funds but can lead to protocol insolvency.

The off-chain client handles this case correctly, but the problem is in the optimistic minting bot. The bot assumes that if the funding TX exists on Bitcoin with the right amount and it was successfully revealed, the transaction is valid.

https://bugs.immunefi.com/magnus/672/projects/502/bug-bounty/reports/55982

Steps

Since there is a 24-hour governance delay on upgrading the Bridge smart contract, we are going to pause optimistic minting.

  1. Pause optimistic minting.
  2. Deploy new Bridge implementation with Deposit library containing a fix, WITHOUT VERIFYING THE CODE on Etherscan.
  3. Schedule upgrade transaction.
  4. After 24 hours, finalize upgrade.
  5. Unpause optimistic minting.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@keep-network/tbtc-v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T22:09:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# Overview\n\nP2PKH has 20 bytes just like P2SH. We protect against revealing P2PKH deposits by manually assembling the expected P2SH script in the smart contract and comparing hashes. However, we missed the case when the attacker embeds a valid P2SH inside of P2PKH as an output script. bitcoin-spv library [extracts the P2SH from P2PKH](https://github.com/keep-network/bitcoin-spv/blob/856849612ef49114af18c0f407eaa74afc2ee4be/solidity/contracts/BTCUtils.sol#L610-L612) and we treat it as a valid P2SH output.\n\nThis does not lead to stealing funds but can lead to protocol insolvency.\n\nThe off-chain client handles this case correctly, but the problem is in the optimistic minting bot. The bot assumes that if the funding TX exists on Bitcoin with the right amount and it was successfully revealed, the transaction is valid.\n\nhttps://bugs.immunefi.com/magnus/672/projects/502/bug-bounty/reports/55982\n\n# Steps\n\nSince there is a 24-hour governance delay on upgrading the Bridge smart contract, we are going to pause optimistic minting.\n\n1. Pause optimistic minting.\n2. Deploy new Bridge implementation with Deposit library containing a fix, WITHOUT VERIFYING THE CODE on Etherscan.\n3. Schedule upgrade transaction.\n4. After 24 hours, finalize upgrade.\n5. Unpause optimistic minting.",
  "id": "GHSA-8986-v76q-8vr2",
  "modified": "2026-03-02T22:09:19Z",
  "published": "2026-03-02T22:09:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/threshold-network/tbtc-v2/security/advisories/GHSA-8986-v76q-8vr2"
    },
    {
      "type": "WEB",
      "url": "https://bugs.immunefi.com/magnus/672/projects/502/bug-bounty/reports/55982"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keep-network/bitcoin-spv/blob/856849612ef49114af18c0f407eaa74afc2ee4be/solidity/contracts/BTCUtils.sol#L610-L612"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/threshold-network/tbtc-v2"
    }
  ],
  "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": "@keep-network/tbtc-v2 revealing P2PKH deposit with a wrapped P2SH script"
}

GHSA-89V6-G7J9-XJ43

Vulnerability from github – Published: 2022-09-20 00:00 – Updated: 2022-09-23 00:00
VLAI
Details

WD Discovery software executable files were signed with an unsafe SHA-1 hashing algorithm. An attacker could use this weakness to create forged certificate signatures due to the use of a hashing algorithm that is not collision-free. This could thereby impact the confidentiality of user content. This issue affects: Western Digital WD Discovery WD Discovery Desktop App versions prior to 4.4.396 on Mac; WD Discovery Desktop App versions prior to 4.4.396 on Windows.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-29835"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-326",
      "CWE-327",
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-19T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "WD Discovery software executable files were signed with an unsafe SHA-1 hashing algorithm. An attacker could use this weakness to create forged certificate signatures due to the use of a hashing algorithm that is not collision-free. This could thereby impact the confidentiality of user content. This issue affects: Western Digital WD Discovery WD Discovery Desktop App versions prior to 4.4.396 on Mac; WD Discovery Desktop App versions prior to 4.4.396 on Windows.",
  "id": "GHSA-89v6-g7j9-xj43",
  "modified": "2022-09-23T00:00:42Z",
  "published": "2022-09-20T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29835"
    },
    {
      "type": "WEB",
      "url": "https://www.westerndigital.com/support/product-security/wdc-22014-wd-discovery-desktop-app-version-4-4-396"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8CC4-RFJ6-FHG4

Vulnerability from github – Published: 2025-04-23 14:05 – Updated: 2025-04-23 19:15
VLAI
Summary
pnpm uses the md5 path shortening function causes packet paths to coincide, which causes indirect packet overwriting
Details

The path shortening function is used in pnpm:

export function depPathToFilename (depPath: string, maxLengthWithoutHash: number): string {
  let filename = depPathToFilenameUnescaped(depPath).replace(/[\\/:*?"<>|]/g, '+')
  if (filename.includes('(')) {
    filename = filename
      .replace(/\)$/, '')
      .replace(/(\)\()|\(|\)/g, '_')
  }
  if (filename.length > maxLengthWithoutHash || filename !== filename.toLowerCase() && !filename.startsWith('file+')) {
    return `${filename.substring(0, maxLengthWithoutHash - 27)}_${createBase32Hash(filename)}`
  }
  return filename
}

However, it uses the md5 function as a path shortening compression function, and if a collision occurs, it will result in the same storage path for two different libraries. Although the real names are under the package name /node_modoules/, there are no version numbers for the libraries they refer to. Schematic picture In the diagram, we assume that two packages are called packageA and packageB, and that the first 90 digits of their package names must be the same, and that the hash value of the package names with versions must be the same. Then C is the package that they both reference, but with a different version number. (npm allows package names up to 214 bytes, so constructing such a collision package name is obvious.)

Then hash(packageA@1.2.3)=hash(packageB@3.4.5). This results in the same path for the installation, and thus under the same directory. Although the package names under node_modoules are the full paths again, they are shared with C. What is the exact version number of C? In our local tests, it depends on which one is installed later. If packageB is installed later, the C version number will change to 2.0.0. At this time, although package A requires the C@1.0.0 version, package. json will only work during installation, and will not affect the actual operation. We did not receive any installation error issues from pnpm during our local testing, nor did we use force, which is clearly a case that can be triggered.

For a package with a package name + version number longer than 120, another package can be constructed to introduce an indirect reference to a lower version, such as one with some known vulnerability. Alternatively, it is possible to construct two packages with more than 120 package names + version numbers. This is clearly an advantage for those intent on carrying out supply chain attacks.

The solution: The repair cost is also very low, just need to upgrade the md5 function to sha256.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-23T14:05:47Z",
    "nvd_published_at": "2025-04-23T16:15:29Z",
    "severity": "MODERATE"
  },
  "details": "The path shortening function is used in pnpm\uff1a\n```\nexport function depPathToFilename (depPath: string, maxLengthWithoutHash: number): string {\n  let filename = depPathToFilenameUnescaped(depPath).replace(/[\\\\/:*?\"\u003c\u003e|]/g, \u0027+\u0027)\n  if (filename.includes(\u0027(\u0027)) {\n    filename = filename\n      .replace(/\\)$/, \u0027\u0027)\n      .replace(/(\\)\\()|\\(|\\)/g, \u0027_\u0027)\n  }\n  if (filename.length \u003e maxLengthWithoutHash || filename !== filename.toLowerCase() \u0026\u0026 !filename.startsWith(\u0027file+\u0027)) {\n    return `${filename.substring(0, maxLengthWithoutHash - 27)}_${createBase32Hash(filename)}`\n  }\n  return filename\n}\n```\nHowever, it uses the md5 function as a path shortening compression function, and if a collision occurs, it will result in the same storage path for two different libraries. Although the real names are under the package name /node_modoules/, there are no version numbers for the libraries they refer to.\n![Schematic picture](https://github.com/user-attachments/assets/7b8b87ab-f297-47bd-a9dd-43be86e36ed2)\nIn the diagram, we assume that two packages are called packageA and packageB, and that the first 90 digits of their package names must be the same, and that the hash value of the package names with versions must be the same.  Then C is the package that they both reference, but with a different version number.  (npm allows package names up to 214 bytes, so constructing such a collision package name is obvious.)\n\nThen hash(packageA@1.2.3)=hash(packageB@3.4.5).  This results in the same path for the installation, and thus under the same directory.  Although the package names under node_modoules are the full paths again, they are shared with C.\nWhat is the exact version number of C?\nIn our local tests, it depends on which one is installed later.  If packageB is installed later, the C version number will change to 2.0.0.  At this time, although package A requires the C@1.0.0 version, package. json will only work during installation, and will not affect the actual operation.\nWe did not receive any installation error issues from pnpm during our local testing, nor did we use force, which is clearly a case that can be triggered.\n\nFor a package with a package name + version number longer than 120, another package can be constructed to introduce an indirect reference to a lower version, such as one with some known vulnerability.\nAlternatively, it is possible to construct two packages with more than 120 package names + version numbers.\nThis is clearly an advantage for those intent on carrying out supply chain attacks.\n\n\nThe solution:\nThe repair cost is also very low, just need to upgrade the md5 function to sha256.",
  "id": "GHSA-8cc4-rfj6-fhg4",
  "modified": "2025-04-23T19:15:59Z",
  "published": "2025-04-23T14:05:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-8cc4-rfj6-fhg4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47829"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pnpm/pnpm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pnpm uses the md5 path shortening function causes packet paths to coincide, which causes indirect packet overwriting"
}

GHSA-8CH8-93Q8-MHM3

Vulnerability from github – Published: 2026-06-30 18:31 – Updated: 2026-06-30 18:31
VLAI
Details

PostgreSQL Anonymizer contains a vulnerability that allows unprivileged masked users to repeatedly call the anon.hash() function and collects (seed, hash_output) pairs to perform an offline brute-force attack and deduce the salt. The problem is resolved in PostgreSQL Anonymizer 3.1.2 and later versions

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-13455"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T16:16:44Z",
    "severity": "MODERATE"
  },
  "details": "PostgreSQL Anonymizer contains a vulnerability that allows unprivileged masked users to repeatedly call the anon.hash() function and collects (seed, hash_output) pairs to perform an offline brute-force attack and deduce the salt. The problem is resolved in PostgreSQL Anonymizer 3.1.2 and later versions",
  "id": "GHSA-8ch8-93q8-mhm3",
  "modified": "2026-06-30T18:31:36Z",
  "published": "2026-06-30T18:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13455"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/dalibo/postgresql_anonymizer/-/issues/649"
    }
  ],
  "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"
    }
  ]
}

GHSA-8VFW-V3XX-J7XW

Vulnerability from github – Published: 2025-05-30 18:31 – Updated: 2025-05-30 18:31
VLAI
Details

Due to outdated Hash algorithm, HCL Glovius Cloud could allow attackers to guess the input data using brute-force or dictionary attacks efficiently using modern hardware such as GPUs or ASICs

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-23589"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-30T16:15:36Z",
    "severity": "MODERATE"
  },
  "details": "Due to outdated Hash algorithm, HCL Glovius Cloud could allow attackers to guess the input data using brute-force or dictionary attacks efficiently using modern hardware such as GPUs or ASICs",
  "id": "GHSA-8vfw-v3xx-j7xw",
  "modified": "2025-05-30T18:31:14Z",
  "published": "2025-05-30T18:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23589"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0121015"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-92MJ-XR7P-2G9C

Vulnerability from github – Published: 2026-06-30 12:31 – Updated: 2026-06-30 12:31
VLAI
Details

Redeight CMS version 1.0 uses the MD5 algorithm without a salt to store user passwords. Because MD5 is a cryptographically broken algorithm and lacks salting, attackers who obtain the password hashes can trivially reverse them using rainbow tables, leading to the exposure of plaintext credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53692"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-261",
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T12:16:24Z",
    "severity": "MODERATE"
  },
  "details": "Redeight CMS version 1.0 uses the MD5 algorithm without a salt to store user passwords. Because MD5 is a cryptographically broken algorithm and lacks salting, attackers who obtain the password hashes can trivially reverse them using rainbow tables, leading to the exposure of plaintext credentials.",
  "id": "GHSA-92mj-xr7p-2g9c",
  "modified": "2026-06-30T12:31:53Z",
  "published": "2026-06-30T12:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53692"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/posts/2026/06/CVE-2026-53690"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/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"
    }
  ]
}

Mitigation MIT-51
Architecture and Design
  • Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.
  • Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.
  • Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.

CAPEC-68: Subvert Code-signing Facilities

Many languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges within an environment. Subverting this mechanism can be instrumental in an attacker escalating privilege. Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack.