Total
524 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-25333 | 1 Ti | 2 Omap L138, Omap L138 Firmware | 2024-11-21 | 8.2 High |
| The Texas Instruments OMAP L138 (secure variants) trusted execution environment (TEE) performs an RSA check implemented in mask ROM when loading a module through the SK_LOAD routine. However, only the module header authenticity is validated. An adversary can re-use any correctly signed header and append a forged payload, to be encrypted using the CEK (obtainable through CVE-2022-25332) in order to obtain arbitrary code execution in secure context. This constitutes a full break of the TEE security architecture. | ||||
| CVE-2022-24884 | 3 Debian, Ecdsautils Project, Fedoraproject | 3 Debian Linux, Ecdsautils, Fedora | 2024-11-21 | 10 Critical |
| 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-2022-24773 | 2 Digitalbazaar, Redhat | 5 Forge, Acm, Openshift Data Foundation and 2 more | 2024-11-21 | 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 | 2 Digitalbazaar, Redhat | 6 Forge, Acm, Jboss Enterprise Bpms Platform and 3 more | 2024-11-21 | 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 | 2 Digitalbazaar, Redhat | 6 Forge, Acm, Jboss Enterprise Bpms Platform and 3 more | 2024-11-21 | 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-2022-24759 | 1 Chainsafe | 1 Js-libp2p-noise | 2024-11-21 | 8.1 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-2022-24115 | 2 Acronis, Apple | 3 Cyber Protect Home Office, True Image, Macos | 2024-11-21 | 7.8 High |
| Local privilege escalation due to unrestricted loading of unsigned libraries. The following products are affected: Acronis Cyber Protect Home Office (macOS) before build 39605, Acronis True Image 2021 (macOS) before build 39287 | ||||
| CVE-2022-23655 | 1 Octobercms | 1 October | 2024-11-21 | 4.8 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-2022-23610 | 1 Wire | 1 Wire-server | 2024-11-21 | 9.1 Critical |
| 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-21449 | 5 Azul, Debian, Netapp and 2 more | 18 Zulu, Debian Linux, 7-mode Transition Tool and 15 more | 2024-11-21 | 7.5 High |
| Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 17.0.2 and 18; Oracle GraalVM Enterprise Edition: 21.3.1 and 22.0.0.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 7.5 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N). | ||||
| CVE-2022-20944 | 1 Cisco | 20 Catalyst 9200, Catalyst 9200cx, Catalyst 9200l and 17 more | 2024-11-21 | 6.1 Medium |
| A vulnerability in the software image verification functionality of Cisco IOS XE Software for Cisco Catalyst 9200 Series Switches could allow an unauthenticated, physical attacker to execute unsigned code at system boot time. This vulnerability is due to an improper check in the code function that manages the verification of the digital signatures of system image files during the initial boot process. An attacker could exploit this vulnerability by loading unsigned software on an affected device. A successful exploit could allow the attacker to boot a malicious software image or execute unsigned code and bypass the image verification check part of the boot process of the affected device. To exploit this vulnerability, the attacker needs either unauthenticated physical access to the device or privileged access to the root shell on the device. Note: In Cisco IOS XE Software releases 16.11.1 and later, root shell access is protected by the Consent Token mechanism. However, an attacker with level-15 privileges could easily downgrade the Cisco IOS XE Software running on a device to a release where root shell access is more readily available. | ||||
| CVE-2022-20929 | 1 Cisco | 1 Enterprise Nfv Infrastructure Software | 2024-11-21 | 7.8 High |
| A vulnerability in the upgrade signature verification of Cisco Enterprise NFV Infrastructure Software (NFVIS) could allow an unauthenticated, local attacker to provide an unauthentic upgrade file for upload. This vulnerability is due to insufficient cryptographic signature verification of upgrade files. An attacker could exploit this vulnerability by providing an administrator with an unauthentic upgrade file. A successful exploit could allow the attacker to fully compromise the Cisco NFVIS system. | ||||
| CVE-2021-44878 | 1 Pac4j | 1 Pac4j | 2024-11-21 | 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-43572 | 1 Starkbank | 1 Ecdsa-python | 2024-11-21 | 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-2021-43571 | 1 Starkbank | 1 Ecdsa-node | 2024-11-21 | 9.8 Critical |
| The verify function in the Stark Bank Node.js ECDSA library (ecdsa-node) 1.1.2 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages. | ||||
| CVE-2021-43570 | 1 Starkbank | 1 Ecdsa-java | 2024-11-21 | 9.8 Critical |
| The verify function in the Stark Bank Java ECDSA library (ecdsa-java) 1.0.0 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages. | ||||
| CVE-2021-43569 | 1 Starkbank | 1 Ecdsa-dotnet | 2024-11-21 | 9.8 Critical |
| The verify function in the Stark Bank .NET ECDSA library (ecdsa-dotnet) 1.3.1 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages. | ||||
| CVE-2021-43568 | 1 Starkbank | 1 Elixir Ecdsa | 2024-11-21 | 9.8 Critical |
| The verify function in the Stark Bank Elixir ECDSA library (ecdsa-elixir) 1.0.0 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages. | ||||
| CVE-2021-43393 | 1 St | 4 J-safe3, J-safe3 Firmware, Stsafe-j and 1 more | 2024-11-21 | 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 | 2024-11-21 | 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. | ||||