Total
425 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-21134 | 1 Reolink | 2 Rlc-410w, Rlc-410w Firmware | 2022-07-01 | 5.0 MEDIUM | 7.5 HIGH |
| A firmware update vulnerability exists in the "update" firmware checks functionality of reolink RLC-410W v3.0.0.136_20121102. A specially-crafted HTTP request can lead to firmware update. An attacker can send a sequence of requests to trigger this vulnerability. | |||||
| CVE-2018-5387 | 1 Wizkunde | 1 Samlbase | 2022-06-01 | 5.0 MEDIUM | 7.5 HIGH |
| Wizkunde SAMLBase may incorrectly utilize the results of XML DOM traversal and canonicalization APIs in such a way that an attacker may be able to manipulate the SAML data without invalidating the cryptographic signature, allowing the attack to potentially bypass authentication to SAML service providers. | |||||
| CVE-2022-26510 | 1 Inhandnetworks | 2 Ir302, Ir302 Firmware | 2022-05-23 | 4.0 MEDIUM | 6.5 MEDIUM |
| A firmware update vulnerability exists in the iburn firmware checks functionality of InHand Networks InRouter302 V3.5.37. A specially-crafted HTTP request can lead to firmware update. An attacker can send a sequence of requests to trigger this vulnerability. | |||||
| CVE-2021-44878 | 1 Pac4j | 1 Pac4j | 2022-05-13 | 5.0 MEDIUM | 7.5 HIGH |
| If an OpenID Connect provider supports the "none" algorithm (i.e., tokens with no signature), pac4j v5.3.0 (and prior) does not refuse it without an explicit configuration on its side or for the "idtoken" response type which is not secure and violates the OpenID Core Specification. The "none" algorithm does not require any signature verification when validating the ID tokens, which allows the attacker to bypass the token validation by injecting a malformed ID token using "none" as the value of "alg" key in the header with an empty signature value. | |||||
| CVE-2021-22573 | 1 Google | 1 Oauth Client Library For Java | 2022-05-10 | 3.5 LOW | 7.3 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-2019-17561 | 2 Apache, Oracle | 2 Netbeans, Graalvm | 2022-04-27 | 5.0 MEDIUM | 7.5 HIGH |
| The "Apache NetBeans" autoupdate system does not fully validate code signatures. An attacker could modify the downloaded nbm and include additional code. "Apache NetBeans" versions up to and including 11.2 are affected by this vulnerability. | |||||
| CVE-2020-12692 | 2 Canonical, Openstack | 2 Ubuntu Linux, Keystone | 2022-04-27 | 5.5 MEDIUM | 5.4 MEDIUM |
| An issue was discovered in OpenStack Keystone before 15.0.1, and 16.0.0. The EC2 API doesn't have a signature TTL check for AWS Signature V4. An attacker can sniff the Authorization header, and then use it to reissue an OpenStack token an unlimited number of times. | |||||
| CVE-2020-25166 | 1 Bbraun | 2 Datamodule Compactplus, Spacecom | 2022-04-21 | 7.5 HIGH | 7.1 HIGH |
| An improper verification of the cryptographic signature of firmware updates of the B. Braun Melsungen AG SpaceCom Version L81/U61 and earlier, and the Data module compactplus Versions A10 and A11 allows attackers to generate valid firmware updates with arbitrary content that can be used to tamper with devices. | |||||
| CVE-2019-9149 | 1 Mailvelope | 1 Mailvelope | 2022-04-18 | 6.4 MEDIUM | 6.5 MEDIUM |
| Mailvelope prior to 3.3.0 allows private key operations without user interaction via its client-API. By modifying an URL parameter in Mailvelope, an attacker is able to sign (and encrypt) arbitrary messages with Mailvelope, assuming the private key password is cached. A second vulnerability allows an attacker to decrypt an arbitrary message when the GnuPG backend is used in Mailvelope. | |||||
| CVE-2020-15705 | 7 Canonical, Debian, Gnu and 4 more | 14 Ubuntu Linux, Debian Linux, Grub2 and 11 more | 2022-04-18 | 4.4 MEDIUM | 6.4 MEDIUM |
| GRUB2 fails to validate kernel signature when booted directly without shim, allowing secure boot to be bypassed. This only affects systems where the kernel signing certificate has been imported directly into the secure boot database and the GRUB image is booted directly without the use of shim. This issue affects GRUB2 version 2.04 and prior versions. | |||||
| 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-09 | 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-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-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. | |||||