Common Weakness Enumeration

CWE-328

Allowed

Use of Weak Hash

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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-9J3M-FR7Q-JXFW

Vulnerability from github – Published: 2024-12-12 19:22 – Updated: 2024-12-18 19:22
VLAI
Summary
Beego has Collision Hazards of MD5 in Cache Key Filenames
Details

In the context of using MD5 to generate filenames for cache keys, there are significant collision hazards that need to be considered. MD5, or Message Digest Algorithm 5, is a widely known cryptographic hash function that produces a 128-bit hash value. However, MD5 is no longer considered secure against well-funded opponents due to its vulnerability to collision attacks.

Understanding Collisions

A collision in hashing occurs when two different inputs produce the same hash output. For MD5, this means that it is theoretically possible, and even practical, to find two distinct cache keys that result in the same MD5 hash. This vulnerability has been well-documented and exploited in various security contexts.

Implications for Cache Systems

In a cache system where filenames are derived from the MD5 hash of cache keys, a collision could lead to several critical issues:

Data Integrity Risks: If two different keys collide, they will map to the same filename. This could result in data being overwritten incorrectly, leading to data loss or corruption. Security Vulnerabilities: An attacker could potentially exploit collisions to manipulate cache data. For instance, by crafting a key that collides with another key, an attacker might gain unauthorized access to sensitive cached information or inject malicious data.

Unpredictable Behavior: Collisions can cause the cache system to behave unpredictably, as it may retrieve or store data in unintended files, leading to system instability or incorrect behavior.

Mitigation Strategies

To mitigate these risks, consider the following strategies:

Use a More Secure Hash Function: Replace MD5 with a more secure hash function like SHA-256, which has a significantly lower probability of collisions and is resistant to known attack vectors.

code at:https://github.com/beego/beego/blob/bb72dc27ac3970e51d38ee52fc3dc1465ae25b9d/client/cache/file.go#L126

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/beego/beego"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.12.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/beego/beego/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-55885"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-327",
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-12T19:22:39Z",
    "nvd_published_at": "2024-12-12T20:15:21Z",
    "severity": "MODERATE"
  },
  "details": "In the context of using MD5 to generate filenames for cache keys, there are significant collision hazards that need to be considered. MD5, or Message Digest Algorithm 5, is a widely known cryptographic hash function that produces a 128-bit hash value. However, MD5 is no longer considered secure against well-funded opponents due to its vulnerability to collision attacks.\n\n### Understanding Collisions\nA collision in hashing occurs when two different inputs produce the same hash output. For MD5, this means that it is theoretically possible, and even practical, to find two distinct cache keys that result in the same MD5 hash. This vulnerability has been well-documented and exploited in various security contexts.\n\n### Implications for Cache Systems\nIn a cache system where filenames are derived from the MD5 hash of cache keys, a collision could lead to several critical issues:\n\nData Integrity Risks: If two different keys collide, they will map to the same filename. This could result in data being overwritten incorrectly, leading to data loss or corruption.\nSecurity Vulnerabilities: An attacker could potentially exploit collisions to manipulate cache data. For instance, by crafting a key that collides with another key, an attacker might gain unauthorized access to sensitive cached information or inject malicious data.\n\nUnpredictable Behavior: Collisions can cause the cache system to behave unpredictably, as it may retrieve or store data in unintended files, leading to system instability or incorrect behavior.\n\n### Mitigation Strategies\nTo mitigate these risks, consider the following strategies:\n\nUse a More Secure Hash Function: Replace MD5 with a more secure hash function like SHA-256, which has a significantly lower probability of collisions and is resistant to known attack vectors.\n\ncode at:https://github.com/beego/beego/blob/bb72dc27ac3970e51d38ee52fc3dc1465ae25b9d/client/cache/file.go#L126",
  "id": "GHSA-9j3m-fr7q-jxfw",
  "modified": "2024-12-18T19:22:40Z",
  "published": "2024-12-12T19:22:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/beego/beego/security/advisories/GHSA-9j3m-fr7q-jxfw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55885"
    },
    {
      "type": "WEB",
      "url": "https://github.com/beego/beego/commit/e7fa4835f71f47ab1d13afd638cebf661800d5a4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/beego/beego"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Beego has Collision Hazards of MD5 in Cache Key Filenames"
}

GHSA-9P92-X77W-9FW2

Vulnerability from github – Published: 2025-09-15 12:31 – Updated: 2025-09-16 19:13
VLAI
Summary
Mattermost makes Use of Weak Hash
Details

