Total
309 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2021-32977 | 1 Aveva | 1 System Platform | 2022-04-13 | 6.5 MEDIUM | 7.2 HIGH |
| AVEVA System Platform versions 2017 through 2020 R2 P01 does not verify, or incorrectly verifies, the cryptographic signature for data. | |||||
| CVE-2021-30066 | 2 Belden, Schneider-electric | 26 Eagle 20 Tofino 943 987-501-tx\/tx, Eagle 20 Tofino 943 987-501-tx\/tx Firmware, Eagle 20 Tofino 943 987-502 -tx\/mm and 23 more | 2022-04-08 | 7.2 HIGH | 6.8 MEDIUM |
| On Schneider Electric ConneXium Tofino Firewall TCSEFEA23F3F22 before 03.23, TCSEFEA23F3F20/21, and Belden Tofino Xenon Security Appliance, an arbitrary firmware image can be loaded because firmware signature verification (for a USB stick) can be bypassed. NOTE: this issue exists because of an incomplete fix of CVE-2017-11400. | |||||
| CVE-2015-3298 | 1 Yubico | 1 Ykneo-openpgp | 2022-04-08 | 5.8 MEDIUM | 8.8 HIGH |
| Yubico ykneo-openpgp before 1.0.10 has a typo in which an invalid PIN can be used. When first powered up, a signature will be issued even though the PIN has not been validated. | |||||
| CVE-2017-5066 | 5 Apple, Google, Linux and 2 more | 8 Macos, Android, Chrome and 5 more | 2022-04-08 | 4.3 MEDIUM | 6.5 MEDIUM |
| Insufficient consistency checks in signature handling in the networking stack in Google Chrome prior to 58.0.3029.81 for Mac, Windows, and Linux, and 58.0.3029.83 for Android, allowed a remote attacker to incorrectly accept a badly formed X.509 certificate via a crafted HTML page. | |||||
| CVE-2022-22934 | 1 Saltstack | 1 Salt | 2022-04-06 | 5.8 MEDIUM | 8.8 HIGH |
| An issue was discovered in SaltStack Salt in versions before 3002.8, 3003.4, 3004.1. Salt Masters do not sign pillar data with the minion’s public key, which can result in attackers substituting arbitrary pillar data. | |||||
| CVE-2020-14365 | 2 Debian, Redhat | 5 Debian Linux, Ansible Engine, Ansible Tower and 2 more | 2022-04-05 | 6.6 MEDIUM | 7.1 HIGH |
| A flaw was found in the Ansible Engine, in ansible-engine 2.8.x before 2.8.15 and ansible-engine 2.9.x before 2.9.13, when installing packages using the dnf module. GPG signatures are ignored during installation even when disable_gpg_check is set to False, which is the default behavior. This flaw leads to malicious packages being installed on the system and arbitrary code executed via package installation scripts. The highest threat from this vulnerability is to integrity and system availability. | |||||
| CVE-2020-16156 | 2 Fedoraproject, Perl | 2 Fedora, Comprehensive Perl Archive Network | 2022-04-01 | 6.8 MEDIUM | 7.8 HIGH |
| CPAN 2.28 allows Signature Verification Bypass. | |||||
| CVE-2021-33054 | 2 Debian, Inverse | 2 Debian Linux, Sogo | 2022-03-29 | 5.0 MEDIUM | 7.5 HIGH |
| SOGo 2.x before 2.4.1 and 3.x through 5.x before 5.1.1 does not validate the signatures of any SAML assertions it receives. Any actor with network access to the deployment could impersonate users when SAML is the authentication method. (Only versions after 2.0.5a are affected.) | |||||
| CVE-2022-23610 | 1 Wire | 1 Wire-server | 2022-03-28 | 5.1 MEDIUM | 8.1 HIGH |
| wire-server provides back end services for Wire, an open source messenger. In versions of wire-server prior to the 2022-01-27 release, it was possible to craft DSA Signatures to bypass SAML SSO and impersonate any Wire user with SAML credentials. In teams with SAML, but without SCIM, it was possible to create new accounts with fake SAML credentials. Under certain conditions that can be established by an attacker, an upstream library for parsing, rendering, signing, and validating SAML XML data was accepting public keys as trusted that were provided by the attacker in the signature. As a consequence, the attacker could login as any user in any Wire team with SAML SSO enabled. If SCIM was not enabled, the attacker could also create new users with new SAML NameIDs. In order to exploit this vulnerability, the attacker needs to know the SSO login code (distributed to all team members with SAML credentials and visible in the Team Management app), the SAML EntityID identifying the IdP (a URL not considered sensitive, but usually hard to guess, also visible in Team Management), and the SAML NameID of the user (usually an email address or a nick). The issue has been fixed in wire-server `2022-01-27` and is already deployed on all Wire managed services. On premise instances of wire-server need to be updated to `2022-01-27`, so that their backends are no longer affected. There are currently no known workarounds. More detailed information about how to reproduce the vulnerability and mitigation strategies is available in the GitHub Security Advisory. | |||||
| CVE-2022-24773 | 1 Digitalbazaar | 1 Forge | 2022-03-28 | 5.0 MEDIUM | 5.3 MEDIUM |
| Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.3.0, RSA PKCS#1 v1.5 signature verification code does not properly check `DigestInfo` for a proper ASN.1 structure. This can lead to successful verification with signatures that contain invalid structures but a valid digest. The issue has been addressed in `node-forge` version 1.3.0. There are currently no known workarounds. | |||||
| CVE-2022-24772 | 1 Digitalbazaar | 1 Forge | 2022-03-28 | 5.0 MEDIUM | 7.5 HIGH |
| Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.3.0, RSA PKCS#1 v1.5 signature verification code does not check for tailing garbage bytes after decoding a `DigestInfo` ASN.1 structure. This can allow padding bytes to be removed and garbage data added to forge a signature when a low public exponent is being used. The issue has been addressed in `node-forge` version 1.3.0. There are currently no known workarounds. | |||||
| CVE-2022-24771 | 1 Digitalbazaar | 1 Forge | 2022-03-28 | 5.0 MEDIUM | 7.5 HIGH |
| Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.3.0, RSA PKCS#1 v1.5 signature verification code is lenient in checking the digest algorithm structure. This can allow a crafted structure that steals padding bytes and uses unchecked portion of the PKCS#1 encoded message to forge a signature when a low public exponent is being used. The issue has been addressed in `node-forge` version 1.3.0. There are currently no known workarounds. | |||||
| CVE-2021-43572 | 1 Starkbank | 1 Ecdsa-python | 2022-03-24 | 7.5 HIGH | 9.8 CRITICAL |
| The verify function in the Stark Bank Python ECDSA library (aka starkbank-escada or ecdsa-python) before 2.0.1 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages. | |||||
| CVE-2022-24759 | 1 Chainsafe | 1 Js-libp2p-noise | 2022-03-23 | 5.8 MEDIUM | 7.4 HIGH |
| `@chainsafe/libp2p-noise` contains TypeScript implementation of noise protocol, an encryption protocol used in libp2p. `@chainsafe/libp2p-noise` before 4.1.2 and 5.0.3 does not correctly validate signatures during the handshake process. This may allow a man-in-the-middle to pose as other peers and get those peers banned. Users should upgrade to version 4.1.2 or 5.0.3 to receive a patch. There are currently no known workarounds. | |||||
| CVE-2021-20319 | 1 Redhat | 1 Coreos-installer | 2022-03-11 | 6.8 MEDIUM | 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-43393 | 1 St | 4 J-safe3, J-safe3 Firmware, Stsafe-j and 1 more | 2022-03-10 | 1.9 LOW | 6.2 MEDIUM |
| STMicroelectronics STSAFE-J 1.1.4, J-SAFE3 1.2.5, and J-SIGN sometimes allow attackers to abuse signature verification. This is associated with the ECDSA signature algorithm on the Java Card J-SAFE3 and STSAFE-J platforms exposing a 3.0.4 Java Card API. It is exploitable for STSAFE-J in closed configuration and J-SIGN (when signature verification is activated) but not for J-SAFE3 EPASS BAC and EAC products. It might also impact other products based on the J-SAFE-3 Java Card platform. | |||||
| CVE-2021-43392 | 1 St | 4 J-safe3, J-safe3 Firmware, Stsafe-j and 1 more | 2022-03-10 | 1.9 LOW | 6.2 MEDIUM |
| STMicroelectronics STSAFE-J 1.1.4, J-SAFE3 1.2.5, and J-SIGN sometimes allow attackers to obtain information on cryptographic secrets. This is associated with the ECDSA signature algorithm on the Java Card J-SAFE3 and STSAFE-J platforms exposing a 3.0.4 Java Card API. It is exploitable for STSAFE-J in closed configuration and J-SIGN (when signature verification is activated) but not for J-SAFE3 EPASS BAC and EAC products. It might also impact other products based on the J-SAFE-3 Java Card platform. | |||||
| CVE-2022-23655 | 1 Octobercms | 1 October | 2022-03-07 | 2.6 LOW | 5.3 MEDIUM |
| Octobercms is a self-hosted CMS platform based on the Laravel PHP Framework. Affected versions of OctoberCMS did not validate gateway server signatures. As a result non-authoritative gateway servers may be used to exfiltrate user private keys. Users are advised to upgrade their installations to build 474 or v1.1.10. The only known workaround is to manually apply the patch (e3b455ad587282f0fbcb7763c6d9c3d000ca1e6a) which adds server signature validation. | |||||
| CVE-2020-16154 | 2 App\, Fedoraproject | 2 \, Fedora | 2022-03-01 | 6.8 MEDIUM | 7.8 HIGH |
| The App::cpanminus package 1.7044 for Perl allows Signature Verification Bypass. | |||||
| CVE-2021-3445 | 3 Fedoraproject, Redhat, Rpm | 3 Fedora, Enterprise Linux, Libdnf | 2022-02-24 | 5.1 MEDIUM | 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. | |||||