Total
468 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-22708 | 1 Schneider-electric | 12 Evlink City Evc1s22p4, Evlink City Evc1s22p4 Firmware, Evlink City Evc1s7p4 and 9 more | 2024-08-03 | 7.2 High |
| A CWE-347: Improper Verification of Cryptographic Signature vulnerability exists in EVlink City (EVC1S22P4 / EVC1S7P4 all versions prior to R8 V3.4.0.1), EVlink Parking (EVW2 / EVF2 / EV.2 all versions prior to R8 V3.4.0.1), and EVlink Smart Wallbox (EVB1A all versions prior to R8 V3.4.0.1 ) that could allow an attacker to craft a malicious firmware package and bypass the signature verification mechanism. | ||||
| CVE-2021-22573 | 2 Google, Redhat | 3 Oauth Client Library For Java, Camel Spring Boot, Jboss Fuse | 2024-08-03 | 8.7 High |
| The vulnerability is that IDToken verifier does not verify if token is properly signed. Signature verification makes sure that the token's payload comes from valid provider, not from someone else. An attacker can provide a compromised token with custom payload. The token will pass the validation on the client side. We recommend upgrading to version 1.33.3 or above | ||||
| CVE-2021-22160 | 1 Apache | 1 Pulsar | 2024-08-03 | 9.8 Critical |
| If Apache Pulsar is configured to authenticate clients using tokens based on JSON Web Tokens (JWT), the signature of the token is not validated if the algorithm of the presented token is set to "none". This allows an attacker to connect to Pulsar instances as any user (incl. admins). | ||||
| CVE-2021-21405 | 1 Filecoin | 1 Lotus | 2024-08-03 | 5.9 Medium |
| Lotus is an Implementation of the Filecoin protocol written in Go. BLS signature validation in lotus uses blst library method VerifyCompressed. This method accepts signatures in 2 forms: "serialized", and "compressed", meaning that BLS signatures can be provided as either of 2 unique byte arrays. Lotus block validation functions perform a uniqueness check on provided blocks. Two blocks are considered distinct if the CIDs of their blockheader do not match. The CID method for blockheader includes the BlockSig of the block. The result of these issues is that it would be possible to punish miners for valid blocks, as there are two different valid block CIDs available for each block, even though this must be unique. By switching from the go based `blst` bindings over to the bindings in `filecoin-ffi`, the code paths now ensure that all signatures are compressed by size and the way they are deserialized. This happened in https://github.com/filecoin-project/lotus/pull/5393. | ||||
| CVE-2021-21238 | 1 Pysaml2 Project | 1 Pysaml2 | 2024-08-03 | 6.5 Medium |
| PySAML2 is a pure python implementation of SAML Version 2 Standard. PySAML2 before 6.5.0 has an improper verification of cryptographic signature vulnerability. All users of pysaml2 that need to validate signed SAML documents are impacted. The vulnerability is a variant of XML Signature wrapping because it did not validate the SAML document against an XML schema. This allowed invalid XML documents to be processed and such a document can trick pysaml2 with a wrapped signature. This is fixed in PySAML2 6.5.0. | ||||
| CVE-2021-21239 | 2 Debian, Pysaml2 Project | 2 Debian Linux, Pysaml2 | 2024-08-03 | 6.5 Medium |
| PySAML2 is a pure python implementation of SAML Version 2 Standard. PySAML2 before 6.5.0 has an improper verification of cryptographic signature vulnerability. Users of pysaml2 that use the default CryptoBackendXmlSec1 backend and need to verify signed SAML documents are impacted. PySAML2 does not ensure that a signed SAML document is correctly signed. The default CryptoBackendXmlSec1 backend is using the xmlsec1 binary to verify the signature of signed SAML documents, but by default xmlsec1 accepts any type of key found within the given document. xmlsec1 needs to be configured explicitly to only use only _x509 certificates_ for the verification process of the SAML document signature. This is fixed in PySAML2 6.5.0. | ||||
| CVE-2021-20319 | 1 Redhat | 2 Coreos-installer, Openshift | 2024-08-03 | 7.8 High |
| An improper signature verification vulnerability was found in coreos-installer. A specially crafted gzip installation image can bypass the image signature verification and as a consequence can lead to the installation of unsigned content. An attacker able to modify the original installation image can write arbitrary data, and achieve full access to the node being installed. | ||||
| CVE-2021-20156 | 1 Trendnet | 2 Tew-827dru, Tew-827dru Firmware | 2024-08-03 | 6.5 Medium |
| Trendnet AC2600 TEW-827DRU version 2.08B01 contains an improper access control configuration that could allow for a malicious firmware update. It is possible to manually install firmware that may be malicious in nature as there does not appear to be any signature validation done to determine if it is from a known and trusted source. This includes firmware updates that are done via the automated "check for updates" in the admin interface. If an attacker is able to masquerade as the update server, the device will not verify that the firmware updates downloaded are legitimate. | ||||
| CVE-2021-3680 | 1 Showdoc | 1 Showdoc | 2024-08-03 | 4.9 Medium |
| showdoc is vulnerable to Missing Cryptographic Step | ||||
| CVE-2021-3521 | 2 Redhat, Rpm | 3 Enterprise Linux, Rhel Eus, Rpm | 2024-08-03 | 4.7 Medium |
| There is a flaw in RPM's signature functionality. OpenPGP subkeys are associated with a primary key via a "binding signature." RPM does not check the binding signature of subkeys prior to importing them. If an attacker is able to add or socially engineer another party to add a malicious subkey to a legitimate public key, RPM could wrongly trust a malicious signature. The greatest impact of this flaw is to data integrity. To exploit this flaw, an attacker must either compromise an RPM repository or convince an administrator to install an untrusted RPM or public key. It is strongly recommended to only use RPMs and public keys from trusted sources. | ||||
| CVE-2021-3633 | 1 Lenovo | 1 Drivers Management | 2024-08-03 | 7.3 High |
| A DLL preloading vulnerability was reported in Lenovo Driver Management prior to version 2.9.0719.1104 that could allow privilege escalation. | ||||
| CVE-2021-3445 | 3 Fedoraproject, Redhat, Rpm | 3 Fedora, Enterprise Linux, Libdnf | 2024-08-03 | 7.5 High |
| A flaw was found in libdnf's signature verification functionality in versions before 0.60.1. This flaw allows an attacker to achieve code execution if they can alter the header information of an RPM package and then trick a user or system into installing it. The highest risk of this vulnerability is to confidentiality, integrity, as well as system availability. | ||||
| CVE-2021-3406 | 2 Fedoraproject, Keylime | 2 Fedora, Keylime | 2024-08-03 | 9.8 Critical |
| A flaw was found in keylime 5.8.1 and older. The issue in the Keylime agent and registrar code invalidates the cryptographic chain of trust from the Endorsement Key certificate to agent attestations. | ||||
| CVE-2021-3421 | 3 Fedoraproject, Redhat, Rpm | 4 Fedora, Enterprise Linux, Rhel Eus and 1 more | 2024-08-03 | 5.5 Medium |
| A flaw was found in the RPM package in the read functionality. This flaw allows an attacker who can convince a victim to install a seemingly verifiable package or compromise an RPM repository, to cause RPM database corruption. The highest threat from this vulnerability is to data integrity. This flaw affects RPM versions before 4.17.0-alpha. | ||||
| CVE-2021-3196 | 1 Hitachi | 1 Id Bravura Security Fabric | 2024-08-03 | 8.8 High |
| An issue was discovered in Hitachi ID Bravura Security Fabric 11.0.0 through 11.1.3, 12.0.0 through 12.0.2, and 12.1.0. When using federated identity management (authenticating via SAML through a third-party identity provider), an attacker can inject additional data into a signed SAML response being transmitted to the service provider (ID Bravura Security Fabric). The application successfully validates the signed values but uses the unsigned malicious values. An attacker with lower-privilege access to the application can inject the username of a high-privilege user to impersonate that user. | ||||
| CVE-2021-1849 | 1 Apple | 5 Ipados, Iphone Os, Macos and 2 more | 2024-08-03 | 7.5 High |
| An issue in code signature validation was addressed with improved checks. This issue is fixed in macOS Big Sur 11.3, iOS 14.5 and iPadOS 14.5, watchOS 7.4, tvOS 14.5. A malicious application may be able to bypass Privacy preferences. | ||||
| CVE-2021-0152 | 1 Intel | 30 Ac1550, Ac1550 Firmware, Ac 3165 and 27 more | 2024-08-03 | 5.5 Medium |
| Improper verification of cryptographic signature in the installer for some Intel(R) Wireless Bluetooth(R) and Killer(TM) Bluetooth(R) products in Windows 10 may allow an authenticated user to potentially enable denial of service via local access. | ||||
| CVE-2022-47549 | 1 Linaro | 1 Op-tee | 2024-08-03 | 6.4 Medium |
| An unprotected memory-access operation in optee_os in TrustedFirmware Open Portable Trusted Execution Environment (OP-TEE) before 3.20 allows a physically proximate adversary to bypass signature verification and install malicious trusted applications via electromagnetic fault injections. | ||||
| CVE-2022-46176 | 1 Rust-lang | 1 Cargo | 2024-08-03 | 5.3 Medium |
| Cargo is a Rust package manager. The Rust Security Response WG was notified that Cargo did not perform SSH host key verification when cloning indexes and dependencies via SSH. An attacker could exploit this to perform man-in-the-middle (MITM) attacks. This vulnerability has been assigned CVE-2022-46176. All Rust versions containing Cargo before 1.66.1 are vulnerable. Note that even if you don't explicitly use SSH for alternate registry indexes or crate dependencies, you might be affected by this vulnerability if you have configured git to replace HTTPS connections to GitHub with SSH (through git's [`url.<base>.insteadOf`][1] setting), as that'd cause you to clone the crates.io index through SSH. Rust 1.66.1 will ensure Cargo checks the SSH host key and abort the connection if the server's public key is not already trusted. We recommend everyone to upgrade as soon as possible. | ||||
| CVE-2022-42793 | 1 Apple | 3 Ipados, Iphone Os, Macos | 2024-08-03 | 5.5 Medium |
| An issue in code signature validation was addressed with improved checks. This issue is fixed in macOS Big Sur 11.7, macOS Ventura 13, iOS 16, iOS 15.7 and iPadOS 15.7, macOS Monterey 12.6. An app may be able to bypass code signing checks. | ||||