Mattermost versions 10.8.x <= 10.8.3, 10.5.x <= 10.5.8, 9.11.x <= 9.11.17, 10.10.x <= 10.10.1, 10.9.x <= 10.9.3 fail to properly validate cache keys for link metadata which allows authenticated users to access unauthorized posts and poison link previews via hash collision attacks on FNV-1 hashing.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.8.0"
            },
            {
              "fixed": "10.8.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.5.0"
            },
            {
              "fixed": "10.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.11.0"
            },
            {
              "fixed": "9.11.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.10.0"
            },
            {
              "fixed": "10.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.9.0"
            },
            {
              "fixed": "10.9.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250718075842-cd87e5c87737"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-9078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-16T19:13:08Z",
    "nvd_published_at": "2025-09-15T10:15:32Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 10.8.x \u003c= 10.8.3, 10.5.x \u003c= 10.5.8, 9.11.x \u003c= 9.11.17, 10.10.x \u003c= 10.10.1, 10.9.x \u003c= 10.9.3 fail to properly validate cache keys for link metadata which allows authenticated users to access unauthorized posts and poison link previews via hash collision attacks on FNV-1 hashing.",
  "id": "GHSA-9p92-x77w-9fw2",
  "modified": "2025-09-16T19:13:08Z",
  "published": "2025-09-15T12:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9078"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/356880c8430b77a4a390c89d5a33f6928188d137"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/944ad5cdd9876ef61c78c8275906262a4118755a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/a8a4badc130be101e5bc4b7916bbcd2f966c4b79"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/cd87e5c877373f109742aa90a3fa136c14774325"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost makes Use of Weak Hash"
}

GHSA-9QWV-Q8RP-329V

Vulnerability from github – Published: 2025-09-09 21:30 – Updated: 2025-09-09 21:30
VLAI
Details

CWE-328: Use of Weak Hash

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-55053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T20:15:46Z",
    "severity": "MODERATE"
  },
  "details": "CWE-328: Use of Weak Hash",
  "id": "GHSA-9qwv-q8rp-329v",
  "modified": "2025-09-09T21:30:29Z",
  "published": "2025-09-09T21:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55053"
    },
    {
      "type": "WEB",
      "url": "https://www.gov.il/en/departments/dynamiccollectors/cve_advisories_listing?skip=0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FH3F-Q9QW-93J9

Vulnerability from github – Published: 2026-02-19 19:41 – Updated: 2026-03-06 01:04
VLAI
Summary
OpenClaw replaced a deprecated sandbox hash algorithm
Details

Affected Packages / Versions

  • npm package: openclaw
  • Affected versions: <= 2026.2.14
  • Fixed version (pre-set): 2026.2.15

Description

The sandbox identifier cache key for Docker/browser sandbox configuration used SHA-1 to hash normalized configuration payloads.

SHA-1 is deprecated for cryptographic use and has known collision weaknesses. In this code path, deterministic IDs are used to decide whether an existing sandbox container can be reused safely. A collision in this hash could let one configuration be interpreted as another under the same sandbox cache identity, increasing the risk of cache poisoning and unsafe sandbox state reuse.

The implementation now uses SHA-256 for these deterministic hashes to restore collision resistance for this security-relevant identifier path.

Fix Commit(s)

  • 559c8d993

Release Process Note

patched_versions is pre-set to 2026.2.15 for the next release. After that release is published, mark this advisory ready for publication.

Thanks @kexinoh ( of Tencent zhuque Lab, by https://github.com/Tencent/AI-Infra-Guard) for reporting.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.14"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-327",
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-19T19:41:07Z",
    "nvd_published_at": "2026-03-05T22:16:22Z",
    "severity": "HIGH"
  },
  "details": "## Affected Packages / Versions\n- npm package: `openclaw`\n- Affected versions: `\u003c= 2026.2.14`\n- Fixed version (pre-set): `2026.2.15`\n\n## Description\nThe sandbox identifier cache key for Docker/browser sandbox configuration used SHA-1 to hash normalized configuration payloads.\n\nSHA-1 is deprecated for cryptographic use and has known collision weaknesses. In this code path, deterministic IDs are used to decide whether an existing sandbox container can be reused safely. A collision in this hash could let one configuration be interpreted as another under the same sandbox cache identity, increasing the risk of cache poisoning and unsafe sandbox state reuse.\n\nThe implementation now uses SHA-256 for these deterministic hashes to restore collision resistance for this security-relevant identifier path.\n\n## Fix Commit(s)\n- `559c8d993`\n\n## Release Process Note\n`patched_versions` is pre-set to `2026.2.15` for the next release. After that release is published, mark this advisory ready for publication.\n\nThanks @kexinoh ( of Tencent zhuque Lab, by https://github.com/Tencent/AI-Infra-Guard) for reporting.",
  "id": "GHSA-fh3f-q9qw-93j9",
  "modified": "2026-03-06T01:04:59Z",
  "published": "2026-02-19T19:41:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-fh3f-q9qw-93j9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/559c8d9930eebb5356506ff1a8cd3dbaec92be77"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.15"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-cache-poisoning-via-deprecated-sha-hash-in-sandbox-configuration"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw replaced a deprecated sandbox hash algorithm"
}

