Total
590 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-64787 | 3 Adobe, Apple, Microsoft | 6 Acrobat, Acrobat Dc, Acrobat Reader and 3 more | 2025-12-12 | N/A | 3.3 LOW |
| Acrobat Reader versions 24.001.30264, 20.005.30793, 25.001.20982, 24.001.30273, 20.005.30803 and earlier are affected by an Improper Verification of Cryptographic Signature vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass cryptographic protections and gain limited unauthorized write access. Exploitation of this issue does not require user interaction. | |||||
| CVE-2025-13662 | 1 Ivanti | 1 Endpoint Manager | 2025-12-11 | N/A | 7.8 HIGH |
| Improper verification of cryptographic signatures in the patch management component of Ivanti Endpoint Manager prior to version 2024 SU4 SR1 allows a remote unauthenticated attacker to execute arbitrary code. User Interaction is required. | |||||
| CVE-2025-66567 | 1 Onelogin | 1 Ruby-saml | 2025-12-10 | N/A | 9.1 CRITICAL |
| The ruby-saml library is for implementing the client side of a SAML authorization. ruby-saml versions up to and including 1.12.4 contain an authentication bypass vulnerability due to an incomplete fix for CVE-2025-25292. ReXML and Nokogiri parse XML differently, generating entirely different document structures from the same input. This allows an attacker to execute a Signature Wrapping attack. This issue is fixed in version 1.18.0. | |||||
| CVE-2025-66568 | 1 Onelogin | 1 Ruby-saml | 2025-12-10 | N/A | 9.1 CRITICAL |
| The ruby-saml library implements the client side of an SAML authorization. Versions up to and including 1.12.4, are vulnerable to authentication bypass through the libxml2 canonicalization process used by Nokogiri for document transformation, which allows an attacker to execute a Signature Wrapping attack. When libxml2’s canonicalization is invoked on an invalid XML input, it may return an empty string rather than a canonicalized node. ruby-saml then proceeds to compute the DigestValue over this empty string, treating it as if canonicalization succeeded. This issue is fixed in version 1.18.0. | |||||
| CVE-2025-59719 | 1 Fortinet | 1 Fortiweb | 2025-12-09 | N/A | 9.8 CRITICAL |
| An improper verification of cryptographic signature vulnerability in Fortinet FortiWeb 8.0.0, FortiWeb 7.6.0 through 7.6.4, FortiWeb 7.4.0 through 7.4.9 may allow an unauthenticated attacker to bypass the FortiCloud SSO login authentication via a crafted SAML response message. | |||||
| CVE-2022-31807 | 1 Siemens | 4 Sipass Integrated Ac5102 \(acc-g2\), Sipass Integrated Ac5102 \(acc-g2\) Firmware, Sipass Integrated Acc-ap and 1 more | 2025-12-09 | N/A | 6.2 MEDIUM |
| A vulnerability has been identified in Building X - Security Manager Edge Controller (ACC-AP) (All versions). Affected devices do not properly check the integrity of firmware updates. This could allow a local attacker to upload a maliciously modified firmware onto the device. In a second scenario, a remote attacker who is able to intercept the transfer of a valid firmware from the server to the device could modify the firmware "on the fly". | |||||
| CVE-2025-65945 | 2025-12-08 | N/A | 7.5 HIGH | ||
| auth0/node-jws is a JSON Web Signature implementation for Node.js. In versions 3.2.2 and earlier and version 4.0.0, auth0/node-jws has an improper signature verification vulnerability when using the HS256 algorithm under specific conditions. Applications are affected when they use the jws.createVerify() function for HMAC algorithms and use user-provided data from the JSON Web Signature protected header or payload in HMAC secret lookup routines, which can allow attackers to bypass signature verification. This issue has been patched in versions 3.2.3 and 4.0.1. | |||||
| CVE-2018-16152 | 3 Canonical, Debian, Strongswan | 3 Ubuntu Linux, Debian Linux, Strongswan | 2025-12-03 | 5.0 MEDIUM | 7.5 HIGH |
| In verify_emsa_pkcs1_signature() in gmp_rsa_public_key.c in the gmp plugin in strongSwan 4.x and 5.x before 5.7.0, the RSA implementation based on GMP does not reject excess data in the digestAlgorithm.parameters field during PKCS#1 v1.5 signature verification. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation when only an RSA signature is used for IKEv2 authentication. This is a variant of CVE-2006-4790 and CVE-2014-1568. | |||||
| CVE-2018-16151 | 3 Canonical, Debian, Strongswan | 3 Ubuntu Linux, Debian Linux, Strongswan | 2025-12-03 | 5.0 MEDIUM | 7.5 HIGH |
| In verify_emsa_pkcs1_signature() in gmp_rsa_public_key.c in the gmp plugin in strongSwan 4.x and 5.x before 5.7.0, the RSA implementation based on GMP does not reject excess data after the encoded algorithm OID during PKCS#1 v1.5 signature verification. Similar to the flaw in the same version of strongSwan regarding digestAlgorithm.parameters, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation when only an RSA signature is used for IKEv2 authentication. | |||||
| CVE-2022-39366 | 1 Datahub | 1 Datahub | 2025-12-03 | N/A | 9.9 CRITICAL |
| DataHub is an open-source metadata platform. Prior to version 0.8.45, the `StatelessTokenService` of the DataHub metadata service (GMS) does not verify the signature of JWT tokens. This allows an attacker to connect to DataHub instances as any user if Metadata Service authentication is enabled. This vulnerability occurs because the `StatelessTokenService` of the Metadata service uses the `parse` method of `io.jsonwebtoken.JwtParser`, which does not perform a verification of the cryptographic token signature. This means that JWTs are accepted regardless of the used algorithm. This issue may lead to an authentication bypass. Version 0.8.45 contains a patch for the issue. There are no known workarounds. | |||||
| CVE-2024-23680 | 1 Amazon | 1 Aws Encryption Sdk | 2025-11-29 | N/A | 5.3 MEDIUM |
| AWS Encryption SDK for Java versions 2.0.0 to 2.2.0 and less than 1.9.0 incorrectly validates some invalid ECDSA signatures. | |||||
| CVE-2025-58356 | 2025-11-28 | N/A | N/A | ||
| Constellation is the first Confidential Kubernetes. The Constellation CVM image uses LUKS2-encrypted volumes for persistent storage. When opening an encrypted storage device, the CVM uses the libcryptsetup function crypt_activate_by_passhrase. If the VM is successful in opening the partition with the disk encryption key, it treats the volume as confidential. However, due to the unsafe handling of null keyslot algorithms in the cryptsetup 2.8.1, it is possible that the opened volume is not encrypted at all. Cryptsetup prior to version 2.8.1 does not report an error when processing LUKS2-formatted disks that use the cipher_null-ecb algorithm in the keyslot encryption field. This vulnerability is fixed in 2.24.0. | |||||
| CVE-2024-48949 | 1 Indutny | 1 Elliptic | 2025-11-25 | N/A | 9.1 CRITICAL |
| The verify function in lib/elliptic/eddsa/index.js in the Elliptic package before 6.5.6 for Node.js omits "sig.S().gte(sig.eddsa.curve.n) || sig.S().isNeg()" validation. | |||||
| CVE-2024-48948 | 1 Indutny | 1 Elliptic | 2025-11-25 | N/A | 4.8 MEDIUM |
| The Elliptic package 6.5.7 for Node.js, in its for ECDSA implementation, does not correctly verify valid signatures if the hash contains at least four leading 0 bytes and when the order of the elliptic curve's base point is smaller than the hash, because of an _truncateToN anomaly. This leads to valid signatures being rejected. Legitimate transactions or communications may be incorrectly flagged as invalid. | |||||
| CVE-2025-59288 | 1 Microsoft | 1 Playwright | 2025-11-21 | N/A | 5.3 MEDIUM |
| Improper verification of cryptographic signature in Github: Playwright allows an unauthorized attacker to perform spoofing over an adjacent network. | |||||
| CVE-2025-64456 | 1 Jetbrains | 1 Resharper | 2025-11-20 | N/A | 8.4 HIGH |
| In JetBrains ReSharper before 2025.2.4 missing signature verification in DPA Collector allows local privilege escalation | |||||
| CVE-2025-64186 | 2025-11-14 | N/A | 8.7 HIGH | ||
| Evervault is a payment security solution. A vulnerability was identified in the `evervault-go` SDK’s attestation verification logic in versions of `evervault-go` prior to 1.3.2 that may allow incomplete documents to pass validation. This may cause the client to trust an enclave operator that does not meet expected integrity guarantees. The exploitability of this issue is limited in Evervault-hosted environments as an attacker would require the pre-requisite ability to serve requests from specific evervault domain names, following from our ACME challenge based TLS certificate acquisition pipeline. The vulnerability primarily affects applications which only check PCR8. Though the efficacy is also reduced for applications that check all PCR values, the impact is largely remediated by checking PCR 0, 1 and 2. The identified issue has been addressed in version 1.3.2 by validating attestation documents before storing in the cache, and replacing the naive equality checks with a new SatisfiedBy check. Those who useevervault-go to attest Enclaves that are hosted outside of Evervault environments and cannot upgrade have two possible workarounds available. Modify the application logic to fail verification if PCR8 is not explicitly present and non-empty and/or add custom pre-validation to reject documents that omit any required PCRs. | |||||
| CVE-2025-55278 | 2025-11-06 | N/A | 8.1 HIGH | ||
| Improper authentication in the API authentication middleware of HCL DevOps Loop allows authentication tokens to be accepted without proper validation of their expiration and cryptographic signature. As a result, an attacker could potentially use expired or tampered tokens to gain unauthorized access to sensitive resources and perform actions with elevated privileges. | |||||
| CVE-2025-47827 | 2 Igel, Microsoft | 16 Igel Os, Windows 10 1507, Windows 10 1607 and 13 more | 2025-11-05 | N/A | 4.6 MEDIUM |
| In IGEL OS before 11, Secure Boot can be bypassed because the igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image. | |||||
| CVE-2025-55039 | 1 Apache | 1 Spark | 2025-11-04 | N/A | 6.5 MEDIUM |
| This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. | |||||