| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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 ReadyCloud client app which can allow an attacker to perform attacker-in-the-middle (MiTM) style attacks impacting product's confidentiality. This vulnerability affects the listed NETGEAR models. |
| 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 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. |
| A vulnerability was determined in yoanbernabeu grepai up to 0.35.0. The affected element is the function PostgresStore.LookupByContentHash of the file indexer/chunker.go of the component Postgres Embedding Cache. Executing a manipulation of the argument content_hash can lead to use of weak hash. The attack needs to be launched locally. The attack requires a high level of complexity. The exploitability is described as difficult. The exploit has been publicly disclosed and may be utilized. The pull request to fix this issue awaits acceptance. |
| Fixed AES-128-CBC keys inside the AcerConnect OTA application let attackers forge authorization credentials for arbitrary IMEI numbers. This allows unauthorized actors to list catalog items and extract protected binaries from pre-signed cloud links. |
| Version 3.0.7 of the Securly Chrome Extension uses EVP_BytesToKey key derivation with MD5 and a single iteration for AES encryption. MD5 has been broken since 2004 and a single iteration provides no key stretching. |
| HAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, the `hmacBase64()` function in the HAXcms Node.js backend contains two critical cryptographic implementation errors that together allow any unauthenticated attacker to extract the system’s private signing key and forge arbitrary admin-level JSON Web Tokens (JWTs) allowing them to get full admin access with a single HTTP request. First, the function passes the literal string "0" as the HMAC signing key instead of the key parameter, making every HAXcms instance compute identical HMACs for the same input. Then, after computing the HMAC, the function concatenates the real key parameter which is "this.privateKey + this.salt", the system’s master signing secret is directly onto the output. The combined buffer is base64-encoded and returned as the token. Every base64url token produced has the same structure: 32 bytes HMAC keyed with "0" and N bytes of `privateKey+salt`. An attacker base64-decodes any token, discards the first 32 bytes, and reads the private key directly. The `/system/api/connectionSettings` endpoint is unauthenticated and returns multiple tokens generated by this function. A single GET request to this endpoint exposes the private key. The PHP backend implements this function correctly with the actual key and returns only the hash. The PHP version produces 44-character tokens whereas the broken Node.js version produces 139+ character tokens. Version 26.0.0 fixes the issue. |
| The linqi application contains hardcoded cryptographic keys. Additionally, the application uses a weak algorithm with a limited ASCII charset to dynamically generate Initialization Vectors (IVs) for AES/CBC encryption, making known-plaintext attacks feasible. An attacker with local access can leverage these vulnerabilities to decrypt sensitive obfuscated strings, including ConnectionString values containing database credentials from appsettings.json. |
| In Linaro OP-TEE before 3.7.0, by using inconsistent or malformed data, it is possible to call update and final cryptographic functions directly, causing a crash that could leak sensitive information. |
| Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
preferred key exchange group when its key exchange group configuration includes
the default by using the 'DEFAULT' keyword.
Impact summary: A less preferred key exchange may be used even when a more
preferred group is supported by both client and server, if the group
was not included among the client's initial predicated keyshares.
This will sometimes be the case with the new hybrid post-quantum groups,
if the client chooses to defer their use until specifically requested by
the server.
If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to
interpolate the built-in default group list into its own configuration, perhaps
adding or removing specific elements, then an implementation defect causes the
'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups
were treated as a single sufficiently secure 'tuple', with the server not
sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
was mutually supported.
As a result, the client and server might fail to negotiate a mutually supported
post-quantum key agreement group, such as 'X25519MLKEM768', if the client's
configuration results in only 'classical' groups (such as 'X25519' being the
only ones in the client's initial keyshare prediction).
OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
1.3 key agreement group on TLS servers. The old syntax had a single 'flat'
list of groups, and treated all the supported groups as sufficiently secure.
If any of the keyshares predicted by the client were supported by the server
the most preferred among these was selected, even if other groups supported by
the client, but not included in the list of predicted keyshares would have been
more preferred, if included.
The new syntax partitions the groups into distinct 'tuples' of roughly
equivalent security. Within each tuple the most preferred group included among
the client's predicted keyshares is chosen, but if the client supports a group
from a more preferred tuple, but did not predict any corresponding keyshares,
the server will ask the client to retry the ClientHello (by issuing a Hello
Retry Request or HRR) with the most preferred mutually supported group.
The above works as expected when the server's configuration uses the built-in
default group list, or explicitly defines its own list by directly defining the
various desired groups and group 'tuples'.
No OpenSSL FIPS modules are affected by this issue, the code in question lies
outside the FIPS boundary.
OpenSSL 3.6 and 3.5 are vulnerable to this issue.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.
OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue. |