GHSA-FV42-MX39-6FPW

Vulnerability from github – Published: 2022-11-16 12:00 – Updated: 2022-12-15 18:45
VLAI
Summary
Whole-script approval in Jenkins Script Security Plugin vulnerable to SHA-1 collisions
Details

Script Security Plugin 1189.vb_a_b_7c8fd5fde and earlier stores whole-script approvals as the SHA-1 hash of the approved script. SHA-1 no longer meets the security standards for producing a cryptographically secure message digest.

Script Security Plugin 1190.v65867a_a_47126 uses SHA-512 for new whole-script approvals. Previously approved scripts will have their SHA-1 based whole-script approval replaced with a corresponding SHA-512 whole-script approval when the script is next used.

Whole-script approval only stores the SHA-1 or SHA-512 hash, so it is not possible to migrate all previously approved scripts automatically on startup.

Administrators concerned about SHA-1 collision attacks on the whole-script approval feature are able to revoke all previous (SHA-1) script approvals on the In-Process Script Approval page.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1189.vb"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:script-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1190.v65867a_a_47126"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-45379"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-326",
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-21T22:20:41Z",
    "nvd_published_at": "2022-11-15T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Script Security Plugin 1189.vb_a_b_7c8fd5fde and earlier stores whole-script approvals as the [SHA-1 hash](https://en.wikipedia.org/wiki/SHA-1) of the approved script. SHA-1 no longer meets the security standards for producing a cryptographically secure message digest.\n\nScript Security Plugin 1190.v65867a_a_47126 uses SHA-512 for new whole-script approvals. Previously approved scripts will have their SHA-1 based whole-script approval replaced with a corresponding SHA-512 whole-script approval when the script is next used.\n\nWhole-script approval only stores the SHA-1 or SHA-512 hash, so it is not possible to migrate all previously approved scripts automatically on startup.\n\nAdministrators concerned about SHA-1 collision attacks on the whole-script approval feature are able to revoke all previous (SHA-1) script approvals on the In-Process Script Approval page.",
  "id": "GHSA-fv42-mx39-6fpw",
  "modified": "2022-12-15T18:45:27Z",
  "published": "2022-11-16T12:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45379"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/script-security-plugin/commit/65867aa471265a16198b92fb439782ba3554da66"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/script-security-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-11-15/#SECURITY-2564"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/11/15/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Whole-script approval in Jenkins Script Security Plugin vulnerable to SHA-1 collisions"
}

GHSA-G2P6-HH5V-7HFM

Vulnerability from github – Published: 2026-03-13 15:40 – Updated: 2026-03-13 15:40
VLAI
Summary
Poseidon V1 variable-length input collision via implicit zero-padding
Details

Impact

Poseidon V1 (PoseidonSponge) accepts variable-length inputs without injective padding. When a caller provides fewer inputs than the sponge rate (inputs.len() < T - 1), unused rate positions are implicitly zero-filled. This allows trivial hash collisions: for any input vector [m1, ..., mk] hashed with a sponge of rate > k, hash([m1, ..., mk]) equals hash([m1, ..., mk, 0]) because both produce identical pre-permutation states.

This affects any use of PoseidonSponge or poseidon_hash where the number of inputs is less than T - 1 (e.g., hashing 1 input with T=3).

Poseidon2 (Poseidon2Sponge) is not affected — it encodes the input length in the capacity element (IV = input_len << 64), making different-length inputs produce distinct states.

Patches

Fixed by enforcing inputs.len() == RATE in PoseidonSponge::compute_hash, matching circom's invariant that nInputs always equals T - 1. Users should upgrade to the next release containing this fix.

Workarounds

If upgrading is not immediately possible:

  • Ensure callers always use T = inputs.len() + 1 (full-rate), which is how circom uses Poseidon. For example, to hash 2 inputs, use T=3; to hash 1 input, use T=2. Never use a sponge with more rate capacity than the number of inputs.
  • Alternatively, migrate to Poseidon2Sponge, which is safe for variable-length inputs due to its length-encoding IV.

