Total
309 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2021-33885 | 1 Bbraun | 3 Infusomat Large Volume Pump 871305u, Spacecom2, Spacestation 8713142u | 2022-07-12 | 10.0 HIGH | 9.8 CRITICAL |
An Insufficient Verification of Data Authenticity vulnerability in B. Braun SpaceCom2 prior to 012U000062 allows a remote unauthenticated attacker to send the device malicious data that will be used in place of the correct data. This results in full system command access and execution because of the lack of cryptographic signatures on critical data sets. | |||||
CVE-2021-26100 | 1 Fortinet | 1 Fortimail | 2022-07-12 | 5.0 MEDIUM | 7.5 HIGH |
A missing cryptographic step in the Identity-Based Encryption service of FortiMail before 7.0.0 may allow an unauthenticated attacker who intercepts the encrypted messages to manipulate them in such a way that makes the tampering and the recovery of the plaintexts possible. | |||||
CVE-2021-37927 | 1 Zohocorp | 1 Manageengine Admanager Plus | 2022-07-12 | 7.5 HIGH | 9.8 CRITICAL |
Zoho ManageEngine ADManager Plus version 7110 and prior allows account takeover via SSO. | |||||
CVE-2021-32738 | 1 Stellar | 1 Js-stellar-sdk | 2022-07-02 | 4.0 MEDIUM | 6.5 MEDIUM |
js-stellar-sdk is a Javascript library for communicating with a Stellar Horizon server. The `Utils.readChallengeTx` function used in SEP-10 Stellar Web Authentication states in its function documentation that it reads and validates the challenge transaction including verifying that the `serverAccountID` has signed the transaction. In js-stellar-sdk before version 8.2.3, the function does not verify that the server has signed the transaction. Applications that also used `Utils.verifyChallengeTxThreshold` or `Utils.verifyChallengeTxSigners` to verify the signatures including the server signature on the challenge transaction are unaffected as those functions verify the server signed the transaction. Applications calling `Utils.readChallengeTx` should update to version 8.2.3, the first version with a patch for this vulnerability, to ensure that the challenge transaction is completely valid and signed by the server creating the challenge transaction. | |||||
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-2021-22160 | 1 Apache | 1 Pulsar | 2022-06-03 | 7.5 HIGH | 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-3421 | 3 Fedoraproject, Redhat, Rpm | 3 Fedora, Enterprise Linux, Rpm | 2022-06-03 | 4.3 MEDIUM | 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-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-2022-24884 | 3 Debian, Ecdsautils Project, Fedoraproject | 3 Debian Linux, Ecdsautils, Fedora | 2022-05-16 | 5.0 MEDIUM | 7.5 HIGH |
ecdsautils is a tiny collection of programs used for ECDSA (keygen, sign, verify). `ecdsa_verify_[prepare_]legacy()` does not check whether the signature values `r` and `s` are non-zero. A signature consisting only of zeroes is always considered valid, making it trivial to forge signatures. Requiring multiple signatures from different public keys does not mitigate the issue: `ecdsa_verify_list_legacy()` will accept an arbitrary number of such forged signatures. Both the `ecdsautil verify` CLI command and the libecdsautil library are affected. The issue has been fixed in ecdsautils 0.4.1. All older versions of ecdsautils (including versions before the split into a library and a CLI utility) are vulnerable. | |||||
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-11841 | 2 Debian, Golang | 2 Debian Linux, Crypto | 2022-05-03 | 4.3 MEDIUM | 5.9 MEDIUM |
A message-forgery issue was discovered in crypto/openpgp/clearsign/clearsign.go in supplementary Go cryptography libraries 2019-03-25. According to the OpenPGP Message Format specification in RFC 4880 chapter 7, a cleartext signed message can contain one or more optional "Hash" Armor Headers. The "Hash" Armor Header specifies the message digest algorithm(s) used for the signature. However, the Go clearsign package ignores the value of this header, which allows an attacker to spoof it. Consequently, an attacker can lead a victim to believe the signature was generated using a different message digest algorithm than what was actually used. Moreover, since the library skips Armor Header parsing in general, an attacker can not only embed arbitrary Armor Headers, but also prepend arbitrary text to cleartext messages without invalidating the signatures. | |||||
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-12244 | 4 Debian, Fedoraproject, Opensuse and 1 more | 5 Debian Linux, Fedora, Backports Sle and 2 more | 2022-04-26 | 5.0 MEDIUM | 7.5 HIGH |
An issue has been found in PowerDNS Recursor 4.1.0 through 4.3.0 where records in the answer section of a NXDOMAIN response lacking an SOA were not properly validated in SyncRes::processAnswer, allowing an attacker to bypass DNSSEC validation. | |||||
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-2018-10470 | 2 Apple, Objective Development | 2 Macos, Little Snitch | 2022-04-18 | 5.0 MEDIUM | 5.3 MEDIUM |
Little Snitch versions 4.0 to 4.0.6 use the SecStaticCodeCheckValidityWithErrors() function without the kSecCSCheckAllArchitectures flag and therefore do not validate all architectures stored in a fat binary. An attacker can maliciously craft a fat binary containing multiple architectures that may cause a situation where Little Snitch treats the running process as having no code signature at all while erroneously indicating that the binary on disk does have a valid code signature. This could lead to users being confused about whether or not the code signature is valid. | |||||
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. |