| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Aqara IAM/SSO gateway (gw-builder.aqara.com) exposes bidirectional AES round-trups against the platform's signing key without authentication. This is an instance of "CWE-306: Missing Authentication for Critical Function" and "CWE-327: Use of a Broken or Risky Cryptographic Algorithm," and has an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5 High). |
| Aqara Home Android (com.lumiunited.aqarahome) 6.0.0 (and white-label clients embedding the same liblumidevsdk.so) uses hard-coded cryptographic keys, which is an instance of "CWE-321: Use of Hard-coded Cryptographic Key" and has an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1 Critical). |
| Naxclow devices use a uniform request-signing scheme based on a hard-coded, platform-wide salt embedded in every firmware image. Once this salt is recovered from any device, an attacker can generate valid signatures for arbitrary device or account operations due to the absence of per-device keys, server-side nonce tracking, or replay protections. Combined with the system’s use of plain HTTP for control-plane traffic, the construction enables broad request forgery and impersonation across the platform. |
| A Missing Required Cryptographic Step vulnerability has been identified in Moxa's embedded Linux firmware for industrial computers and controllers. This vulnerability represents an incomplete remediation of CVE-2026-0714. The firmware introduced TPM2 parameter encryption as a countermeasure against CVE-2026-0714. However, an omission in the authorization session configuration causes the parameter encryption to provide no effective protection. An attacker with invasive physical access to the device can still capture TPM communications on the SPI bus and derive the LUKS disk encryption key in plaintext. While successful exploitation results in full compromise of the encrypted disk volume, the attack requires invasive physical access, including opening the device and attaching external equipment to the SPI bus. Remote exploitation is not possible, and the attack does not affect any downstream systems. |
| Wss4jSecurityInterceptor defaulted allowRSA15KeyTransportAlgorithm to true, overriding Apache WSS4J's safer default for validation RequestData. Inbound WS-Security decryption could therefore accept RSA PKCS#1 v1.5 (rsa-1_5) encrypted key material unless operators explicitly reconfigured the flag.
Affected versions:
Spring Web Services 5.0.0 through 5.0.1; 4.1.0 through 4.1.3; 4.0.0 through 4.0.18; 3.1.0 through 3.1.8. |
| During an internal security assessment, a potential vulnerability was discovered in some ThinkPad embedded controller firmware that could allow a privileged local user to perform arbitrary reads or writes to privileged memory regions. |
| An improper implementation of TLS certificate validation vulnerability found in NETGEAR's ReadyCloud client app which could allow an attacker to perform attacker-in-the-middle (MiTM) style attacks impacting the product's confidentiality. This vulnerability affects the listed NETGEAR models. |
| A security flaw has been discovered in gradio-app gradio 6.14.0. This affects the function save_audio_to_cache of the component Audio Cache Key Handler. Performing a manipulation results in use of weak hash. The attack must be initiated from a local position. The attack is considered to have high complexity. It is indicated that the exploitability is difficult. The exploit has been released to the public and may be used for attacks. The patch is named 13394. To fix this issue, it is recommended to deploy a patch. |
| A vulnerability has been found in Streamlit up to 1.53.0. Impacted is an unknown function in the library lib/streamlit/runtime/caching/hashing.py of the component Palette Handler. Such manipulation leads to use of weak hash. Local access is required to approach this attack. The attack requires a high level of complexity. The exploitability is considered difficult. The exploit has been disclosed to the public and may be used. The pull request to fix this issue awaits acceptance. |
| A vulnerability has been found in milvus-io milvus up to 2.6.13. This vulnerability affects unknown code of the file internal/metastore/kv/rootcoord/kv_catalog.go of the component Grantee ID Hash Handler. The manipulation leads to use of weak hash. The attack needs to be performed locally. The attack's complexity is rated as high. It is stated that the exploitability is difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 3d932f1c3e065351c4440c27abe1e6479752544d. Applying a patch is the recommended action to fix this issue. |
| Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV
(RFC 8452) mishandle the authentication of AAD (Additional Authenticated
Data) with an empty ciphertext allowing a forgery of such messages.
Impact summary: An attacker can forge empty messages with arbitrary AAD
to the victim's application using these ciphers.
AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD
modes: they accept a key, nonce, optional AAD (bytes that are authenticated
but not encrypted), and plaintext, and produces ciphertext plus a 16-byte
tag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success only
if the tag is verified succesfully.
In OpenSSL's provider implementation of these ciphers, the expected tag is
computed only when decryption function is invoked with non-empty data.
If the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without
invocation of the ciphertext update, which can happen when the received
ciphertext length is zero, the tag is never recalculated and still holds its
all-zeros value.
When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty
ciphertext, and all-zeros tag passes authentication under any key they do not
know, single-shot. When AES-SIV is used, for mounting the attack it's
necessary for the application to reuse the decryption context without
resetting the key.
AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since
OpenSSL 3.2.
No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support
either AES-GCM-SIV or AES-SIV. To mount an attack, the applications must
implement their own protocol and use the EVP interface. Also they must skip the
ciphertext update when a message with an empty ciphertext arrives.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as these algorithms are not FIPS approved and the affected code is
outside the OpenSSL FIPS module boundary. |
| Issue summary: When an application drives an AES-OCB context through the
public EVP_Cipher() one-shot interface, the application-supplied
initialisation vector (IV) is silently discarded.
Impact summary: Every message encrypted under the same key uses the
same effective nonce regardless of the IV supplied by the caller,
resulting in (key, nonce) reuse and loss of confidentiality. If the
same code path is used to compute the authentication tag, the tag
depends only on the (key, IV) pair and not on the plaintext or
ciphertext, allowing universal forgery of arbitrary ciphertext from a
single captured message.
OpenSSL provides two ways to drive a cipher: the documented streaming
interface (EVP_CipherUpdate / EVP_CipherFinal_ex) and a lower-level
one-shot, EVP_Cipher(), whose documentation explicitly recommends
against use by applications in favour of EVP_CipherUpdate() and
EVP_CipherFinal_ex(). The OCB provider's streaming handler flushes
the application-supplied IV into the OCB context before processing
data; the one-shot handler did not. Every call to EVP_Cipher() on an
AES-OCB context therefore ran with the all-zero key-derived offset
state left by cipher initialisation, regardless of the caller's IV.
If EVP_EncryptFinal_ex() is subsequently used to obtain the
authentication tag, the deferred IV setup runs at that point and
clears the running checksum that should have been accumulated over the
plaintext. The resulting tag is a function of (key, IV) only and
verifies against any ciphertext produced under the same (key, IV)
pair.
The OpenSSL SSL/TLS implementation is not affected: AES-OCB is not a
TLS cipher suite, and libssl does not call EVP_Cipher() in any case.
Applications that drive AES-OCB through the documented streaming AEAD
API (EVP_CipherUpdate / EVP_CipherFinal_ex) are not affected. Only
applications that combine the AES-OCB cipher with the EVP_Cipher()
one-shot API are vulnerable.
The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by
this issue, as AES-OCB is outside the OpenSSL FIPS module boundary. |
| Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42)
peer key, the peer key is not properly checked for the subgroup membership.
Impact summary: A malicious peer which presents an X9.42 key carrying the
victim's p and g parameters, a forged q = r (a small prime factor of the
cofactor (p−1)/q_local), and a public value Y of order r can recover the
victim's private key after a small number of key exchange attempts.
When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the
subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's
own q parameter, not the local key's q. The peer's domain parameters are
then matched against the domain parameters of the private key, but the value
of q is not compared.
A malicious peer who presents an X9.42 key carrying the victim's p, g,
a forged q = r (a small prime factor of the cofactor), and a public
value Y of order r passes all checks. The shared secret then takes only
r distinct values, leaking priv mod r. Repeating for each small-prime
factor of the cofactor and combining via CRT recovers the full private
key (Lim–Lee / small-subgroup-confinement attack).
The realistic attack surface is narrow: principally CMP deployments with
long-lived RA/CA DHX keys and bespoke enterprise or government applications
using X9.42 DHX static keys with interactive protocols and therefore this
issue was assigned Low severity.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are affected by this
issue. |
| Windows Kerberos Information Disclosure Vulnerability |
| phpMyFAQ is an open source FAQ web application. Prior to version 4.1.4, attachment passwords are hashed using SHA-1, a cryptographically broken algorithm. SHA-1 has been vulnerable to collision attacks since 2017 (SHAttered). Version 4.1.4 fixes the issue. |
| A vulnerability has been found in yoanbernabeu grepai 0.35.0. This issue affects some unknown processing of the file indexer/chunker.go of the component Qdrant Backend. Such manipulation leads to use of weak hash. The attack may be performed from remote. Attacks of this nature are highly complex. The exploitability is assessed as difficult. The exploit has been disclosed to the public and may be used. The pull request to fix this issue awaits acceptance. |
| GNCC GP5 v7.1.76 was discovered to utilize a weak hashing algorithm to protect the root password, possibly allowing attackers to obtain root credentials and privileges via a bruteforce attack. |
| A vulnerability has been found in onnx onnx-mlir up to 0.5.0.0. Affected by this issue is the function generate_hash_key of the file src/Runtime/python/torch_onnxmlir/src/torch_onnxmlir/backend.py of the component Placeholder Node Cache Handler. Such manipulation leads to use of weak hash. An attack has to be approached locally. A high complexity level is associated with this attack. The exploitation is known to be difficult. The name of the patch is 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4. Applying a patch is advised to resolve this issue. |
| A weakness has been identified in thedotmack claude-mem up to 11.0.1. The affected element is the function computeObservationContentHash of the file src/services/sqlite/observations/store.ts of the component Observation Content Hash Handler. This manipulation causes use of weak hash. The attack can only be executed locally. The attack's complexity is rated as high. The exploitability is described as difficult. Upgrading to version 12.0.0 is sufficient to fix this issue. Patch name: f32fda8b35e9fe9329f87da65c31149362a03f97. It is suggested to upgrade the affected component. |
| A flaw has been found in GL.iNet A1300, AX1800, AXT1800, MT2500, MT3000, MT6000, X3000 and XE3000 4.8.x. This affects an unknown function of the component glnassys. Executing a manipulation can lead to use of hard-coded cryptographic key
. The attack may be launched remotely. The attack requires a high level of complexity. The exploitability is reported as difficult. Upgrading to version 4.9.0 mitigates this issue. Upgrading the affected component is advised. |