References

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": "crates.io",
        "name": "soroban-poseidon"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "25.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32129"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T15:40:31Z",
    "nvd_published_at": "2026-03-12T18:16:25Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\nPoseidon V1 (`PoseidonSponge`) accepts variable-length inputs without injective padding. When a caller provides fewer inputs than the sponge rate (`inputs.len() \u003c T - 1`), unused rate positions are implicitly zero-filled. This allows trivial hash collisions: for any input vector `[m1, ..., mk]` hashed with a sponge of rate \u003e k, `hash([m1, ..., mk])` equals `hash([m1, ..., mk, 0])` because both produce identical pre-permutation states.\n\nThis affects any use of `PoseidonSponge` or `poseidon_hash` where the number of inputs is less than `T - 1` (e.g., hashing 1 input with `T=3`).\n\nPoseidon2 (`Poseidon2Sponge`) is **not affected** \u2014 it encodes the input length in the capacity element (`IV = input_len \u003c\u003c 64`), making different-length inputs produce distinct states.\n\n## Patches\n\nFixed by enforcing `inputs.len() == RATE` in `PoseidonSponge::compute_hash`, matching circom\u0027s invariant that `nInputs` always equals `T - 1`. Users should upgrade to the next release containing this fix.\n\n## Workarounds\n\nIf upgrading is not immediately possible:\n\n- Ensure callers **always** use `T = inputs.len() + 1` (full-rate), which is how circom uses Poseidon. For example, to hash 2 inputs, use `T=3`; to hash 1 input, use `T=2`. Never use a sponge with more rate capacity than the number of inputs.\n- Alternatively, migrate to `Poseidon2Sponge`, which is safe for variable-length inputs due to its length-encoding IV.\n\n## References\n- [circom Poseidon implementation](https://github.com/iden3/circomlib/blob/master/circuits/poseidon.circom) \u2014 reference implementation where `nInputs` determines `T`\n- [Poseidon paper](https://eprint.iacr.org/2019/458) \u2014 Section 4 discusses sponge construction and padding requirements",
  "id": "GHSA-g2p6-hh5v-7hfm",
  "modified": "2026-03-13T15:40:31Z",
  "published": "2026-03-13T15:40:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-poseidon/security/advisories/GHSA-g2p6-hh5v-7hfm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-poseidon/pull/10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-poseidon/commit/ceb20d3593fc4a8a951a7e99d8fa2344f8250a8c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stellar/rs-soroban-poseidon"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-poseidon/releases/tag/v25.0.1"
    }
  ],
  "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": "Poseidon V1 variable-length input collision via implicit zero-padding"
}

GHSA-G5HG-3X62-V52F

Vulnerability from github – Published: 2023-03-07 00:30 – Updated: 2023-03-13 18:30
VLAI
Details

