| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.2.4, a critical authentication-bypass vulnerability in fast-jwt's async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application's key resolver returns an empty string (''), for example via the common keys[decoded.header.kid] || '' JWKS-style fallback, fast-jwt converts it to a zero-length Buffer, hands it to crypto.createSecretKey, derives allowedAlgorithms = ['HS256','HS384','HS512'] from it, and then verifies the token's signature against an empty-key HMAC. The attacker simply computes HMAC-SHA256(key='', input='${header}.${payload}'), which Node accepts without complaint — and the verifier returns the attacker-chosen payload (sub, admin, scopes, etc.) as authentic. This vulnerability is fixed in 6.2.4. |
| IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. |
| Next.js is a React framework for building full-stack web applications. From 13.4.6 to before 15.5.16 and 16.2.5, React Server Component responses can be vulnerable to cache poisoning in deployments that rely on shared caches with insufficient response partitioning. In affected conditions, collisions in the _rsc cache-busting value can allow an attacker to poison cache entries so users receive the wrong response variant for a given URL. This vulnerability is fixed in 15.5.16 and 16.2.5. |
| The Claude Desktop app gives you Claude Code with a graphical interface built for running multiple sessions side by side. From 1.2581.0 to before 1.4304.0, Claude Desktop's SSH remote development feature verified only whether a hostname existed in ~/.ssh/known_hosts without comparing the server's presented host key against the stored key. This allowed a network-positioned attacker to present an arbitrary SSH host key and have the connection silently accepted, enabling a man-in-the-middle attack on remote development sessions. Successful exploitation required the attacker to be in a network position to intercept SSH traffic (e.g., via ARP spoofing, rogue Wi-Fi, or DNS poisoning) and the target hostname to already have an entry in the victim's known_hosts file. This vulnerability is fixed in 1.4304.0. |
| 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. |
| ELECOM wireless LAN access point devices use a hard-coded cryptographic key when creating backups of configuration files. An attacker who knows the encryption key can tamper the configuration file of the product, and a victim administrator may be tricked to use a crafted configuration file. |
| Astro is a web framework. Astro versions prior to 6.1.10 used AES-GCM encryption to protect the confidentiality and integrity of server island props and slots parameters, but did not bind the ciphertext to its intended component or parameter type. An attacker could replay one component's encrypted props (p) value as another component's slots (s) value, or vice versa. Since slots contain raw unescaped HTML while props may contain user-controlled values, this could lead to XSS in applications. This occurs when the application uses server islands, two different server island components share the same key name for a prop and a slot, and an attacker has full control over the value of the overlapping prop (requires a dynamically rendered page). This vulnerability is fixed in 6.1.10. |
| Ecommerce Systempay 1.0 contains a weak cryptographic implementation vulnerability that allows attackers to brute force the 16-character production secret key used for payment signature generation. Attackers can extract payment form data and signatures from POST requests to the payment endpoint, then use SHA1 hash comparison to iteratively test key candidates until discovering the correct production key, enabling them to forge valid payment signatures and manipulate transaction amounts. |
| 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), blueplanet 105 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 110 TL3 (All versions), blueplanet 125 NX3 M11 (All versions), blueplanet 125 TL3 (All versions), blueplanet 125 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 137 TL3 (All versions), blueplanet 150 TL3 (All versions), blueplanet 150 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 155 TL3 (All versions), blueplanet 155 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 165 TL3 (All versions), blueplanet 165 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 25.0 NX3-33.0 NX3 (All versions), blueplanet 3.0 NX3-20.0 NX3 (All versions), blueplanet 3.0 TL3-60.0 TL3 (All versions), blueplanet 3.0-5.0 NX1 (All versions), blueplanet 360 NX3 M6 (All versions), blueplanet 50.0 NX3-60.0 NX3 (All versions), blueplanet 87.0 TL3 (All versions), blueplanet 87.0 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 92.0 TL3 (All versions), blueplanet 92.0 TL3 GEN2 (All versions < V6.1.4.9), blueplanet gridsafe 110 TL3-S (All versions < V3.91), blueplanet gridsafe 137 TL3-S (All versions < V3.91), blueplanet gridsafe 92.0 TL3-S (All versions < V3.91), blueplanet hybrid 10.0 TL3 (All versions), blueplanet hybrid 6.0 NH3-12.0 NH3 (All versions). 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. |
| Ubiquiti UniFi Network Controller prior to 5.10.12 (excluding 5.6.42), UAP FW prior to 4.0.6, UAP-AC, UAP-AC v2, and UAP-AC Outdoor FW prior to 3.8.17, USW FW prior to 4.0.6, USG FW prior to 4.4.34 uses AES-CBC encryption for device-to-controller communication, which contains cryptographic weaknesses that allow attackers to recover encryption keys from captured traffic. Attackers with adjacent network access can capture sufficient encrypted traffic and exploit AES-CBC mode vulnerabilities to derive the encryption keys, enabling unauthorized control and management of network devices. |
| Hirschmann HiLCOS devices OpenBAT, WLC, BAT300, BAT54 prior to 8.80 and OpenBAT prior to 9.10 are shipped with identical default SSH and SSL keys that cannot be changed, allowing unauthenticated remote attackers to decrypt or intercept encrypted management communications. Attackers can perform man-in-the-middle attacks, impersonate devices, and expose sensitive information by leveraging the shared default cryptographic keys across multiple devices. |
| A use of hard-coded cryptographic key vulnerability in Fortinet FortiClientWindows 7.4.0 through 7.4.2, FortiClientWindows 7.2 all versions may allow attacker to information disclosure via <insert attack vector here> |
| AstrBotDevs AstrBot 3.5.15 has Advanced_System_for_Text_Response_and_Bot_Operations_Tool as the hardcoded private key used to sign a JWT. |
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: RMI). Supported versions that are affected are Oracle Java SE: 8u471, 8u471-b50, 8u471-perf, 11.0.29, 17.0.17, 21.0.9, 25.0.1; Oracle GraalVM for JDK: 17.0.17 and 21.0.9; Oracle GraalVM Enterprise Edition: 21.3.16. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N). |
| Issue summary: When using the low-level OCB API directly with AES-NI or<br>other hardware-accelerated code paths, inputs whose length is not a multiple<br>of 16 bytes can leave the final partial block unencrypted and unauthenticated.<br><br>Impact summary: The trailing 1-15 bytes of a message may be exposed in<br>cleartext on encryption and are not covered by the authentication tag,<br>allowing an attacker to read or tamper with those bytes without detection.<br><br>The low-level OCB encrypt and decrypt routines in the hardware-accelerated<br>stream path process full 16-byte blocks but do not advance the input/output<br>pointers. The subsequent tail-handling code then operates on the original<br>base pointers, effectively reprocessing the beginning of the buffer while<br>leaving the actual trailing bytes unprocessed. The authentication checksum<br>also excludes the true tail bytes.<br><br>However, typical OpenSSL consumers using EVP are not affected because the<br>higher-level EVP and provider OCB implementations split inputs so that full<br>blocks and trailing partial blocks are processed in separate calls, avoiding<br>the problematic code path. Additionally, TLS does not use OCB ciphersuites.<br>The vulnerability only affects applications that call the low-level<br>CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with<br>non-block-aligned lengths in a single call on hardware-accelerated builds.<br>For these reasons the issue was assessed as Low severity.<br><br>The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected<br>by this issue, as OCB mode is not a FIPS-approved algorithm.<br><br>OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.<br><br>OpenSSL 1.0.2 is not affected by this issue. |
| A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering. |
| Insecure generation of credentials in the local SAT (Technical Support) access functionality of the Ingecon Sun EMS Board. The vulnerability arose because the secret access credentials were not based on a secure cryptographic scheme, but rather on a weak hashing algorithm, which could allow an attacker to carry out a privilege escalation. |
| Issue summary: The POLY1305 MAC (message authentication code) implementation
contains a bug that might corrupt the internal state of applications running
on PowerPC CPU based platforms if the CPU provides vector instructions.
Impact summary: If an attacker can influence whether the POLY1305 MAC
algorithm is used, the application state might be corrupted with various
application dependent consequences.
The POLY1305 MAC (message authentication code) implementation in OpenSSL for
PowerPC CPUs restores the contents of vector registers in a different order
than they are saved. Thus the contents of some of these vector registers
are corrupted when returning to the caller. The vulnerable code is used only
on newer PowerPC processors supporting the PowerISA 2.07 instructions.
The consequences of this kind of internal application state corruption can
be various - from no consequences, if the calling application does not
depend on the contents of non-volatile XMM registers at all, to the worst
consequences, where the attacker could get complete control of the application
process. However unless the compiler uses the vector registers for storing
pointers, the most likely consequence, if any, would be an incorrect result
of some application dependent calculations or a crash leading to a denial of
service.
The POLY1305 MAC algorithm is most frequently used as part of the
CHACHA20-POLY1305 AEAD (authenticated encryption with associated data)
algorithm. The most common usage of this AEAD cipher is with TLS protocol
versions 1.2 and 1.3. If this cipher is enabled on the server a malicious
client can influence whether this AEAD cipher is used. This implies that
TLS server applications using OpenSSL can be potentially impacted. However
we are currently not aware of any concrete application that would be affected
by this issue therefore we consider this a Low severity security issue. |
| Issue summary: Generating excessively long X9.42 DH keys or checking
excessively long X9.42 DH keys or parameters may be very slow.
Impact summary: Applications that use the functions DH_generate_key() to
generate an X9.42 DH key may experience long delays. Likewise, applications
that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()
to check an X9.42 DH key or X9.42 DH parameters may experience long delays.
Where the key or parameters that are being checked have been obtained from
an untrusted source this may lead to a Denial of Service.
While DH_check() performs all the necessary checks (as of CVE-2023-3817),
DH_check_pub_key() doesn't make any of these checks, and is therefore
vulnerable for excessively large P and Q parameters.
Likewise, while DH_generate_key() performs a check for an excessively large
P, it doesn't check for an excessively large Q.
An application that calls DH_generate_key() or DH_check_pub_key() and
supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
DH_generate_key() and DH_check_pub_key() are also called by a number of
other OpenSSL functions. An application calling any of those other
functions may similarly be affected. The other functions affected by this
are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().
Also vulnerable are the OpenSSL pkey command line application when using the
"-pubcheck" option, as well as the OpenSSL genpkey command line application.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue. |
| Issue summary: A bug has been identified in the processing of key and
initialisation vector (IV) lengths. This can lead to potential truncation
or overruns during the initialisation of some symmetric ciphers.
Impact summary: A truncation in the IV can result in non-uniqueness,
which could result in loss of confidentiality for some cipher modes.
When calling EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() or
EVP_CipherInit_ex2() the provided OSSL_PARAM array is processed after
the key and IV have been established. Any alterations to the key length,
via the "keylen" parameter or the IV length, via the "ivlen" parameter,
within the OSSL_PARAM array will not take effect as intended, potentially
causing truncation or overreading of these values. The following ciphers
and cipher modes are impacted: RC2, RC4, RC5, CCM, GCM and OCB.
For the CCM, GCM and OCB cipher modes, truncation of the IV can result in
loss of confidentiality. For example, when following NIST's SP 800-38D
section 8.2.1 guidance for constructing a deterministic IV for AES in
GCM mode, truncation of the counter portion could lead to IV reuse.
Both truncations and overruns of the key and overruns of the IV will
produce incorrect results and could, in some cases, trigger a memory
exception. However, these issues are not currently assessed as security
critical.
Changing the key and/or IV lengths is not considered to be a common operation
and the vulnerable API was recently introduced. Furthermore it is likely that
application developers will have spotted this problem during testing since
decryption would fail unless both peers in the communication were similarly
vulnerable. For these reasons we expect the probability of an application being
vulnerable to this to be quite low. However if an application is vulnerable then
this issue is considered very serious. For these reasons we have assessed this
issue as Moderate severity overall.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this because
the issue lies outside of the FIPS provider boundary.
OpenSSL 3.1 and 3.0 are vulnerable to this issue. |
