CWE-328
AllowedUse 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-35M5-8CVJ-8783
Vulnerability from github – Published: 2021-11-10 16:28 – Updated: 2024-09-20 16:50Impact
The vulnerability is we used MD5 hashing Algorithm In our hashing file. If anyone who is a beginner(and doesn't know about hashes) can face problems as MD5 is considered a Insecure Hashing Algorithm.
Patches
The vulnerability is patched in v1.1.4 of the product, the users can upgrade to version 1.1.4.
Workarounds
If u specifically want a version and don't want to upgrade, you can remove the MD5 hashing function from the file hashing.py and this vulnerability will be gone
References
https://www.cybersecurity-help.cz/vdb/cwe/916/ https://www.cybersecurity-help.cz/vdb/cwe/327/ https://www.cybersecurity-help.cz/vdb/cwe/328/ https://www.section.io/engineering-education/what-is-md5/ https://www.johndcook.com/blog/2019/01/24/reversing-an-md5-hash/
For more information
If you have any questions or comments about this advisory: * Open an issue in Enrocrypt's Official Repo * Create a Discussion in Enrocrypt's Official Repo
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "enrocrypt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-39182"
],
"database_specific": {
"cwe_ids": [
"CWE-326",
"CWE-327",
"CWE-328",
"CWE-916"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-08T18:58:04Z",
"nvd_published_at": "2021-11-08T15:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nThe vulnerability is we used MD5 hashing Algorithm In our hashing file. If anyone who is a beginner(and doesn\u0027t know about hashes) can face problems as MD5 is considered a Insecure Hashing Algorithm. \n\n### Patches\nThe vulnerability is patched in v1.1.4 of the product, the users can upgrade to version 1.1.4.\n\n### Workarounds\nIf u specifically want a version and don\u0027t want to upgrade, you can remove the `MD5` hashing function from the file `hashing.py` and this vulnerability will be gone\n\n### References\nhttps://www.cybersecurity-help.cz/vdb/cwe/916/\nhttps://www.cybersecurity-help.cz/vdb/cwe/327/\nhttps://www.cybersecurity-help.cz/vdb/cwe/328/\nhttps://www.section.io/engineering-education/what-is-md5/\nhttps://www.johndcook.com/blog/2019/01/24/reversing-an-md5-hash/\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [**Enrocrypt\u0027s Official Repo**](http://www.github.com/Morgan-Phoenix/EnroCrypt)\n* Create a Discussion in [**Enrocrypt\u0027s Official Repo**](http://www.github.com/Morgan-Phoenix/EnroCrypt)\n",
"id": "GHSA-35m5-8cvj-8783",
"modified": "2024-09-20T16:50:32Z",
"published": "2021-11-10T16:28:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Morgan-Phoenix/EnroCrypt/security/advisories/GHSA-35m5-8cvj-8783"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39182"
},
{
"type": "WEB",
"url": "https://github.com/Morgan-Phoenix/EnroCrypt/commit/e652d56ac60eadfc26489ab83927af13a9b9d8ce"
},
{
"type": "PACKAGE",
"url": "https://github.com/Morgan-Phoenix/EnroCrypt"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/enrocrypt/PYSEC-2021-385.yaml"
}
],
"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"
},
{
"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": "Improper hashing in enrocrypt"
}
GHSA-39PV-4J6C-2G6V
Vulnerability from github – Published: 2026-06-15 17:24 – Updated: 2026-06-15 17:24Angular's HttpTransferCache caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in TransferState using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters).
The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions.
An attacker can easily find a query parameter string (e.g., q=aaCAZMMM for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., /api/user/profile). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the TransferState cache.
Impact
When the application attempts to retrieve the cached response for the sensitive endpoint (such as the user's profile), it receives the attacker-controlled response instead. This results in:
- State Poisoning: The application runs with attacker-forged data, which can lead to bypassing client-side security controls or DOM-based Cross-Site Scripting (XSS) if the data is rendered unsafely.
- Information Leakage: If the sensitive response is mistakenly associated with the attacker's search results and rendered on the page, the victim's sensitive data may be disclosed to the attacker.
Patched Versions
- 22.0.1
- 21.2.17
- 20.3.25
Framework-Level Fix
The logic has been updated to use a cryptographically secure SHA-256 hash algorithm for generating TransferState cache keys in HttpTransferCache. The cache keys are now 256-bit hexadecimal strings.
Workarounds
If you cannot upgrade immediately, configure your HttpClient requests to skip transfer caching for sensitive endpoints:
this.http.get('/api/user/profile', {
transferCache: false
});
Alternatively, disable the HTTP transfer cache globally in your application bootstrap config:
import { provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser';
export const appConfig = {
providers: [
provideClientHydration(
withNoHttpTransferCache()
)
]
};
Credits
This vulnerability was discovered and reported by CodeMender from Google DeepMind.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "22.0.0-next.0"
},
{
"fixed": "22.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "21.0.0-next.0"
},
{
"fixed": "21.2.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "20.0.0-next.0"
},
{
"fixed": "20.3.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "19.2.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54266"
],
"database_specific": {
"cwe_ids": [
"CWE-328",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T17:24:02Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Angular\u0027s `HttpTransferCache` caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in `TransferState` using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters).\n\nThe cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions.\n\nAn attacker can easily find a query parameter string (e.g., `q=aaCAZMMM` for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., `/api/user/profile`). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the `TransferState` cache.\n\n### Impact\n\nWhen the application attempts to retrieve the cached response for the sensitive endpoint (such as the user\u0027s profile), it receives the attacker-controlled response instead. This results in:\n\n* **State Poisoning**: The application runs with attacker-forged data, which can lead to bypassing client-side security controls or DOM-based Cross-Site Scripting (XSS) if the data is rendered unsafely. \n* **Information Leakage**: If the sensitive response is mistakenly associated with the attacker\u0027s search results and rendered on the page, the victim\u0027s sensitive data may be disclosed to the attacker.\n\n### Patched Versions\n* 22.0.1 \n* 21.2.17 \n* 20.3.25\n\n### Framework-Level Fix\n\nThe logic has been updated to use a cryptographically secure **SHA-256** hash algorithm for generating `TransferState` cache keys in `HttpTransferCache`. The cache keys are now 256-bit hexadecimal strings.\n\n### Workarounds\n\nIf you cannot upgrade immediately, configure your `HttpClient` requests to skip transfer caching for sensitive endpoints:\n\n```ts\nthis.http.get(\u0027/api/user/profile\u0027, {\n transferCache: false\n});\n```\n\nAlternatively, disable the HTTP transfer cache globally in your application bootstrap config:\n\n```ts\n\nimport { provideClientHydration, withNoHttpTransferCache } from \u0027@angular/platform-browser\u0027;\n\nexport const appConfig = {\n providers: [\n provideClientHydration(\n withNoHttpTransferCache()\n )\n ]\n};\n\n```\n\n### Credits\nThis vulnerability was discovered and reported by [CodeMender from Google DeepMind](https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/).",
"id": "GHSA-39pv-4j6c-2g6v",
"modified": "2026-06-15T17:24:02Z",
"published": "2026-06-15T17:24:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/angular/angular/security/advisories/GHSA-39pv-4j6c-2g6v"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/pull/69153"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/5f36274da3f961430ae72865159afa02a1dd9133"
},
{
"type": "PACKAGE",
"url": "https://github.com/angular/angular"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "@angular/common: Weak 32-Bit Cache Key Hashing in `HttpTransferCache` Leading to Cross-Request Data Leakage and State Poisoning"
}
GHSA-3G92-F9CH-QJCM
Vulnerability from github – Published: 2026-04-16 22:52 – Updated: 2026-04-16 22:52Vulnerability
Currently, when hashing, if the number of elements to hash is not a multiple of the rate, hash_iter pads by elements of
the current state. This means that it is possible to create iterators of different lengths which lead to an identical hashed state.
Given a simple example using a PaddingFreeSponge with width 8 and rate 4.
Start with the zero state: [0, 0, 0, 0, 0, 0, 0, 0]
Take the first 4 elements to hash and insert into the first 4 elements of the state: [h0, h1, h2, h3, 0, 0, 0, 0]
Run the cryptographic permutation on the state: [p00, p10, p20, p30, p40, p50, p60, p70]
Take the next 4 elements to hash and insert into the first 4 elements of the state: [h4, h5, h6, h7, p40, p50, p60, p70] Run the cryptographic permutation: [p01, p11, p21, p31, p41, p51, p61, p71]
Repeat the above two steps until all elements of the iterator have been consumed.
If the number of elements in the iterator is not a multiple of 4 (say there are 10 elements) then, in the final round, the first 2 elements are overwritten and so our final hash would be of: [h8, h9, p21, p31, p41, p51, p61, p71]
This means that the iterators over the elements [h0, h1, h2, h3, h4, h5, h6, h7, h8, h9] and [h0, h1, h2, h3, h4, h5, h6, h7, h8, h9, p21] would lead to the same final state of the hasher.
Impact
The impact of this vulnerability is a little difficult to estimate. It is important to note that, in circumstances where the number of elements to be hashed is known and fixed in advance, (as is the case for most STARKS), the method is collision resistant. This vulnerability only applies if a malicious user is able to manipulate the number of elements to be hashed.
That being said, there are theoretically situations where this could allow for an amortising of grinding costs (if a prover can manipulate things to get the same hasher state across multiple proofs).
Patches
The fix comes in two parts. The documentation on the current struct PaddingFreeSponge has been improved to clarify its intended use case and highlight that it is not collision resistant if an attacker can modify the number of elements being hashed.
In addition we add a new struct Pad10Sponge which is slightly less efficient but safe in all cases. The padding strategy of the new struct is as follows:
If the number of elements in the iterator is not a multiple of the rate, use a 10 padding scheme. If it is a multiple of the rate add 1 to the first secret state element. In the above example, for hashes of length 9, 10, 11, 12, the final state to be permuted would be [h8, 1, 0, 0, p41, p51, p61, p71] [h8, h9, 1, 0, p41, p51, p61, p71] [h8, h9, h10, 1, p41, p51, p61, p71] [h8, h9, h10, h11, p41 + 1, p51, p61, p71]
As can be seen, it is now impossible for iterators of different lengths to produce the same "final state" to be hashed which restores collision resistance. (See the following for more details padding-in-sponge.pdf)
Thanks
Many thanks to Benedikt Wagner, Dmitry Khovratovich and Bart Mennink for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "p3-symmetric"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-328"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T22:52:41Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Vulnerability\nCurrently, when hashing, if the number of elements to hash is not a multiple of the rate, `hash_iter` pads by elements of\nthe current state. This means that it is possible to create iterators of different lengths which lead to an identical hashed state.\n\nGiven a simple example using a `PaddingFreeSponge` with width 8 and rate 4.\nStart with the zero state: [0, 0, 0, 0, 0, 0, 0, 0]\nTake the first 4 elements to hash and insert into the first 4 elements of the state: [h0, h1, h2, h3, 0, 0, 0, 0]\nRun the cryptographic permutation on the state: [p00, p10, p20, p30, p40, p50, p60, p70]\n\nTake the next 4 elements to hash and insert into the first 4 elements of the state: [h4, h5, h6, h7, p40, p50, p60, p70]\nRun the cryptographic permutation: [p01, p11, p21, p31, p41, p51, p61, p71]\n\nRepeat the above two steps until all elements of the iterator have been consumed.\n\nIf the number of elements in the iterator is not a multiple of 4 (say there are 10 elements) then, in the final round,\nthe first 2 elements are overwritten and so our final hash would be of: [h8, h9, p21, p31, p41, p51, p61, p71]\n\nThis means that the iterators over the elements [h0, h1, h2, h3, h4, h5, h6, h7, h8, h9] and [h0, h1, h2, h3, h4, h5, h6, h7, h8, h9, p21] would lead to the same final state of the hasher.\n\n### Impact\n\nThe impact of this vulnerability is a little difficult to estimate. It is important to note that, in circumstances where the number of elements to be hashed is known and fixed in advance, (as is the case for most STARKS), the method is collision resistant. This vulnerability only applies if a malicious user is able to manipulate the number of elements to be hashed.\n\nThat being said, there are theoretically situations where this could allow for an amortising of grinding costs (if a prover can manipulate things to get the same hasher state across multiple proofs).\n\n### Patches\n\nThe fix comes in two parts. The documentation on the current struct `PaddingFreeSponge` has been improved to clarify its intended use case and highlight that it is not collision resistant if an attacker can modify the number of elements being hashed.\n\nIn addition we add a new struct `Pad10Sponge` which is slightly less efficient but safe in all cases. The padding strategy of the new struct is as follows:\n\nIf the number of elements in the iterator is not a multiple of the rate, use a 10 padding scheme. If it is a multiple of the rate add 1 to the first secret state element. In the above example, for hashes of length 9, 10, 11, 12, the final state to be permuted would be\n[h8, 1, 0, 0, p41, p51, p61, p71]\n[h8, h9, 1, 0, p41, p51, p61, p71]\n[h8, h9, h10, 1, p41, p51, p61, p71]\n[h8, h9, h10, h11, p41 + 1, p51, p61, p71]\n\nAs can be seen, it is now impossible for iterators of different lengths to produce the same \"final state\" to be hashed which restores collision resistance. (See the following for more details [padding-in-sponge.pdf](https://github.com/user-attachments/files/24465342/padding-in-sponge.pdf))\n\n### Thanks\nMany thanks to Benedikt Wagner, Dmitry Khovratovich and Bart Mennink for reporting this issue.",
"id": "GHSA-3g92-f9ch-qjcm",
"modified": "2026-04-16T22:52:41Z",
"published": "2026-04-16T22:52:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Plonky3/Plonky3/security/advisories/GHSA-3g92-f9ch-qjcm"
},
{
"type": "WEB",
"url": "https://github.com/Plonky3/Plonky3/commit/5c1dc1d64c0516a8911bbf3ea40f173c21d6ae47"
},
{
"type": "PACKAGE",
"url": "https://github.com/Plonky3/Plonky3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Plonky3: The sponge construction used to get a hash function from a cryptographic permutation is not collision resistant for inputs of different lengths"
}
GHSA-48VQ-44VM-P326
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-07 21:30All versions of Econolite EOS traffic control software are vulnerable to CWE-328: Use of Weak Hash, and use a weak hash algorithm for encrypting privileged user credentials. A configuration file that is accessible without authentication uses MD5 hashes for encrypting credentials, including those of administrators and technicians.
{
"affected": [],
"aliases": [
"CVE-2023-0452"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-328"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-26T21:18:00Z",
"severity": "MODERATE"
},
"details": "All versions of Econolite EOS traffic control software are vulnerable to CWE-328: Use of Weak Hash, and use a weak hash algorithm for encrypting privileged user credentials. A configuration file that is accessible without authentication uses MD5 hashes for encrypting credentials, including those of administrators and technicians.",
"id": "GHSA-48vq-44vm-p326",
"modified": "2023-02-07T21:30:24Z",
"published": "2023-01-26T21:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0452"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-23-026-02"
}
],
"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-4JVR-VJ2C-8Q37
Vulnerability from github – Published: 2026-02-04 23:12 – Updated: 2026-02-04 23:12Impact
The vault key is sealed using SHA1 PCRs instead of SHA256 PCRs
Thus an attacker with physical access to an EVE-OS device can try to brute force creating a kernel or rootfs image which produces the same SHA1 PCR but with malicious content.
Patches
Fixed in 9.4.3-lts and 10.1.0
Workarounds
None
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lf-edge/eve"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20230519072751-977f42b07fa9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-43635"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-328",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-04T23:12:29Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThe vault key is sealed using SHA1 PCRs instead of SHA256 PCRs\n\nThus an attacker with physical access to an EVE-OS device can try to brute force creating a kernel or rootfs image which produces the same SHA1 PCR but with malicious content.\n\n### Patches\n\nFixed in 9.4.3-lts and 10.1.0\n\n### Workarounds\n\nNone",
"id": "GHSA-4jvr-vj2c-8q37",
"modified": "2026-02-04T23:12:29Z",
"published": "2026-02-04T23:12:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lf-edge/eve/security/advisories/GHSA-4jvr-vj2c-8q37"
},
{
"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"
},
{
"type": "PACKAGE",
"url": "https://github.com/lf-edge/eve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "EVE Seals Vault Key With SHA1 PCRs"
}
GHSA-4QM4-8HG2-G2XM
Vulnerability from github – Published: 2024-10-17 19:30 – Updated: 2024-10-18 16:23Impact
When this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions, leading to large CPU consumption disproportionate to the size of the data being deserialized.
This is similar to a prior advisory, which provided an inadequate fix for the hash collision part of the vulnerability.
Patches
The following steps are required to mitigate this risk.
- Upgrade to a version of the library where a fix is available. If upgrading from v1, check out our migration guide.
- Review the steps in this previous advisory to ensure you have your application configured for untrusted data.
Workarounds
If upgrading MessagePack to a patched version is not an option for you, you may apply a manual workaround as follows:
- Declare a class that derives from
MessagePackSecurity. - Override the
GetHashCollisionResistantEqualityComparer<T>method to provide a collision-resistant hash function of your own and avoid callingbase.GetHashCollisionResistantEqualityComparer<T>(). - Configure a
MessagePackSerializerOptionswith an instance of your derived type by callingWithSecurityon an existing options object. - Use your custom options object for all deserialization operations. This may be by setting the
MessagePackSerializer.DefaultOptionsstatic property, if you call methods that rely on this default property, and/or by passing in the options object explicitly to anyDeserializemethod.
References
- Learn more about best security practices when reading untrusted data with MessagePack 1.x or MessagePack 2.x.
- The .NET team's discussion on hash collision vulnerabilities of their
HashCodestruct (or in the pull request that merges this into the dotnet org).
For more information
If you have any questions or comments about this advisory:
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "MessagePack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.5.187"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "MessagePack"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.95-alpha"
},
{
"fixed": "3.0.214-rc.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-48924"
],
"database_specific": {
"cwe_ids": [
"CWE-328"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-17T19:30:03Z",
"nvd_published_at": "2024-10-17T21:15:14Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions, leading to large CPU consumption disproportionate to the size of the data being deserialized.\n\nThis is similar to [a prior advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf), which provided an inadequate fix for the hash collision part of the vulnerability.\n\n### Patches\n\nThe following steps are required to mitigate this risk.\n\n1. Upgrade to a version of the library where a fix is available. If upgrading from v1, check out [our migration guide](https://github.com/MessagePack-CSharp/MessagePack-CSharp/blob/master/doc/migration.md).\n1. Review the steps in [this previous advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf) to ensure you have your application configured for untrusted data.\n\n### Workarounds\n\nIf upgrading MessagePack to a patched version is not an option for you, you may apply a manual workaround as follows:\n\n1. Declare a class that derives from `MessagePackSecurity`.\n2. Override the `GetHashCollisionResistantEqualityComparer\u003cT\u003e` method to provide a collision-resistant hash function of your own and avoid calling `base.GetHashCollisionResistantEqualityComparer\u003cT\u003e()`.\n3. Configure a `MessagePackSerializerOptions` with an instance of your derived type by calling `WithSecurity` on an existing options object.\n4. Use your custom options object for all deserialization operations. This may be by setting the `MessagePackSerializer.DefaultOptions` static property, if you call methods that rely on this default property, and/or by passing in the options object explicitly to any `Deserialize` method.\n\n### References\n\n- Learn more about best security practices when reading untrusted data with [MessagePack 1.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp/tree/v1.x#security) or [MessagePack 2.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp#security).\n- The .NET team\u0027s [discussion on hash collision vulnerabilities of their `HashCode` struct](https://github.com/GrabYourPitchforks/runtime/blob/threat_models/docs/design/security/System.HashCode.md) (or in [the pull request that merges this into the dotnet org](https://github.com/dotnet/runtime/pull/108864)).\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* [Start a public discussion](https://github.com/MessagePack-CSharp/MessagePack-CSharp/discussions)\n* [Email us privately](mailto:andrewarnott@live.com)",
"id": "GHSA-4qm4-8hg2-g2xm",
"modified": "2024-10-18T16:23:37Z",
"published": "2024-10-17T19:30:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-4qm4-8hg2-g2xm"
},
{
"type": "PACKAGE",
"url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "MessagePack allows untrusted data to lead to DoS attack due to hash collisions and stack overflow"
}
GHSA-58FG-62FG-3FCJ
Vulnerability from github – Published: 2026-06-23 22:02 – Updated: 2026-06-23 22:02Summary
Attachment passwords are hashed using SHA-1, a cryptographically broken algorithm. SHA-1 has been vulnerable to collision attacks since 2017 (SHAttered).
Details
Affected File : phpmyfaq/src/phpMyFAQ/Attachment/AbstractAttachment.php
Impact
- An attacker can generate SHA-1 collisions to bypass attachment protection
- Risk of password cracking if database is compromised
- Estimated cracking time: < 1 minute for standard attachment
Solution
Use bcrypt:
public function setPassword(string $password): void
{
$this->passwordHash = password_hash($password, PASSWORD_BCRYPT);
}
public function verifyPassword(string $plainPassword): bool
{
return password_verify($plainPassword, $this->passwordHash);
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.3"
},
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.3"
},
"package": {
"ecosystem": "Packagist",
"name": "phpmyfaq/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48488"
],
"database_specific": {
"cwe_ids": [
"CWE-328"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T22:02:25Z",
"nvd_published_at": "2026-06-08T16:16:43Z",
"severity": "LOW"
},
"details": "### Summary\n\nAttachment passwords are hashed using SHA-1, a cryptographically broken algorithm. SHA-1 has been vulnerable to collision attacks since 2017 (SHAttered).\n\n### Details\n\n**Affected File** : `phpmyfaq/src/phpMyFAQ/Attachment/AbstractAttachment.php`\n\n\u003cimg width=\"810\" height=\"427\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6499a008-3ece-4291-8296-f1d3303ba35c\" /\u003e\n\n\n### Impact\n\n- An attacker can generate SHA-1 collisions to bypass attachment protection\n- Risk of password cracking if database is compromised\n- Estimated cracking time: \u003c 1 minute for standard attachment\n\n### Solution\n\n**Use bcrypt:**\n\n```\npublic function setPassword(string $password): void\n{\n $this-\u003epasswordHash = password_hash($password, PASSWORD_BCRYPT);\n}\n\npublic function verifyPassword(string $plainPassword): bool\n{\n return password_verify($plainPassword, $this-\u003epasswordHash);\n}\n```",
"id": "GHSA-58fg-62fg-3fcj",
"modified": "2026-06-23T22:02:25Z",
"published": "2026-06-23T22:02:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-58fg-62fg-3fcj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48488"
},
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/commit/1aa9be6f8a2fa5c527c983826205229fc3129718"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "phpMyFAQ has Weak Cryptography - SHA1 for Password Hashing"
}
GHSA-58QF-7XXX-PW82
Vulnerability from github – Published: 2024-05-01 18:30 – Updated: 2024-07-03 18:38An issue in LOGINT LoMag Inventory Management v1.0.20.120 and before allows a local attacker to obtain sensitive information via the UserClass.cs and Settings.cs components.
{
"affected": [],
"aliases": [
"CVE-2024-32211"
],
"database_specific": {
"cwe_ids": [
"CWE-328",
"CWE-922"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T18:15:23Z",
"severity": "MODERATE"
},
"details": "An issue in LOGINT LoMag Inventory Management v1.0.20.120 and before allows a local attacker to obtain sensitive information via the UserClass.cs and Settings.cs components.",
"id": "GHSA-58qf-7xxx-pw82",
"modified": "2024-07-03T18:38:15Z",
"published": "2024-05-01T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32211"
},
{
"type": "WEB",
"url": "https://gainsec.com/2024/04/28/cve-2024-32210-cve-2024-32211-cve-2024-32212-cve-2024-32213-lomag-integrator-ce-warehouse-management"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5JVG-8J6F-VPMC
Vulnerability from github – Published: 2023-09-20 15:30 – Updated: 2026-02-04 20:43Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-phcg-h58r-gmcq. This link is maintained to preserve external references.
Original Description
PCR14 is not in the list of PCRs that seal/unseal the “vault” key, but due to the change that was implemented in commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, fixing this issue alone would not solve the problem of the config partition not being measured correctly.
Also, the “vault” key is sealed/unsealed with SHA1 PCRs instead of SHA256. This issue was somewhat mitigated due to all of the PCR extend functions updating both the values of SHA256 and SHA1 for a given PCR ID.
However, due to the change that was implemented in commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, this is no longer the case for PCR14, as the code in “measurefs.go” explicitly updates only the SHA256 instance of PCR14, which means that even if PCR14 were to be added to the list of PCRs sealing/unsealing the “vault” key, changes to the config partition would still not be measured.
An attacker could modify the config partition without triggering the measured boot, this could result in the attacker gaining full control over the device with full access to the contents of the encrypted “vault”
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lf-edge/eve"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20230126065759-d9383a7ee4e1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-328",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-04T20:43:08Z",
"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-phcg-h58r-gmcq. This link is maintained to preserve external references.\n\n### Original Description\nPCR14 is not in the list of PCRs that seal/unseal the \u201cvault\u201d key, but\ndue to the change that was implemented in commit\n\u201c7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4\u201d, fixing this issue alone would not solve the\nproblem of the config partition not being measured correctly.\n\nAlso, the \u201cvault\u201d key is sealed/unsealed with SHA1 PCRs instead of\nSHA256. \nThis issue was somewhat mitigated due to all of the PCR extend functions\nupdating both the values of SHA256 and SHA1 for a given PCR ID.\n\nHowever, due to the change that was implemented in commit\n\u201c7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4\u201d, this is no longer the case for PCR14, as\nthe code in \u201cmeasurefs.go\u201d explicitly updates only the SHA256 instance of PCR14, which\nmeans that even if PCR14 were to be added to the list of PCRs sealing/unsealing the \u201cvault\u201d\nkey, changes to the config partition would still not be measured.\n\n\n\nAn attacker could modify the config partition without triggering the measured boot, this could\nresult in the attacker gaining full control over the device with full access to the contents of the\nencrypted \u201cvault\u201d",
"id": "GHSA-5jvg-8j6f-vpmc",
"modified": "2026-02-04T20:43:09Z",
"published": "2023-09-20T15:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43630"
},
{
"type": "WEB",
"url": "https://asrg.io/security-advisories/config-partition-not-measured-from-2-fronts"
},
{
"type": "WEB",
"url": "https://asrg.io/security-advisories/cve-2023-43630"
}
],
"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 Doesn\u0027t Measure Config Partition From 2 Fronts",
"withdrawn": "2026-02-04T20:43:08Z"
}
GHSA-5VFC-FCP9-H5Q8
Vulnerability from github – Published: 2024-09-30 09:30 – Updated: 2024-09-30 09:30Certain switch models from PLANET Technology use an insecure hashing function to hash user passwords without being salted. Remote attackers with administrator privileges can read configuration files to obtain the hash values, and potentially crack them to retrieve the plaintext passwords.
{
"affected": [],
"aliases": [
"CVE-2024-8453"
],
"database_specific": {
"cwe_ids": [
"CWE-328"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-30T08:15:04Z",
"severity": "MODERATE"
},
"details": "Certain switch models from PLANET Technology use an insecure hashing function to hash user passwords without being salted. Remote attackers with administrator privileges can read configuration files to obtain the hash values, and potentially crack them to retrieve the plaintext passwords.",
"id": "GHSA-5vfc-fcp9-h5q8",
"modified": "2024-09-30T09:30:47Z",
"published": "2024-09-30T09:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8453"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-8056-09688-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-8055-2c361-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-51
- 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.