| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability was detected in nocobase up to 1.9.4/2.0.0-alpha.37. The affected element is an unknown function of the file nocobase\packages\core\auth\src\base\jwt-service.ts of the component JWT Service. The manipulation of the argument API_KEY results in use of hard-coded cryptographic key
. The attack can be launched remotely. A high complexity level is associated with this attack. The exploitability is described as difficult. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability has been found in running-elephant Datart up to 1.0.0-rc3. Affected by this issue is the function getTokensecret of the file datart/security/src/main/java/datart/security/util/AESUtil.java of the component API. The manipulation leads to use of hard-coded cryptographic key
. The attack is possible to be carried out remotely. The attack is considered to have high complexity. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. |
| free-one-api allows users to access large language model reverse engineering libraries through the standard OpenAI API format. In versions up to and including 1.0.1, MD5 is used to hash passwords before sending them to the backend. MD5 is a cryptographically broken hashing algorithm and is no longer considered secure for password storage or transmission. It is vulnerable to collision attacks and can be easily cracked using modern hardware, exposing user credentials to potential compromise. As of time of publication, a replacement for MD5 has not been committed to the free-one-api GitHub repository. |
| sigstore-python is a Python tool for generating and verifying Sigstore signatures. Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the "integration time" present in "v2" and "v3" bundles during the verification flow: the "integration time" is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect "v1" bundles, as the "v1" bundle format always requires an inclusion promise.
Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify). Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry's time. However, this would still be rejected at validation time, as the new entry's (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable. |
| ESPTouch is a connection protocol for internet of things devices. In the ESPTouchV2 protocol, while there is an option to use a custom AES key, there is no option to set the IV (Initialization Vector) prior to versions 5.3.2, 5.2.4, 5.1.6, and 5.0.8. The IV is set to zero and remains constant throughout the product's lifetime. In AES/CBC mode, if the IV is not properly initialized, the encrypted output becomes deterministic, leading to potential data leakage. To address the aforementioned issues, the application generates a random IV when activating the AES key starting in versions 5.3.2, 5.2.4, 5.1.6, and 5.0.8. This IV is then transmitted along with the provision data to the provision device. The provision device has also been equipped with a parser for the AES IV. The upgrade is applicable for all applications and users of ESPTouch v2 component from ESP-IDF. As it is implemented in the ESP Wi-Fi stack, there is no workaround for the user to fix the application layer without upgrading the underlying firmware. |
| An issue in the index.js decryptCookie function of cookie-encrypter v1.0.1 allows attackers to execute a bit flipping attack. |
| A static initialization vector (IV) in the encrypt function of netbird management's service from v0.23.2 to v0.29.1 allows attackers to obtain sensitive information (email addresses) when in possession of the audit events database. |
| An issue was discovered on Swissphone DiCal-RED 4009 devices. An attacker with access to the file /etc/deviceconfig may recover the administrative device password via password-cracking methods, because unsalted MD5 is used. |
| Reusing a nonce, key pair in encryption issue exists in "FreeFrom - the nostr client" App versions prior to 1.3.5 for Android and iOS. If this vulnerability is exploited, the content of direct messages (DMs) between users may be manipulated by a man-in-the-middle attack. |
| Certain Anpviz products contain a hardcoded cryptographic key stored in the firmware of the device. This affects IPC-D250, IPC-D260, IPC-B850, IPC-D850, IPC-D350, IPC-D3150, IPC-D4250, IPC-D380, IPC-D880, IPC-D280, IPC-D3180, MC800N, YM500L, YM800N_N2, YMF50B, YM800SV2, YM500L8, and YM200E10 firmware v3.2.2.2 and lower and possibly more vendors/models of IP camera. |
| HCL DRYiCE Optibot Reset Station is impacted by a missing Strict Transport Security Header. This could allow an attacker to intercept or manipulate data during redirection. |
| Inadequate Encryption Strength vulnerability allow an authenticated attacker to execute arbitrary OS Commands via encrypted package upload.This issue affects Envoy: 4.x and 5.x |
| Inadequate encryption strength for some BMRA software before version 22.08 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| A vulnerability exists in Algo Edge up to 2.1.1 - a previously used (legacy) component of navify® Algorithm Suite. The vulnerability impacts the authentication mechanism of this component and could allow an attacker with adjacent access to the laboratory network and the Algo Edge system to craft valid authentication tokens and access the component. Other components of navify® Algorithm Suite are not affected. |
| The AES key utilized in the pairing process between a lock using Sciener firmware and a wireless keypad is not unique, and can be reused to compromise other locks using the Sciener firmware. |
| Cryptographic Flaw in PDFium in Google Chrome prior to 147.0.7727.55 allowed an attacker to read potentially sensitive information from encrypted PDFs via a brute-force attack. (Chromium security severity: Medium) |
| Configured cipher preference order not preserved vulnerability in Apache Tomcat.
This issue affects Apache Tomcat: from 11.0.16 through 11.0.18, from 10.1.51 through 10.1.52, from 9.0.114 through 9.0.115.
Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue. |
| A Key Exchange without Entity Authentication vulnerability in the SSH implementation of Juniper Networks Apstra allows a unauthenticated, MITM
attacker to impersonate managed devices.
Due to insufficient SSH host key validation an attacker can perform a machine-in-the-middle attack on the SSH connections from Apstra to managed devices, enabling an attacker to impersonate a managed device and capture user credentials.
This issue affects all versions of Apstra before 6.1.1. |
| The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that the A-MSDU flag in the plaintext QoS header field is authenticated. Against devices that support receiving non-SSP A-MSDU frames (which is mandatory as part of 802.11n), an adversary can abuse this to inject arbitrary network packets. |
| Cocos AI is a confidential computing system for AI. The current implementation of attested TLS (aTLS) in CoCoS is vulnerable to a relay attack affecting all versions from v0.4.0 through v0.8.2. This vulnerability is present in both the AMD SEV-SNP and Intel TDX deployment targets supported by CoCoS. In the affected design, an attacker may be able to extract the ephemeral TLS private key used during the intra-handshake attestation. Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. A client will accept the connection under false assumptions about the endpoint it is communicating with — the attestation report cannot distinguish the genuine attested service from the attacker's relay. This undermines the intended authentication guarantees of attested TLS. A successful attack may allow an attacker to impersonate an attested CoCoS service and access data or operations that the client intended to send only to the genuine attested endpoint. Exploitation requires the attacker to first extract the ephemeral TLS private key, which is possible through physical access to the server hardware, transient execution attacks, or side-channel attacks. Note that the aTLS implementation was fully redesigned in v0.7.0, but the redesign does not address this vulnerability. The relay attack weakness is architectural and affects all releases in the v0.4.0–v0.8.2 range. This vulnerability class was formally analyzed and demonstrated across multiple attested TLS implementations, including CoCoS, by researchers whose findings were disclosed to the IETF TLS Working Group. Formal verification was conducted using ProVerif. As of time of publication, there is no patch available. No complete workaround is available. The following hardening measures reduce but do not eliminate the risk: Keep TEE firmware and microcode up to date to reduce the key-extraction surface; define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers; and/or enable mutual aTLS with CA-signed certificates where deployment architecture permits. |
