Export limit exceeded: 425863 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1057 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-28432 | 1 Misskey | 1 Misskey | 2026-04-16 | 7.5 High |
| Misskey is an open source, federated social media platform. All Misskey servers prior to 2026.3.1 contain a vulnerability that allows bypassing HTTP signature verification. Although this is a vulnerability related to federation, it affects all servers regardless of whether federation is enabled or disabled. This vulnerability is fixed in 2026.3.1. | ||||
| CVE-2026-20965 | 1 Microsoft | 2 Azure Portal Windows Admin Center, Windows Admin Center | 2026-04-16 | 7.5 High |
| Improper verification of cryptographic signature in Windows Admin Center allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2005-2182 | 1 Grandstream | 2 Bt-100, Bt-100 Firmware | 2026-04-16 | 7.5 High |
| Grandstream BudgeTone (BT) 100 Voice over IP (VoIP) phones do not properly check the Call-ID, branch, and tag values in a NOTIFY message to verify a subscription, which allows remote attackers to spoof messages such as the "Messages waiting" message. | ||||
| CVE-2005-2181 | 1 Cisco | 4 Ip Phone 7940, Ip Phone 7940 Firmware, Ip Phone 7960 and 1 more | 2026-04-16 | 7.5 High |
| Cisco 7940/7960 Voice over IP (VoIP) phones do not properly check the Call-ID, branch, and tag values in a NOTIFY message to verify a subscription, which allows remote attackers to spoof messages such as the "Messages waiting" message. | ||||
| CVE-2002-1706 | 1 Cisco | 3 Ios, Ubr7100, Ubr7200 | 2026-04-16 | 7.5 High |
| Cisco IOS software 11.3 through 12.2 running on Cisco uBR7200 and uBR7100 series Universal Broadband Routers allows remote attackers to modify Data Over Cable Service Interface Specification (DOCSIS) settings via a DOCSIS file without a Message Integrity Check (MIC) signature, which is approved by the router. | ||||
| CVE-2002-1796 | 1 Hp | 5 Chaivm Ezloader, Laserjet 4100, Laserjet 4500 and 2 more | 2026-04-16 | 7.8 High |
| ChaiVM EZloader for HP color LaserJet 4500 and 4550 and HP LaserJet 4100 and 8150 does not properly verify JAR signatures for new services, which allows local users to load unauthorized Chai services. | ||||
| CVE-2026-39395 | 1 Sigstore | 1 Cosign | 2026-04-15 | 4.3 Medium |
| Cosign provides code signing and transparency for containers and binaries. Prior to 3.0.6 and 2.6.3, cosign verify-blob-attestation may erroneously report a "Verified OK" result for attestations with malformed payloads or mismatched predicate types. For old-format bundles and detached signatures, this was due to a logic flaw in the error handling of the predicate type validation. For new-format bundles, the predicate type validation was bypassed completely. This vulnerability is fixed in 3.0.6 and 2.6.3. | ||||
| CVE-2026-32614 | 1 Emmansun | 1 Gmsm | 2026-04-15 | 7.5 High |
| Go ShangMi (Commercial Cryptography) Library (GMSM) is a cryptographic library that covers the Chinese commercial cryptographic public algorithms SM2/SM3/SM4/SM9/ZUC. Prior to 0.41.1, the current SM9 decryption implementation contains an infinity-point ciphertext forgery vulnerability. The root cause is that, during decryption, the elliptic-curve point C1 in the ciphertext is only deserialized and checked to be on the curve, but the implementation does not explicitly reject the point at infinity. In the current implementation, an attacker can construct C1 as the point at infinity, causing the bilinear pairing result to degenerate into the identity element in the GT group. As a result, a critical part of the key derivation input becomes a predictable constant. An attacker who only knows the target user's UID can derive the decryption key material and then forge a ciphertext that passes the integrity check. This vulnerability is fixed in 0.41.1. | ||||
| CVE-2025-12007 | 1 Supermicro | 1 Mbd-x13sem-f | 2026-04-15 | 8.4 High |
| There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X13SEM-F . An attacker can update the system firmware with a specially crafted image. | ||||
| CVE-2025-55278 | 1 Hcltech | 1 Devops Loop | 2026-04-15 | 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-2020-36843 | 2026-04-15 | 4.3 Medium | ||
| The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message. | ||||
| CVE-2025-30064 | 1 Cgm | 1 Clininet | 2026-04-15 | N/A |
| An insufficiently secured internal function allows session generation for arbitrary users. The decodeParam function checks the JWT but does not verify which signing algorithm was used. As a result, an attacker can use the "ex:action" parameter in the VerifyUserByThrustedService function to generate a session for any user. | ||||
| CVE-2025-54982 | 1 Zscaler | 1 Authentication Server | 2026-04-15 | 9.6 Critical |
| An improper verification of cryptographic signature in Zscaler's SAML authentication mechanism on the server-side allowed an authentication abuse. | ||||
| CVE-2023-53951 | 1 Gauzy | 1 Ever Gauzy | 2026-04-15 | 9.8 Critical |
| Ever Gauzy v0.281.9 contains a JWT authentication vulnerability that allows attackers to exploit weak HMAC secret key implementation. Attackers can leverage the exposed JWT token to authenticate and gain unauthorized access with administrative permissions. | ||||
| CVE-2024-54150 | 2026-04-15 | 9.1 Critical | ||
| cjwt is a C JSON Web Token (JWT) Implementation. Algorithm confusion occurs when a system improperly verifies the type of signature used, allowing attackers to exploit the lack of distinction between signing methods. If the system doesn't differentiate between an HMAC signed token and an RS/EC/PS signed token during verification, it becomes vulnerable to this kind of attack. For instance, an attacker could craft a token with the alg field set to "HS256" while the server expects an asymmetric algorithm like "RS256". The server might mistakenly use the wrong verification method, such as using a public key as the HMAC secret, leading to unauthorised access. For RSA, the key can be computed from a few signatures. For Elliptic Curve (EC), two potential keys can be recovered from one signature. This can be used to bypass the signature mechanism if an application relies on asymmetrically signed tokens. This issue has been addressed in version 2.3.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-56161 | 2026-04-15 | 7.2 High | ||
| Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious CPU microcode resulting in loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP. | ||||
| CVE-2024-36277 | 2026-04-15 | 5.3 Medium | ||
| Improper verification of cryptographic signature issue exists in "FreeFrom - the nostr client" App versions prior to 1.3.5 for Android and iOS. The affected app cannot detect event data with invalid signatures. | ||||
| CVE-2025-54549 | 1 Arista | 1 Danz Monitoring Fabric | 2026-04-15 | 5.9 Medium |
| Cryptographic validation of upgrade images could be circumventing by dropping a specifically crafted file into the upgrade ISO | ||||
| CVE-2025-31489 | 1 Minio | 1 Minio | 2026-04-15 | 7.5 High |
| MinIO is a High Performance Object Storage released under GNU Affero General Public License v3.0. The signature component of the authorization may be invalid, which would mean that as a client you can use any arbitrary secret to upload objects given the user already has prior WRITE permissions on the bucket. Prior knowledge of access-key, and bucket name this user might have access to - and an access-key with a WRITE permissions is necessary. However with relevant information in place, uploading random objects to buckets is trivial and easy via curl. This issue is fixed in RELEASE.2025-04-03T14-56-28Z. | ||||
| CVE-2024-32962 | 1 Node Saml Project | 1 Xml Crypto | 2026-04-15 | 10 Critical |
| xml-crypto is an xml digital signature and encryption library for Node.js. In affected versions the default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of the w3 xmldsig-core-20080610 spec. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `<KeyInfo />` element, and pass `xml-crypto` default validation checks. As a result `xml-crypto` trusts by default any certificate provided via digitally signed XML document's `<KeyInfo />`. `xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes. An attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to `<KeyInfo />` element. This vulnerability is combination of changes introduced to `4.0.0` on pull request 301 / commit `c2b83f98` and has been addressed in version 6.0.0 with pull request 445 / commit `21201723d`. Users are advised to upgrade. Users unable to upgrade may either check the certificate extracted via `getCertFromKeyInfo` against trusted certificates before accepting the results of the validation or set `xml-crypto's getCertFromKeyInfo` to `() => undefined` forcing `xml-crypto` to use an explicitly configured `publicCert` or `privateKey` for signature verification. | ||||