CWE-334
AllowedSmall Space of Random Values
Abstraction: Base · Status: Draft
The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.
25 vulnerabilities reference this CWE, most recent first.
GHSA-J9H7-V335-8GCP
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2026-05-29 21:31A CWE-334: Small Space of Random Values vulnerability exists in Modicon M221 (all references, all versions) that could allow the attacker to break the encryption keys when the attacker has captured the traffic between EcoStruxure Machine - Basic software and Modicon M221 controller.
{
"affected": [],
"aliases": [
"CVE-2020-7566"
],
"database_specific": {
"cwe_ids": [
"CWE-334"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-19T22:15:00Z",
"severity": "HIGH"
},
"details": "A CWE-334: Small Space of Random Values vulnerability exists in Modicon M221 (all references, all versions) that could allow the attacker to break the encryption keys when the attacker has captured the traffic between EcoStruxure Machine - Basic software and Modicon M221 controller.",
"id": "GHSA-j9h7-v335-8gcp",
"modified": "2026-05-29T21:31:15Z",
"published": "2022-05-24T17:34:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7566"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-20-343-04"
},
{
"type": "WEB",
"url": "https://www.se.com/ww/en/download/document/SEVD-2020-315-05"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JP37-5QHW-MFFW
Vulnerability from github – Published: 2024-11-18 20:03 – Updated: 2024-11-18 20:03Affected versions of this crate allowed for a bias when generating random polynomials for Shamir Secret Sharing, where instead of being within the range [0, 255] they were instead in the range [1, 255]. A description from Cure53, who originally found the issue, is available:
The correct method to select a random polynomial would be to select all coefficients (including the most significant coefficient) uniformly in the range 0..255 (inclusive). Otherwise, knowledge that a coefficient in a polynomial cannot be 0 permits the exclusion of single byte values for the shared secret given one share less than required. [...] Exploiting this weakness necessitates sharing the same secret multiple times. In this scenario, an attacker could exclude an exponential number of values for each of the shared bytes until sufficiently few values remain for brute forcing. Cure53 estimates that under ideal circumstances (e.g., a 2-out-of-N scheme) a shared secret can be reconstructed if the same secret has been distributed 500-1500 times.
Secrets that have been shared a low amount of times (ideally, once) would not be impacted. However, secrets that are repeatedly shared may be vulnerable, especially if the shares are still available, and should be rotated.
The vulnerability does not impact reconstitution of secrets: secrets that have already been split can be recombined without issue.
The flaw can be corrected by changing the lower bound of the polynomial coefficient range in the sharks::math::random_polynomial function to 0. The blahaj crate has been made available with a fixed version of the code, after attempts to reach the maintainer of the sharks crate were unsuccessful.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "sharks"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-334"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-18T20:03:25Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Affected versions of this crate allowed for a bias when generating random polynomials for Shamir Secret Sharing, where instead of being within the range `[0, 255]` they were instead in the range `[1, 255]`. A description from Cure53, who originally found the issue, is available:\n\n\u003e The correct method to select a random polynomial would be to select all coefficients (including the most significant coefficient) uniformly in the range 0..255 (inclusive). Otherwise, knowledge that a coefficient in a polynomial cannot be 0 permits the exclusion of single byte values for the shared secret given one share less than required. [...] Exploiting this weakness necessitates sharing the same secret multiple times. In this scenario, an attacker could exclude an exponential number of values for each of the shared bytes until sufficiently few values remain for brute forcing. Cure53 estimates that under ideal circumstances (e.g., a 2-out-of-N scheme) a shared secret can be reconstructed if the same secret has been distributed 500-1500 times.\n\nSecrets that have been shared a low amount of times (ideally, once) would not be impacted. However, secrets that are repeatedly shared may be vulnerable, especially if the shares are still available, and should be rotated.\n\nThe vulnerability does not impact reconstitution of secrets: secrets that have already been split can be recombined without issue.\n\nThe flaw can be corrected by changing the lower bound of the polynomial coefficient range in the `sharks::math::random_polynomial` function to `0`. The `blahaj` crate has been made available with a fixed version of the code, after attempts to reach the maintainer of the `sharks` crate were unsuccessful.\n",
"id": "GHSA-jp37-5qhw-mffw",
"modified": "2024-11-18T20:03:25Z",
"published": "2024-11-18T20:03:25Z",
"references": [
{
"type": "WEB",
"url": "https://git.distrust.co/public/blahaj/commit/4faab1cd33d455f0ca2ccc7208093fd6c18e0767"
},
{
"type": "PACKAGE",
"url": "https://github.com/c0dearm/sharks"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0398.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Sharks has a Bias of Polynomial Coefficients in Secret Sharing"
}
GHSA-RG76-677X-56Q9
Vulnerability from github – Published: 2026-08-07 18:48 – Updated: 2026-08-07 18:48Summary
CryptoJS.lib.WordArray.random() in affected versions is not a cryptographically secure random number generator. Nominal requests for 128 or 256 bits of entropy produce effective search spaces of approximately 2^39 and 2^47 possibilities — small enough to enumerate on commodity hardware.
Coinspect's Ill Bloom investigation confirmed that downstream wallet applications used this function as the entropy source for BIP39 recovery phrases.
An application is affected only if it uses the vulnerable function to generate security-sensitive values.
Merely depending on crypto-js < 4.0.0 is not sufficient to be exploitable.
Details
The affected implementation used a custom variation of George Marsaglia's Multiply-With-Carry PRNG, seeded from Math.random(). It was introduced in 3.1.2-4 (June 2014, commit brix/crypto-js@ff1f003) in response to issue #7, and was present in every 3.x release except 3.2.0 and 3.2.1. That change was reverted in 3.3.0 because it was considered a breaking change, so projects tracking the 3.x line could resolve to newer versions that still contained the weak generator.
4.0.0 replaced the generator with the platform's native cryptographic API.
Applying PBKDF2, another KDF, or a cryptographic hash after the vulnerable generator does not restore missing entropy.
Proof of concept
Coinspect reproduced the attack end to end:
- Reimplemented the affected
WordArray.random()behavior. - Enumerated the feasible outputs of the underlying PRNG.
- Converted candidate entropy values into valid BIP39 recovery phrases.
- Derived private keys and addresses across the relevant derivation paths and networks.
- Compared derived addresses against public blockchain data.
- Recovered the private keys controlling funded addresses.
Impact
An attacker can enumerate the reduced output space and recover security-sensitive values generated through the affected function.
Coinspect documented coordinated drain waves affecting addresses derived from vulnerable recovery phrases. As of July 13, 2026, the measured lower bound of stolen assets across the two events was approximately $5M.
The consequences are persistent:
- Updating an affected library or wallet does not strengthen a previously generated secret.
- Importing the same recovery phrase into an updated software or hardware wallet does not remediate the issue.
- Previously generated secrets may remain exploitable indefinitely.
- Future deposits to an affected address may also be stolen.
- Assets may remain exposed across networks or derivation paths that have not yet shown suspicious activity.
Remediation
For projects:
- Upgrade
crypto-jsto version4.0.0or later. Where possible, replace CryptoJS randomness with the native Web Crypto API or Node.jscryptomodule. - Audit direct, downstream, and transitive dependencies for versions of
crypto-jsmatching< 4.0.0. - Determine whether
CryptoJS.lib.WordArray.random()was used to generate any security-sensitive values. - Identify the time periods and application versions during which the vulnerable generation path was present.
- Treat all long-term secrets generated through an affected path as compromised and rotate them.
- Notify affected users that installing an update is insufficient when a long-term secret was generated by the vulnerable code.
For wallet users: create a new wallet with a newly generated recovery phrase from a trustworthy source and migrate assets to addresses derived from it. Do not import the existing recovery phrase into the new wallet.
Public address checker
Coinspect provides a public checker for addresses identified in the known Ill Bloom exposed-address datasets:
Only public blockchain addresses should be entered. Users must never enter a recovery phrase, seed phrase, mnemonic, private key, password, or wallet backup file.
A match indicates that funds controlled by the same recovery phrase may be at immediate risk. A negative result only means that the submitted address was not found in the currently published datasets.
References
- Ill Bloom research site and public address checker:
https://illbloom.org/ - Coinspect investigation overview:
https://www.coinspect.com/blog/ill-bloom-investigation/ - CryptoJS issue #7 —
randomBytes is not random enough:
https://github.com/brix/crypto-js/issues/7 - Commit introducing the MWC-based implementation:
https://github.com/brix/crypto-js/commit/ff1f0032ff58aedfcc44eb6aa7b2c78207a98009 - Changes between CryptoJS
3.3.0and4.0.0:
https://github.com/brix/crypto-js/compare/3.3.0...4.0.0 - Downstream
ferrumnet/bip39fork:
https://github.com/ferrumnet/bip39
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "crypto-js"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71851"
],
"database_specific": {
"cwe_ids": [
"CWE-331",
"CWE-334",
"CWE-338"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-07T18:48:59Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\n\n`CryptoJS.lib.WordArray.random()` in affected versions is not a cryptographically secure random number generator. Nominal requests for 128 or 256 bits of entropy produce effective search spaces of approximately 2^39 and 2^47 possibilities \u2014 small enough to enumerate on commodity hardware.\n\nCoinspect\u0027s [Ill Bloom](https://www.coinspect.com/blog/ill-bloom-investigation/) investigation confirmed that downstream wallet applications used this function as the entropy source for BIP39 recovery phrases.\n\n**An application is affected only if it uses the vulnerable function to generate security-sensitive values.** \n\nMerely depending on `crypto-js \u003c 4.0.0` is not sufficient to be exploitable.\n\n### Details\n\nThe affected implementation used a custom variation of George Marsaglia\u0027s Multiply-With-Carry PRNG, seeded from `Math.random()`. It was introduced in 3.1.2-4 (June 2014, commit brix/crypto-js@ff1f003) in response to issue \\#7, and was present in every 3.x release except 3.2.0 and 3.2.1. That **change was reverted in 3.3.0** because it was considered a breaking change, so projects tracking the 3.x line could resolve to newer versions that still contained the weak generator. \n\n4.0.0 replaced the generator with the platform\u0027s native cryptographic API.\n\nApplying PBKDF2, another KDF, or a cryptographic hash after the vulnerable generator does not restore missing entropy.\n\n### Proof of concept\n\nCoinspect reproduced the attack end to end:\n\n1. Reimplemented the affected `WordArray.random()` behavior. \n2. Enumerated the feasible outputs of the underlying PRNG. \n3. Converted candidate entropy values into valid BIP39 recovery phrases. \n4. Derived private keys and addresses across the relevant derivation paths and networks. \n5. Compared derived addresses against public blockchain data. \n6. Recovered the private keys controlling funded addresses.\n\n### Impact\n\nAn attacker can enumerate the reduced output space and recover security-sensitive values generated through the affected function.\n\nCoinspect documented coordinated drain waves affecting addresses derived from vulnerable recovery phrases. As of July 13, 2026, the measured lower bound of stolen assets across the two events was approximately $5M.\n\nThe consequences are persistent:\n\n* Updating an affected library or wallet does not strengthen a previously generated secret. \n* Importing the same recovery phrase into an updated software or hardware wallet does not remediate the issue. \n* Previously generated secrets may remain exploitable indefinitely. \n* Future deposits to an affected address may also be stolen. \n* Assets may remain exposed across networks or derivation paths that have not yet shown suspicious activity.\n\n### Remediation\n\n**For projects:**\n\n1. Upgrade `crypto-js` to version `4.0.0` or later. Where possible, replace CryptoJS randomness with the native Web Crypto API or Node.js `crypto` module. \n2. Audit direct, downstream, and transitive dependencies for versions of `crypto-js` matching `\u003c 4.0.0`. \n3. Determine whether `CryptoJS.lib.WordArray.random()` was used to generate any security-sensitive values. \n4. Identify the time periods and application versions during which the vulnerable generation path was present. \n5. Treat all long-term secrets generated through an affected path as compromised and rotate them. \n6. Notify affected users that installing an update is insufficient when a long-term secret was generated by the vulnerable code.\n\n**For wallet users:** create a new wallet with a newly generated recovery phrase from a trustworthy source and migrate assets to addresses derived from it. Do not import the existing recovery phrase into the new wallet.\n\n### Public address checker\n\nCoinspect provides a public checker for addresses identified in the known Ill Bloom exposed-address datasets:\n\n[https://illbloom.org/](https://illbloom.org/)\n\nOnly public blockchain addresses should be entered. Users must **never enter a recovery phrase**, seed phrase, mnemonic, private key, password, or wallet backup file.\n\nA match indicates that funds controlled by the same recovery phrase may be at immediate risk. A negative result only means that the submitted address was not found in the currently published datasets.\n\n### References\n\n* Ill Bloom research site and public address checker: \n [https://illbloom.org/](https://illbloom.org/) \n* Coinspect investigation overview: \n [https://www.coinspect.com/blog/ill-bloom-investigation/](https://www.coinspect.com/blog/ill-bloom-investigation/) \n* CryptoJS issue \\#7 \u2014 `randomBytes is not random enough`: \n [https://github.com/brix/crypto-js/issues/7](https://github.com/brix/crypto-js/issues/7) \n* Commit introducing the MWC-based implementation: \n [https://github.com/brix/crypto-js/commit/ff1f0032ff58aedfcc44eb6aa7b2c78207a98009](https://github.com/brix/crypto-js/commit/ff1f0032ff58aedfcc44eb6aa7b2c78207a98009) \n* Changes between CryptoJS `3.3.0` and `4.0.0`: \n [https://github.com/brix/crypto-js/compare/3.3.0...4.0.0](https://github.com/brix/crypto-js/compare/3.3.0...4.0.0) \n* Downstream `ferrumnet/bip39` fork: \n [https://github.com/ferrumnet/bip39](https://github.com/ferrumnet/bip39)",
"id": "GHSA-rg76-677x-56q9",
"modified": "2026-08-07T18:48:59Z",
"published": "2026-08-07T18:48:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/brix/crypto-js/security/advisories/GHSA-rg76-677x-56q9"
},
{
"type": "WEB",
"url": "https://github.com/brix/crypto-js/commit/b405ff597fb3ac76a7bdfbc72dca10ba1079b1d5"
},
{
"type": "PACKAGE",
"url": "https://github.com/brix/crypto-js"
},
{
"type": "WEB",
"url": "https://www.coinspect.com/blog/ill-bloom-investigation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "crypto-js: Insufficient Entropy in Cryptographic Secret Generation via Vulnerable CryptoJS Dependency Chain"
}
GHSA-VV74-P9WH-MPF3
Vulnerability from github – Published: 2023-09-02 15:30 – Updated: 2024-04-04 07:22There is a vulnerability in MXsecurity versions prior to 1.0.1 that can be exploited to bypass authentication. A remote attacker might access the system if the web service authenticator has insufficient random values.
{
"affected": [],
"aliases": [
"CVE-2023-39979"
],
"database_specific": {
"cwe_ids": [
"CWE-330",
"CWE-334"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-02T13:15:44Z",
"severity": "CRITICAL"
},
"details": "There is a vulnerability in MXsecurity versions prior to 1.0.1 that can be exploited to bypass authentication. A remote attacker might access the system if the web service authenticator has insufficient random values.\u00a0\u00a0\n\n",
"id": "GHSA-vv74-p9wh-mpf3",
"modified": "2024-04-04T07:22:18Z",
"published": "2023-09-02T15:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39979"
},
{
"type": "WEB",
"url": "https://www.moxa.com/en/support/product-support/security-advisory/mpsa-230403-mxsecurity-series-multiple-vulnerabilities"
}
],
"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-WV47-QQCP-W8J2
Vulnerability from github – Published: 2026-05-12 12:32 – Updated: 2026-05-12 12:32A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V11.0), SIPROTEC 5 6MD85 (CP200) (All versions), SIPROTEC 5 6MD85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 6MD86 (CP200) (All versions), SIPROTEC 5 6MD86 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 6MD89 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 6MU85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7KE85 (CP200) (All versions), SIPROTEC 5 7KE85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SA82 (CP100) (All versions >= V7.80), SIPROTEC 5 7SA82 (CP150) (All versions < V11.0), SIPROTEC 5 7SA84 (CP200) (All versions), SIPROTEC 5 7SA86 (CP200) (All versions), SIPROTEC 5 7SA86 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SA87 (CP200) (All versions), SIPROTEC 5 7SA87 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SD82 (CP100) (All versions >= V7.80), SIPROTEC 5 7SD82 (CP150) (All versions < V11.0), SIPROTEC 5 7SD84 (CP200) (All versions), SIPROTEC 5 7SD86 (CP200) (All versions), SIPROTEC 5 7SD86 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SD87 (CP200) (All versions), SIPROTEC 5 7SD87 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SJ81 (CP100) (All versions >= V7.80), SIPROTEC 5 7SJ81 (CP150) (All versions < V11.0), SIPROTEC 5 7SJ82 (CP100) (All versions >= V7.80), SIPROTEC 5 7SJ82 (CP150) (All versions < V11.0), SIPROTEC 5 7SJ85 (CP200) (All versions), SIPROTEC 5 7SJ85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SJ86 (CP200) (All versions), SIPROTEC 5 7SJ86 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SK82 (CP100) (All versions >= V7.80), SIPROTEC 5 7SK82 (CP150) (All versions < V11.0), SIPROTEC 5 7SK85 (CP200) (All versions), SIPROTEC 5 7SK85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SL82 (CP100) (All versions >= V7.80), SIPROTEC 5 7SL82 (CP150) (All versions < V11.0), SIPROTEC 5 7SL86 (CP200) (All versions), SIPROTEC 5 7SL86 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SL87 (CP200) (All versions), SIPROTEC 5 7SL87 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7SS85 (CP200) (All versions), SIPROTEC 5 7SS85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7ST85 (CP200) (All versions), SIPROTEC 5 7ST85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7ST86 (CP300) (All versions < V11.0), SIPROTEC 5 7SX82 (CP150) (All versions < V11.0), SIPROTEC 5 7SX85 (CP300) (All versions < V11.0), SIPROTEC 5 7SY82 (CP150) (All versions < V11.0), SIPROTEC 5 7UM85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7UT82 (CP100) (All versions >= V7.80), SIPROTEC 5 7UT82 (CP150) (All versions < V11.0), SIPROTEC 5 7UT85 (CP200) (All versions), SIPROTEC 5 7UT85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7UT86 (CP200) (All versions), SIPROTEC 5 7UT86 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7UT87 (CP200) (All versions), SIPROTEC 5 7UT87 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7VE85 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7VK87 (CP200) (All versions), SIPROTEC 5 7VK87 (CP300) (All versions >= V7.80 < V11.0), SIPROTEC 5 7VU85 (CP300) (All versions < V11.0), SIPROTEC 5 Compact 7SX800 (CP050) (All versions < V11.0). Affected devices do not use sufficiently random values to create session identifiers. This could allow an unauthenticated remote attacker to brute force a session identifier and gain read access to limited information from the web server without authorization.
{
"affected": [],
"aliases": [
"CVE-2024-54017"
],
"database_specific": {
"cwe_ids": [
"CWE-334"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-12T10:16:40Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions \u003c V11.0), SIPROTEC 5 6MD85 (CP200) (All versions), SIPROTEC 5 6MD85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 6MD86 (CP200) (All versions), SIPROTEC 5 6MD86 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 6MD89 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 6MU85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7KE85 (CP200) (All versions), SIPROTEC 5 7KE85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SA82 (CP100) (All versions \u003e= V7.80), SIPROTEC 5 7SA82 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7SA84 (CP200) (All versions), SIPROTEC 5 7SA86 (CP200) (All versions), SIPROTEC 5 7SA86 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SA87 (CP200) (All versions), SIPROTEC 5 7SA87 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SD82 (CP100) (All versions \u003e= V7.80), SIPROTEC 5 7SD82 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7SD84 (CP200) (All versions), SIPROTEC 5 7SD86 (CP200) (All versions), SIPROTEC 5 7SD86 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SD87 (CP200) (All versions), SIPROTEC 5 7SD87 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SJ81 (CP100) (All versions \u003e= V7.80), SIPROTEC 5 7SJ81 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7SJ82 (CP100) (All versions \u003e= V7.80), SIPROTEC 5 7SJ82 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7SJ85 (CP200) (All versions), SIPROTEC 5 7SJ85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SJ86 (CP200) (All versions), SIPROTEC 5 7SJ86 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SK82 (CP100) (All versions \u003e= V7.80), SIPROTEC 5 7SK82 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7SK85 (CP200) (All versions), SIPROTEC 5 7SK85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SL82 (CP100) (All versions \u003e= V7.80), SIPROTEC 5 7SL82 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7SL86 (CP200) (All versions), SIPROTEC 5 7SL86 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SL87 (CP200) (All versions), SIPROTEC 5 7SL87 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7SS85 (CP200) (All versions), SIPROTEC 5 7SS85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7ST85 (CP200) (All versions), SIPROTEC 5 7ST85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7ST86 (CP300) (All versions \u003c V11.0), SIPROTEC 5 7SX82 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7SX85 (CP300) (All versions \u003c V11.0), SIPROTEC 5 7SY82 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7UM85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7UT82 (CP100) (All versions \u003e= V7.80), SIPROTEC 5 7UT82 (CP150) (All versions \u003c V11.0), SIPROTEC 5 7UT85 (CP200) (All versions), SIPROTEC 5 7UT85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7UT86 (CP200) (All versions), SIPROTEC 5 7UT86 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7UT87 (CP200) (All versions), SIPROTEC 5 7UT87 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7VE85 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7VK87 (CP200) (All versions), SIPROTEC 5 7VK87 (CP300) (All versions \u003e= V7.80 \u003c V11.0), SIPROTEC 5 7VU85 (CP300) (All versions \u003c V11.0), SIPROTEC 5 Compact 7SX800 (CP050) (All versions \u003c V11.0). Affected devices do not use sufficiently random values to create session identifiers. This could allow an unauthenticated remote attacker to brute force a session identifier and gain read access to limited information from the web server without authorization.",
"id": "GHSA-wv47-qqcp-w8j2",
"modified": "2026-05-12T12:32:13Z",
"published": "2026-05-12T12:32:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54017"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-786884.html"
}
],
"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"
},
{
"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: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-2
Strategy: Libraries or Frameworks
Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").
No CAPEC attack patterns related to this CWE.