Since the Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability was disclosed by Microsoft on Nov 8 2022 and per RFC8429 it is assumed that rc4-hmac is weak, Vulnerable Samba Active Directory DCs will issue rc4-hmac encrypted tickets despite the target server supporting better encryption (eg aes256-cts-hmac-sha1-96).

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-45141"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-326",
      "CWE-327",
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-06T23:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Since the Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability was disclosed by Microsoft on Nov 8 2022 and per RFC8429 it is assumed that rc4-hmac is weak, Vulnerable Samba Active Directory DCs will issue rc4-hmac encrypted tickets despite the target server supporting better encryption (eg aes256-cts-hmac-sha1-96).",
  "id": "GHSA-g5hg-3x62-v52f",
  "modified": "2023-03-13T18:30:41Z",
  "published": "2023-03-07T00:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45141"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202309-06"
    },
    {
      "type": "WEB",
      "url": "https://www.samba.org/samba/security/CVE-2022-45141.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G664-59R4-4VFR

Vulnerability from github – Published: 2023-02-01 18:30 – Updated: 2023-02-08 21:30
VLAI
Details

IBM App Connect Enterprise Certified Container 4.1, 4.2, 5.0, 5.1, 5.2, 6.0, 6.1, and 6.2 could disclose sensitive information to an attacker due to a weak hash of an API Key in the configuration. IBM X-Force ID: 241583.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-43922"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-326",
      "CWE-328"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-01T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM App Connect Enterprise Certified Container 4.1, 4.2, 5.0, 5.1, 5.2, 6.0, 6.1, and 6.2 could disclose sensitive information to an attacker due to a weak hash of an API Key in the configuration. IBM X-Force ID: 241583.",
  "id": "GHSA-g664-59r4-4vfr",
  "modified": "2023-02-08T21:30:19Z",
  "published": "2023-02-01T18:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43922"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/241583"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6857807"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H929-FVVP-882C

Vulnerability from github – Published: 2023-09-20 15:30 – Updated: 2026-02-04 23:11
VLAI
Summary
Duplicate Advisory: EVE Seals Vault Key With SHA1 PCRs
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-wc42-fcjp-v8vq. This link is maintained to preserve external references.

Original Description

Vault Key Sealed With SHA1 PCRs

The measured boot solution implemented in EVE OS leans on a PCR locking mechanism.

Different parts of the system update different PCR values in the TPM, resulting in a unique value for each PCR entry.

These PCRs are then used in order to seal/unseal a key from the TPM which is used to encrypt/decrypt the “vault” directory.

This “vault” directory is the most sensitive point in the system and as such, its content should be protected.

This mechanism is noted in Zededa’s documentation as the “measured boot” mechanism, designed to protect said “vault”.

The code that’s responsible for generating and fetching the key from the TPM assumes that SHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being checked.

The issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs. This leads to several issues:

• Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well as not sealing their keys at all, meaning the “vault” is not protected from an attacker.

• SHA1 is considered insecure and reduces the complexity level required to unseal the key in machines which have their SHA1 PCRs enabled.

An attacker can very easily retrieve the contents of the “vault”, which will effectively render the “measured boot” mechanism meaningless.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lf-edge/eve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20230519072751-977f42b07fa9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-327",
      "CWE-328"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-04T23:11:53Z",
    "nvd_published_at": "2023-09-20T15:15:11Z",
    "severity": "HIGH"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-wc42-fcjp-v8vq. This link is maintained to preserve external references.\n\n### Original Description\nVault Key Sealed With SHA1 PCRs\n\n\n\n\n\n\nThe measured boot solution implemented in EVE OS leans on a PCR locking mechanism.\n\nDifferent parts of the system update different PCR values in the TPM, resulting in a unique\nvalue for each PCR entry.\n\nThese PCRs are then used in order to seal/unseal a key from the TPM which is used to\nencrypt/decrypt the \u201cvault\u201d directory.\n\nThis \u201cvault\u201d directory is the most sensitive point in the system and as such, its content should\nbe protected.\n\nThis mechanism is noted in Zededa\u2019s documentation as the \u201cmeasured boot\u201d mechanism,\ndesigned to protect said \u201cvault\u201d.\n\nThe code that\u2019s responsible for generating and fetching the key from the TPM assumes that\nSHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being\nchecked.\n\nThe issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.\nThis leads to several issues:\n\n\u2022 Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well\nas not sealing their keys at all, meaning the \u201cvault\u201d is not protected from an attacker.\n\n\u2022 SHA1 is considered insecure and reduces the complexity level required to unseal the\nkey in machines which have their SHA1 PCRs enabled.\n\n\n\nAn attacker can very easily retrieve the contents of the \u201cvault\u201d, which will effectively render\nthe \u201cmeasured boot\u201d mechanism meaningless.",
  "id": "GHSA-h929-fvvp-882c",
  "modified": "2026-02-04T23:11:53Z",
  "published": "2023-09-20T15:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43635"
    },
    {
      "type": "WEB",
      "url": "https://asrg.io/security-advisories/cve-2023-43635"
    },
    {
      "type": "WEB",
      "url": "https://asrg.io/security-advisories/vault-key-sealed-with-sha1-pcrs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: EVE Seals Vault Key With SHA1 PCRs",
  "withdrawn": "2026-02-04T23:11:53Z"
}

GHSA-HMWM-86JC-9M8G

Vulnerability from github – Published: 2025-05-27 09:30 – Updated: 2025-05-27 09:30
VLAI
Details

The devices are vulnerable to an authentication bypass due to flaws in the authorization mechanism. An unauthenticated remote attacker could exploit this weakness by performing brute-force attacks to guess valid credentials or by using MD5 collision techniques to forge authentication hashes, potentially compromising the device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-41652"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-328",
      "CWE-656"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-27T09:15:21Z",
    "severity": "CRITICAL"
  },
  "details": "The devices are vulnerable to an authentication bypass due to flaws in the authorization mechanism. An unauthenticated remote attacker could exploit this weakness by performing brute-force attacks to guess valid credentials or by using MD5 collision techniques to forge authentication hashes, potentially compromising the device.",
  "id": "GHSA-hmwm-86jc-9m8g",
  "modified": "2025-05-27T09:30:32Z",
  "published": "2025-05-27T09:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41652"
    },
    {
      "type": "WEB",
      "url": "https://certvde.com/en/advisories/VDE-2025-044"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
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.

← Back to the CWE list