Total
364 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-23928 | 1 Reason-jose Project | 1 Reason-jose | 2023-12-10 | N/A | 9.8 CRITICAL |
| reason-jose is a JOSE implementation in ReasonML and OCaml.`Jose.Jws.validate` does not check HS256 signatures. This allows tampering of JWS header and payload data if the service does not perform additional checks. Such tampering could expose applications using reason-jose to authorization bypass. Applications relying on JWS claims assertion to enforce security boundaries may be vulnerable to privilege escalation. This issue has been patched in version 0.8.2. | |||||
| CVE-2022-23540 | 1 Auth0 | 1 Jsonwebtoken | 2023-12-10 | N/A | 7.6 HIGH |
| In versions `<=8.5.1` of `jsonwebtoken` library, lack of algorithm definition in the `jwt.verify()` function can lead to signature validation bypass due to defaulting to the `none` algorithm for signature verification. Users are affected if you do not specify algorithms in the `jwt.verify()` function. This issue has been fixed, please update to version 9.0.0 which removes the default support for the none algorithm in the `jwt.verify()` method. There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the `none` algorithm. If you need 'none' algorithm, you have to explicitly specify that in `jwt.verify()` options. | |||||
| CVE-2022-3322 | 1 Cloudflare | 1 Warp Mobile Client | 2023-12-10 | N/A | 7.5 HIGH |
| Lock Warp switch is a feature of Zero Trust platform which, when enabled, prevents users of enrolled devices from disabling WARP client. Due to insufficient policy verification by WARP iOS client, this feature could be bypassed by using the "Disable WARP" quick action. | |||||
| CVE-2022-35930 | 1 Sigstore | 1 Policy Controller | 2023-12-10 | N/A | 8.8 HIGH |
| PolicyController is a utility used to enforce supply chain policy in Kubernetes clusters. In versions prior to 0.2.1 PolicyController will report a false positive, resulting in an admission when it should not be admitted when there is at least one attestation with a valid signature and there are NO attestations of the type being verified (--type defaults to "custom"). An example image that can be used to test this is `ghcr.io/distroless/static@sha256:dd7614b5a12bc4d617b223c588b4e0c833402b8f4991fb5702ea83afad1986e2`. Users should upgrade to version 0.2.1 to resolve this issue. There are no workarounds for users unable to upgrade. | |||||
| CVE-2022-39299 | 1 Passport-saml Project | 1 Passport-saml | 2023-12-10 | N/A | 8.1 HIGH |
| Passport-SAML is a SAML 2.0 authentication provider for Passport, the Node.js authentication library. A remote attacker may be able to bypass SAML authentication on a website using passport-saml. A successful attack requires that the attacker is in possession of an arbitrary IDP signed XML element. Depending on the IDP used, fully unauthenticated attacks (e.g without access to a valid user) might also be feasible if generation of a signed message can be triggered. Users should upgrade to passport-saml version 3.2.2 or newer. The issue was also present in the beta releases of `node-saml` before version 4.0.0-beta.5. If you cannot upgrade, disabling SAML authentication may be done as a workaround. | |||||
| CVE-2022-25898 | 1 Jsrsasign Project | 1 Jsrsasign | 2023-12-10 | 7.5 HIGH | 9.8 CRITICAL |
| The package jsrsasign before 10.5.25 are vulnerable to Improper Verification of Cryptographic Signature when JWS or JWT signature with non Base64URL encoding special characters or number escaped characters may be validated as valid by mistake. Workaround: Validate JWS or JWT signature if it has Base64URL and dot safe string before executing JWS.verify() or JWS.verifyJWT() method. | |||||
| CVE-2022-31123 | 2 Grafana, Netapp | 2 Grafana, E-series Performance Analyzer | 2023-12-10 | N/A | 7.8 HIGH |
| Grafana is an open source observability and data visualization platform. Versions prior to 9.1.8 and 8.5.14 are vulnerable to a bypass in the plugin signature verification. An attacker can convince a server admin to download and successfully run a malicious plugin even though unsigned plugins are not allowed. Versions 9.1.8 and 8.5.14 contain a patch for this issue. As a workaround, do not install plugins downloaded from untrusted sources. | |||||
| CVE-2022-42793 | 1 Apple | 3 Ipados, Iphone Os, Macos | 2023-12-10 | N/A | 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. | |||||
| CVE-2022-31207 | 1 Omron | 14 Cp1w-cif41, Cp1w-cif41 Firmware, Sysmac Cj2h and 11 more | 2023-12-10 | N/A | 9.8 CRITICAL |
| The Omron SYSMAC Cx product family PLCs (CS series, CJ series, and CP series) through 2022-05-18 lack cryptographic authentication. They utilize the Omron FINS (9600/TCP) protocol for engineering purposes, including downloading projects and control logic to the PLC. This protocol has authentication flaws as reported in FSCT-2022-0057. Control logic is downloaded to PLC volatile memory using the FINS Program Area Read and Program Area Write commands or to non-volatile memory using other commands from where it can be loaded into volatile memory for execution. The logic that is loaded into and executed from the user program area exists in compiled object code form. Upon execution, these object codes are first passed to a dedicated ASIC that determines whether the object code is to be executed by the ASIC or the microprocessor. In the former case, the object code is interpreted by the ASIC whereas in the latter case the object code is passed to the microprocessor for object code interpretation by a ROM interpreter. In the abnormal case where the object code cannot be handled by either, an abnormal condition is triggered and the PLC is halted. The logic that is downloaded to the PLC does not seem to be cryptographically authenticated, thus allowing an attacker to manipulate transmitted object code to the PLC and either execute arbitrary object code commands on the ASIC or on the microprocessor interpreter. | |||||
| CVE-2021-35097 | 1 Qualcomm | 258 Aqt1000, Aqt1000 Firmware, Ar8031 and 255 more | 2023-12-10 | N/A | 6.8 MEDIUM |
| Possible authentication bypass due to improper order of signature verification and hashing in the signature verification call in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables | |||||
| CVE-2021-35113 | 1 Qualcomm | 96 Aqt1000, Aqt1000 Firmware, Csrb31024 and 93 more | 2023-12-10 | N/A | 6.8 MEDIUM |
| Possible authentication bypass due to improper order of signature verification and hashing in the signature verification call in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables | |||||
| CVE-2021-40326 | 2 Foxit, Microsoft | 4 Pdf Editor, Pdf Reader, Phantompdf and 1 more | 2023-12-10 | N/A | 5.5 MEDIUM |
| Foxit PDF Reader before 11.1 and PDF Editor before 11.1, and PhantomPDF before 10.1.6, mishandle hidden and incremental data in signed documents. An attacker can write to an arbitrary file, and display controlled contents, during signature verification. | |||||
| CVE-2022-31206 | 1 Omron | 50 Nj101-1000, Nj101-1000 Firmware, Nj101-1020 and 47 more | 2023-12-10 | N/A | 9.8 CRITICAL |
| The Omron SYSMAC Nx product family PLCs (NJ series, NY series, NX series, and PMAC series) through 2022-005-18 lack cryptographic authentication. These PLCs are programmed using the SYMAC Studio engineering software (which compiles IEC 61131-3 conformant POU code to native machine code for execution by the PLC's runtime). The resulting machine code is executed by a runtime, typically controlled by a real-time operating system. The logic that is downloaded to the PLC does not seem to be cryptographically authenticated, allowing an attacker to manipulate transmitted object code to the PLC and execute arbitrary machine code on the processor of the PLC's CPU module in the context of the runtime. In the case of at least the NJ series, an RTOS and hardware combination is used that would potentially allow for memory protection and privilege separation and thus limit the impact of code execution. However, it was not confirmed whether these sufficiently segment the runtime from the rest of the RTOS. | |||||
| CVE-2022-31156 | 1 Gradle | 1 Gradle | 2023-12-10 | N/A | 4.4 MEDIUM |
| Gradle is a build tool. Dependency verification is a security feature in Gradle Build Tool that was introduced to allow validation of external dependencies either through their checksum or cryptographic signatures. In versions 6.2 through 7.4.2, there are some cases in which Gradle may skip that verification and accept a dependency that would otherwise fail the build as an untrusted external artifact. This can occur in two ways. When signature verification is disabled but the verification metadata contains entries for dependencies that only have a `gpg` element but no `checksum` element. When signature verification is enabled, the verification metadata contains entries for dependencies with a `gpg` element but there is no signature file on the remote repository. In both cases, the verification will accept the dependency, skipping signature verification and not complaining that the dependency has no checksum entry. For builds that are vulnerable, there are two risks. Gradle could download a malicious binary from a repository outside your organization due to name squatting. For those still using HTTP only and not HTTPS for downloading dependencies, the build could download a malicious library instead of the expected one. Gradle 7.5 patches this issue by making sure to run checksum verification if signature verification cannot be completed, whatever the reason. Two workarounds are available: Remove all `gpg` elements from dependency verification metadata if you disable signature validation and/or avoid adding `gpg` entries for dependencies that do not have signature files. | |||||
| CVE-2022-39200 | 1 Matrix | 1 Dendrite | 2023-12-10 | N/A | 5.3 MEDIUM |
| Dendrite is a Matrix homeserver written in Go. In affected versions events retrieved from a remote homeserver using the `/get_missing_events` path did not have their signatures verified correctly. This could potentially allow a remote homeserver to provide invalid/modified events to Dendrite via this endpoint. Note that this does not apply to events retrieved through other endpoints (e.g. `/event`, `/state`) as they have been correctly verified. Homeservers that have federation disabled are not vulnerable. The problem has been fixed in Dendrite 0.9.8. Users are advised to upgrade. There are no known workarounds for this issue. | |||||
| CVE-2022-35929 | 1 Sigstore | 1 Cosign | 2023-12-10 | N/A | 9.8 CRITICAL |
| cosign is a container signing and verification utility. In versions prior to 1.10.1 cosign can report a false positive if any attestation exists. `cosign verify-attestation` used with the `--type` flag will report a false positive verification when there is at least one attestation with a valid signature and there are NO attestations of the type being verified (--type defaults to "custom"). This can happen when signing with a standard keypair and with "keyless" signing with Fulcio. This vulnerability can be reproduced with the `distroless.dev/static@sha256:dd7614b5a12bc4d617b223c588b4e0c833402b8f4991fb5702ea83afad1986e2` image. This image has a `vuln` attestation but not an `spdx` attestation. However, if you run `cosign verify-attestation --type=spdx` on this image, it incorrectly succeeds. This issue has been addressed in version 1.10.1 of cosign. Users are advised to upgrade. There are no known workarounds for this issue. | |||||
| CVE-2022-20944 | 1 Cisco | 20 Catalyst 9200, Catalyst 9200cx, Catalyst 9200l and 17 more | 2023-12-10 | N/A | 6.8 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-28751 | 1 Zoom | 1 Meetings | 2023-12-10 | N/A | 7.8 HIGH |
| The Zoom Client for Meetings for MacOS (Standard and for IT Admin) before version 5.11.3 contains a vulnerability in the package signature validation during the update process. A local low-privileged user could exploit this vulnerability to escalate their privileges to root. | |||||
| CVE-2022-41340 | 1 Secp256k1-js Project | 1 Secp256k1-js | 2023-12-10 | N/A | 7.5 HIGH |
| The secp256k1-js package before 1.1.0 for Node.js implements ECDSA without required r and s validation, leading to signature forgery. | |||||
| CVE-2022-36056 | 1 Sigstore | 1 Cosign | 2023-12-10 | N/A | 5.5 MEDIUM |
| Cosign is a project under the sigstore organization which aims to make signatures invisible infrastructure. In versions prior to 1.12.0 a number of vulnerabilities have been found in cosign verify-blob, where Cosign would successfully verify an artifact when verification should have failed. First a cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature. Second, when providing identity flags, the email and issuer of a certificate is not checked when verifying a Rekor bundle, and the GitHub Actions identity is never checked. Third, providing an invalid Rekor bundle without the experimental flag results in a successful verification. And fourth an invalid transparency log entry will result in immediate success for verification. Details and examples of these issues can be seen in the GHSA-8gw7-4j42-w388 advisory linked. Users are advised to upgrade to 1.12.0. There are no known workarounds for these issues. | |||||