| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 include deprecated OpsDirector functionality with weaknesses that could allow an unauthenticated remote attacker to make unauthorized requests to internal services or forge trusted requests, potentially resulting in unauthorized access to protected information. |
| Apache CXF's STSTokenValidator and Security Token Service (STS) cached validated security tokens under a non-cryptographic 32-bit hash of the token (Java Arrays.hashCode/hashCode()), and treated a cache hit as proof that the presented token had already been validated. An attacker could craft a token (for example a UsernameToken or a self-signed SAML Assertion) whose hash collides with a cached entry. The token would then be accepted without password validation, signature trust verification or a call to the STS. This could let the attacker authenticate as another user and, through STS token validation or renewal, obtain STS-signed tokens for that identity.
Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue. |
| In Bouncy Castle for Java LTS before 2.73.13, the native one-shot CTR packet cipher did not check that the requested input length fitted the counter space the IV left. In CTR mode the IV and the block counter share one 16-byte block, so an IV of 13 to 15 bytes leaves a counter of only 1 to 3 bytes, addressing 256, 65536 or 16777216 blocks respectively. Given a longer input the counter wrapped and the keystream repeated from the start of the same packet, and the call then returned the full input length as though every byte had been correctly transformed. Two segments of the message were therefore encrypted under the same keystream, so their plaintexts can be recovered from the ciphertext alone, without the key, while the caller saw neither an exception nor a short length to indicate it. The streaming implementation validates at init and again while processing, and the portable AESCTRPacketCipher rejects such a request with "Counter in CTR/SIC mode out of range.", but the native one-shot path has a single entry point and performed no counter-range validation there. It now preflights the IV-derived counter range and rejects an over-long request before any output is written, so the operation is failure-atomic and never reports success for bytes it did not correctly transform. A counter of four bytes or more cannot be exhausted by a Java int length and is unaffected, as is a full 16-byte IV, where the counter range is the caller's responsibility. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations. |
| Slican telephone exchanges use symmetric encryption for TCP/IP communication. Secret key is hardcoded in multiple binary files. An attacker who has access to these files can decrypt the communication.
This issue was fixed in IPx series version 6.62.0100.
The issue STILL EXISTS in End-Of-Life telephone exchanges:
- CCT-1668 (CCT1CPU)
- MAC-6400
- CXS-0424
These products were discontinued in 2011 and 2012 and and will not receive updates. These products require a hardware update in order to receive a software update. The vendor recommends that users of these devices contact the their service department directly to determine the options for upgrading. |
| When the default self-signed certificate is used, an attacker could gain administrative access to the application.
The SSL certificate for the web interface is used to sign JWT access tokens that are used to validate that the user is logged in. When the default SSL certificate is used, an attacker could have the capability to sign JWT access tokens and bypass login.
An attacker could gain administrative access to the application and perform actions like configuring the service or requesting log collection. Device credentials and customer data cannot be accessed with this vulnerability. |
| Huawei's openUBMC ships a default SNMPv3 USM key that uses one value for both authentication and privacy. An attacker who holds the key (recoverable from the open-source build) can authenticate SNMPv3 to, and decrypt SNMPv3 traffic from, any unit that still carries the shipped key. The build customization `manifest/build/customization/default_password.lua` sets `AuthenticationKey == EncryptionKey == 7df2f29369e3ac3245b2c9d46b67a0ecd055197e41808a34ef325db2f6422581` for the iBMC product build, and the community seed `account/manufacture/default_password.lua` sets both to `7a2f5b86f20233ec7b7bef49643fbf34d86d0cbf6f1f8f5c52d4f30d4536938b`. These are shipped constants, not per-unit values, and they are not rotated by the Administrator password reset, so they survive account provisioning. This is especially dangerous considering that SNMP access is mapped to full device administration privileges, including system reset and firmware upgrades. |
| A vulnerability in the SupportLink API authentication component of Brocade ASCG versions prior to 3.5.0 allows an attacker to bypass authentication across deployments due to the use of a hard coded cryptographic key. |
| Inadequate encryption strength in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to perform spoofing locally. |
| BotSharp through 5.2.0 contains an authentication bypass vulnerability that allows unauthenticated remote attackers to forge bearer tokens using the hard-coded Jwt:Key in WebStarter appsettings.json. Attackers can sign tokens with the committed HMAC secret and fixed botsharp issuer and audience to impersonate any known user, including administrators, on Authorize-protected API routes. |
| IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.10 and IBM WebSphere Application Server 8.5, and 9.0 could allow a remote attacker to bypass cryptographic signature verification due to improper verification of cryptographic signature. |
| vlife through 2.0.1 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge JWTs using the hardcoded HS256 signing key in TokenUtil. Attackers can sign a token with superUser=true and arbitrary groupIds claims to gain super administrator access to any URL on vlife instances. |
| Libgcrypt before 1.8.8 and 1.9.x before 1.9.3 mishandles ElGamal encryption because it lacks exponent blinding to address a side-channel attack against mpi_powm, and the window size is not chosen appropriately. This, for example, affects use of ElGamal in OpenPGP. |
| GnuTLS 3.6.x before 3.6.13 uses incorrect cryptography for DTLS. The earliest affected version is 3.6.3 (2018-07-16) because of an error in a 2017-10-06 commit. The DTLS client always uses 32 '\0' bytes instead of a random value, and thus contributes no randomness to a DTLS negotiation. This breaks the security guarantees of the DTLS protocol. |
| Snowy 3.6.5 contains a hard-coded HMAC key vulnerability that allows unauthenticated attackers to forge download signatures for the /dev/file/download endpoint by using the published FILE_DOWNLOAD_SIGN_SECRET constant. Attackers can compute HMAC-SHA256 signatures of guessed file ids offline to download stored files such as avatars, editor images and attachments. |
| A use of hard-coded cryptographic key vulnerability in Fortinet FortiSandbox 5.2.0 through 5.2.1, FortiSandbox 5.0.0 through 5.0.6, FortiSandbox 4.4 all versions, FortiSandbox Cloud 5.2.0 through 5.2.1, FortiSandbox Cloud 5.0.0 through 5.0.6, FortiSandbox Cloud 4.4 all versions may allow attacker to escalation of privilege via specially crafted HTTP requests |
| NetEase Cloud Music client for Windows (cloudmusic.exe) versions 3.1.38 and 3.1.39.205426 contains a weak encryption vulnerability where /eapi/ and /xeapi/ API response bodies are decrypted using a fixed, publicly documented AES-128-ECB key with no integrity credential. Attackers who can intercept or originate server responses can construct valid ciphertext under the known key with PKCS#7 padding, enabling the client to accept forged API responses that serve as a prerequisite for further exploitation such as reaching the os.navigateExternal bridge. |
| NVIDIA Megatron-LM for all platforms contains a vulnerability in inference, where an attacker could cause hash collisions in the cache used for inference requests. A successful exploit of this vulnerability might lead to data tampering and partial information disclosure. |
| A vulnerability has been identified in blueplanet 100 NX3 M8 (All versions), blueplanet 100 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 105 TL3 (All versions < V3.92), blueplanet 105 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 110 TL3 (All versions < V3.92), blueplanet 125 NX3 M10 (All versions), blueplanet 125 TL3 (All versions < V3.92), blueplanet 125 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 137 TL3 (All versions < V3.92), blueplanet 150 TL3 (All versions < V3.92), blueplanet 150 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 155 TL3 (All versions < V3.92), blueplanet 155 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 165 TL3 (All versions < V3.92), blueplanet 165 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 3.0 TL3-60.0 TL3 (All versions), blueplanet 87.0 TL3 (All versions < V3.92), blueplanet 87.0 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 92.0 TL3 (All versions < V3.92), blueplanet 92.0 TL3 GEN2 (All versions < V6.1.4.9), blueplanet gridsave 110 TL3-S (All versions < V3.91), blueplanet gridsave 137 TL3-S (All versions < V3.91), blueplanet gridsave 92.0 TL3-S (All versions < V3.91). A CRC16-based algorithm for generating Technical Service credentials could allow an attacker to derive the credentials from the devices serial number and misuse them to gain unauthorized access. |
| In Progress ShareFile Storage Zones Controller v5.12.6 and below, processing of queue items can send acknowledgements to an unvalidated callback URL, this behavior together with a race condition allows the attacker to cause FileCopyService to consume attacker-controlled metadata and content. Exploitation requires control over copy queue work and a race condition. |
| Crux Agent from 1.9.0 before 2.0.3 uses the full SKA bilocation key as the WireGuard preshared key. When a peering session negotiates use of SHA-512, the key produced is 64 bytes instead of the 32 bytes WireGuard requires. The agent does not validate this size; instead it attempts to use the `wg set` command to update the live tunnel, and write the invalid key to the WireGuard configuration file. The update fails, so the live tunnel keeps using its previous preshared key until the tunnel is shut down. The tunnel will fail to start when restarted.
For a peer which has never successfully negotiated a 32-byte bilocation key in a Crux C2 organization which has the "Enforce SKA Use" setting turned off, no preshared key will be set for the tunnel. Therefore, an attacker who is able to intercept and store the peer's traffic, and has access (or will have access) to a cryptographically relevant quantum computer, will be able to decrypt the tunnel. |
