| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Authorization headers are cleared on cross-origin redirect. However, cookie headers which are sensitive headers and are official headers found in the spec, remain uncleared. There are active users using cookie headers in undici. This may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site. This was patched in v5.7.1. By default, this vulnerability is not exploitable. Do not enable redirections, i.e. `maxRedirections: 0` (the default). |
| 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. |
| 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. |
| MeshCentral is a full computer management web site. Versions prior to 1.1.21 a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. The vulnerability is exploitable when an attacker is able to convince a victim end-user to click on a malicious link to a page hosting an attacker-controlled site. The attacker can then originate a cross-site websocket connection using client-side JavaScript code to connect to `control.ashx` as the victim user within MeshCentral. Version 1.1.21 contains a patch for this issue. |
| 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. |
| immudb is a database with built-in cryptographic proof and verification. In versions prior to 1.4.1, a malicious immudb server can provide a falsified proof that will be accepted by the client SDK signing a falsified transaction replacing the genuine one. This situation can not be triggered by a genuine immudb server and requires the client to perform a specific list of verified operations resulting in acceptance of an invalid state value. This vulnerability only affects immudb client SDKs, the immudb server itself is not affected by this vulnerability. This issue has been patched in version 1.4.1. |
| A vulnerability identified in the Tailscale Windows client allows a malicious website to reconfigure the Tailscale daemon `tailscaled`, which can then be used to remotely execute code. In the Tailscale Windows client, the local API was bound to a local TCP socket, and communicated with the Windows client GUI in cleartext with no Host header verification. This allowed an attacker-controlled website visited by the node to rebind DNS to an attacker-controlled DNS server, and then make local API requests in the client, including changing the coordination server to an attacker-controlled coordination server. An attacker-controlled coordination server can send malicious URL responses to the client, including pushing executables or installing an SMB share. These allow the attacker to remotely execute code on the node. All Windows clients prior to version v.1.32.3 are affected. If you are running Tailscale on Windows, upgrade to v1.32.3 or later to remediate the issue. |
| A validation integrity issue was discovered in Fort through 1.6.4 before 2.0.0. RPKI manifests are listings of relevant files that clients are supposed to verify. Assuming everything else is correct, the most recent version of a manifest should be prioritized over other versions, to prevent replays, accidental or otherwise. Manifests contain the manifestNumber and thisUpdate fields, which can be used to gauge the relevance of a given manifest, when compared to other manifests. The former is a serial-like sequential number, and the latter is the date on which the manifest was created. However, the product does not compare the up-to-dateness of the most recently fetched manifest against the cached manifest. As such, it's prone to a rollback to a previous version if it's served a valid outdated manifest. This leads to outdated route origin validation. |
| An issue was discovered in Technitium through 11.0.3. It enables attackers to conduct a DNS cache poisoning attack and inject fake responses within 1 second, which is impactful. |
| Inappropriate implementation in Navigations in Google Chrome prior to 135.0.7049.52 allowed a remote attacker who convinced a user to engage in specific UI gestures to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low) |
| A logic issue was addressed with improved state management. This issue is fixed in Safari 16.2, tvOS 16.2, iCloud for Windows 14.1, iOS 15.7.2 and iPadOS 15.7.2, macOS Ventura 13.1, iOS 16.2 and iPadOS 16.2, watchOS 9.2. Processing maliciously crafted web content may bypass Same Origin Policy. |
| SSL.com before 2025-04-19, when domain validation method 3.2.2.4.14 is used, processes certificate requests such that a trusted TLS certificate may be issued for the domain name of a requester's email address, even when the requester does not otherwise establish administrative control of that domain. |
| 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 |
| The Good for Enterprise application 3.0.0.415 for Android does not use signature protection for its Authentication Delegation API intent. Also, the Good Dynamic application activation process does not attempt to detect malicious activation attempts involving modified names beginning with a com.good.gdgma substring. Consequently, an attacker could obtain access to intranet data. This issue is only relevant in cases where the user has already downloaded a malicious Android application. |
| Infotecs ViPNet Client and Coordinator before 4.3.2-42442 allow local users to gain privileges by placing a Trojan horse ViPNet update file in the update folder. The attack succeeds because of incorrect folder permissions in conjunction with a lack of integrity and authenticity checks. |
| Microsoft Edge in Microsoft Windows 10 1703 allows an attacker to exploit a security feature bypass due to Microsoft Edge not properly enforcing same-origin policies, aka "Microsoft Edge Security Feature Bypass Vulnerability". |
| Microsoft Edge in Microsoft Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows an attacker to trick a user into loading a page with malicious content when Microsoft Edge does not properly enforce same-origin policies, aka "Microsoft Edge Security Feature Bypass Vulnerability". This CVE ID is unique from CVE-2017-8523 and CVE-2017-8555. |
| FusionSphere OpenStack V100R006C00SPC102(NFV)has an improper verification of cryptographic signature vulnerability. The software does not verify the cryptographic signature. An attacker with high privilege may exploit this vulnerability to inject malicious software. |
| Huawei APP HiWallet earlier than 5.0.3.100 versions do not support signature verification for APK file. An attacker could exploit this vulnerability to hijack the APK and upload modified APK file. Successful exploit could lead to the APP is hijacking. |
| The CORS Filter in Apache Tomcat 9.0.0.M1 to 9.0.0.M21, 8.5.0 to 8.5.15, 8.0.0.RC1 to 8.0.44 and 7.0.41 to 7.0.78 did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances. |
