| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| @hoppscotch/cli is a CLI to run Hoppscotch Test Scripts in CI environments. Prior to 0.8.0, the @hoppscotch/js-sandbox package provides a Javascript sandbox that uses the Node.js vm module. However, the vm module is not safe for sandboxing untrusted Javascript code. This is because code inside the vm context can break out if it can get a hold of any reference to an object created outside of the vm. In the case of @hoppscotch/js-sandbox, multiple references to external objects are passed into the vm context to allow pre-request scripts interactions with environment variables and more. But this also allows the pre-request script to escape the sandbox. This vulnerability is fixed in 0.8.0. |
| The matrix-sdk-crypto crate, part of the Matrix Rust SDK project, is an implementation of a Matrix end-to-end encryption state machine in Rust. In Matrix, the server-side `key backup` stores encrypted copies of Matrix message keys. This facilitates key sharing between a user's devices and provides a redundant copy in case all devices are lost. The key backup uses asymmetric
cryptography, with each server-side key backup assigned a unique public-private key pair. Due to a logic bug introduced in commit 71136e44c03c79f80d6d1a2446673bc4d53a2067, matrix-sdk-crypto version 0.7.0 will sometimes log the private part of the backup key pair to Rust debug logs (using the `tracing` crate). This issue has been resolved in matrix-sdk-crypto version 0.7.1. No known workarounds are available. |
| llama-cpp-python is the Python bindings for llama.cpp. `llama-cpp-python` depends on class `Llama` in `llama.py` to load `.gguf` llama.cpp or Latency Machine Learning Models. The `__init__` constructor built in the `Llama` takes several parameters to configure the loading and running of the model. Other than `NUMA, LoRa settings`, `loading tokenizers,` and `hardware settings`, `__init__` also loads the `chat template` from targeted `.gguf` 's Metadata and furtherly parses it to `llama_chat_format.Jinja2ChatFormatter.to_chat_handler()` to construct the `self.chat_handler` for this model. Nevertheless, `Jinja2ChatFormatter` parse the `chat template` within the Metadate with sandbox-less `jinja2.Environment`, which is furthermore rendered in `__call__` to construct the `prompt` of interaction. This allows `jinja2` Server Side Template Injection which leads to remote code execution by a carefully constructed payload. |
| wolfictl is a command line tool for working with Wolfi. A git authentication issue in versions prior to 0.16.10 allows a local user’s GitHub token to be sent to remote servers other than `github.com`. Most git-dependent functionality in wolfictl relies on its own `git` package, which contains centralized logic for implementing interactions with git repositories. Some of this functionality requires authentication in order to access private repositories. A central function `GetGitAuth` looks for a GitHub token in the environment variable `GITHUB_TOKEN` and returns it as an HTTP basic auth object to be used with the `github.com/go-git/go-git/v5` library. Most callers (direct or indirect) of `GetGitAuth` use the token to authenticate to github.com only; however, in some cases callers were passing this authentication without checking that the remote git repository was hosted on github.com. This behavior has existed in one form or another since commit 0d06e1578300327c212dda26a5ab31d09352b9d0 - committed January 25, 2023. This impacts anyone who ran the `wolfictl check update` commands with a Melange configuration that included a `git-checkout` directive step that referenced a git repository not hosted on github.com. This also impacts anyone who ran `wolfictl update <url>` with a remote URL outside of github.com. Additionally, these subcommands must have run with the `GITHUB_TOKEN` environment variable set to a valid GitHub token. Users should upgrade to version 0.16.10 to receive a patch. |
| Minder is a software supply chain security platform. Prior to version 0.0.49, the Minder REST ingester is vulnerable to a denial of service attack via an attacker-controlled REST endpoint that can crash the Minder server. The REST ingester allows users to interact with REST endpoints to fetch data for rule evaluation. When fetching data with the REST ingester, Minder sends a request to an endpoint and will use the data from the body of the response as the data to evaluate against a certain rule. If the response is sufficiently large, it can drain memory on the machine and crash the Minder server. The attacker can control the remote REST endpoints that Minder sends requests to, and they can configure the remote REST endpoints to return responses with large bodies. They would then instruct Minder to send a request to their configured endpoint that would return the large response which would crash the Minder server. Version 0.0.49 fixes this issue. |
| Stalwart Mail Server is an open-source mail server. Prior to version 0.8.0, attackers who achieved Arbitrary Code Execution as the stalwart-mail user (including web interface admins) can gain complete root access to the system. Usually, system services are run as a separate user (not as root) to isolate an attacker with Arbitrary Code Execution to the current service. Therefore, other system services and the system itself remains protected in case of a successful attack. stalwart-mail runs as a separate user, but it can give itself full privileges again in a simple way, so this protection is practically ineffective. Server admins who handed out the admin credentials to the mail server, but didn't want to hand out complete root access to the system, as well as any attacked user when the attackers gained Arbitrary Code Execution using another vulnerability, may be vulnerable. Version 0.8.0 contains a patch for the issue. |
| Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0. |
| Sentry is a developer-first error tracking and performance monitoring platform. Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the deprecated Slack verification token. With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration. The request body is leaked in log entries matching `event == "slack.*" && name == "sentry.integrations.slack" && request_data == *`. The deprecated slack verification token, will be found in the `request_data.token` key. **SaaS users** do not need to take any action. **Self-hosted users** should upgrade to version 24.5.0 or higher, rotate their Slack verification token, and use the Slack Signing Secret instead of the verification token. For users only using the `slack.signing-secret` in their self-hosted configuration, the legacy verification token is not used to verify the webhook payload. It is ignored. Users unable to upgrade should either set the `slack.signing-secret` instead of `slack.verification-token`. The signing secret is Slack's recommended way of authenticating webhooks. By having `slack.singing-secret` set, Sentry self-hosted will no longer use the verification token for authentication of the webhooks, regardless of whether `slack.verification-token` is set or not. Alternatively if the self-hosted instance is unable to be upgraded or re-configured to use the `slack.signing-secret`, the logging configuration can be adjusted to not generate logs from the integration. The default logging configuration can be found in `src/sentry/conf/server.py`. **Services should be restarted once the configuration change is saved.**
|
| Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge. Dapr sends the app token of the invoker app instead of the app token of the invoked app. This causes of a leak of the application token of the invoker app to the invoked app when using Dapr as a gRPC proxy for remote service invocation. This vulnerability impacts Dapr users who use Dapr as a gRPC proxy for remote service invocation as well as the Dapr App API token functionality. An attacker could exploit this vulnerability to gain access to the app token of the invoker app, potentially compromising security and authentication mechanisms. This vulnerability was patched in version 1.13.3.
|
| Wagtail is an open source content management system built on Django. Due to an improperly applied permission check in the `wagtail.contrib.settings` module, a user with access to the Wagtail admin and knowledge of the URL of the edit view for a settings model can access and update that setting, even when they have not been granted permission over the model. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. Patched versions have been released as Wagtail 6.0.5 and 6.1.2. Wagtail releases prior to 6.0 are unaffected. Users are advised to upgrade. Site owners who are unable to upgrade to a patched version can avoid the vulnerability in `ModelViewSet` by registering the model as a snippet instead. No workaround is available for `wagtail.contrib.settings`. |
| MIT IdentiBot is an open-source Discord bot written in Node.js that verifies individuals' affiliations with MIT, grants them roles in a Discord server, and stores information about them in a database backend. A vulnerability that exists prior to commit 48e3e5e7ead6777fa75d57c7711c8e55b501c24e impacts all users who have performed verification with an instance of MIT IdentiBot that meets the following conditions: The instance of IdentiBot is tied to a "public" Discord application—i.e., users other than the API access registrant can add it to servers; *and* the instance has not yet been patched. In affected versions, IdentiBot does not check that a server is authorized before allowing members to execute slash and user commands in that server. As a result, any user can join IdentiBot to their server and then use commands (e.g., `/kerbid`) to reveal the full name and other information about a Discord user who has verified their affiliation with MIT using IdentiBot. The latest version of MIT IdentiBot contains a patch for this vulnerability (implemented in commit 48e3e5e7ead6777fa75d57c7711c8e55b501c24e). There is no way to prevent exploitation of the vulnerability without the patch. To prevent exploitation of the vulnerability, all vulnerable instances of IdentiBot should be taken offline until they have been updated. |
| Minder by Stacklok is an open source software supply chain security platform. Minder prior to version 0.0.51 is vulnerable to a denial-of-service (DoS) attack which could allow an attacker to crash the Minder server and deny other users access to it. The root cause of the vulnerability is that Minders sigstore verifier reads an untrusted response entirely into memory without enforcing a limit on the response body. An attacker can exploit this by making Minder make a request to an attacker-controlled endpoint which returns a response with a large body which will crash the Minder server. Specifically, the point of failure is where Minder parses the response from the GitHub attestations endpoint in `getAttestationReply`. Here, Minder makes a request to the `orgs/$owner/attestations/$checksumref` GitHub endpoint (line 285) and then parses the response into the `AttestationReply` (line 295). The way Minder parses the response on line 295 makes it prone to DoS if the response is large enough. Essentially, the response needs to be larger than the machine has available memory. Version 0.0.51 contains a patch for this issue.
The content that is hosted at the `orgs/$owner/attestations/$checksumref` GitHub attestation endpoint is controlled by users including unauthenticated users to Minders threat model. However, a user will need to configure their own Minder settings to cause Minder to make Minder send a request to fetch the attestations. The user would need to know of a package whose attestations were configured in such a way that they would return a large response when fetching them. As such, the steps needed to carry out this attack would look as such:
1. The attacker adds a package to ghcr.io with attestations that can be fetched via the `orgs/$owner/attestations/$checksumref` GitHub endpoint.
2. The attacker registers on Minder and makes Minder fetch the attestations.
3. Minder fetches attestations and crashes thereby being denied of service. |
| A vulnerability has been identified in SIMATIC S7-200 SMART CPU CR40 (6ES7288-1CR40-0AA0) (All versions), SIMATIC S7-200 SMART CPU CR60 (6ES7288-1CR60-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR20 (6ES7288-1SR20-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR20 (6ES7288-1SR20-0AA1) (All versions), SIMATIC S7-200 SMART CPU SR30 (6ES7288-1SR30-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR30 (6ES7288-1SR30-0AA1) (All versions), SIMATIC S7-200 SMART CPU SR40 (6ES7288-1SR40-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR40 (6ES7288-1SR40-0AA1) (All versions), SIMATIC S7-200 SMART CPU SR60 (6ES7288-1SR60-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR60 (6ES7288-1SR60-0AA1) (All versions), SIMATIC S7-200 SMART CPU ST20 (6ES7288-1ST20-0AA0) (All versions), SIMATIC S7-200 SMART CPU ST20 (6ES7288-1ST20-0AA1) (All versions), SIMATIC S7-200 SMART CPU ST30 (6ES7288-1ST30-0AA0) (All versions), SIMATIC S7-200 SMART CPU ST30 (6ES7288-1ST30-0AA1) (All versions), SIMATIC S7-200 SMART CPU ST40 (6ES7288-1ST40-0AA0) (All versions), SIMATIC S7-200 SMART CPU ST40 (6ES7288-1ST40-0AA1) (All versions), SIMATIC S7-200 SMART CPU ST60 (6ES7288-1ST60-0AA0) (All versions), SIMATIC S7-200 SMART CPU ST60 (6ES7288-1ST60-0AA1) (All versions). Affected devices are using a predictable IP ID sequence number. This leaves the system susceptible to a family of attacks which rely on the use of predictable IP ID sequence numbers as their base method of attack and eventually could allow an attacker to create a denial of service condition. |
| Certain Anpviz products allow unauthenticated users to download arbitrary files from the device's filesystem via a HTTP GET request to the /playback/ URI. This affects IPC-D250, IPC-D260, IPC-B850, IPC-D850, IPC-D350, IPC-D3150, IPC-D4250, IPC-D380, IPC-D880, IPC-D280, IPC-D3180, MC800N, YM500L, YM800N_N2, YMF50B, YM800SV2, YM500L8, and YM200E10 (IP Cameras) firmware v3.2.2.2 and lower and possibly more vendors/models of IP camera. |
| A vulnerability has been identified in SIMATIC BATCH V9.1 (All versions), SIMATIC Information Server 2020 (All versions < V2020 SP2 Update 5), SIMATIC Information Server 2022 (All versions < V2022 SP1 Update 2), SIMATIC PCS 7 V9.1 (All versions < V9.1 SP2 UC06), SIMATIC Process Historian 2020 (All versions < V2020 SP2 Update 5), SIMATIC Process Historian 2022 (All versions < V2022 SP1 Update 2), SIMATIC WinCC Runtime Professional V18 (All versions < V18 Update 5), SIMATIC WinCC Runtime Professional V19 (All versions < V19 Update 3), SIMATIC WinCC V7.4 (All versions), SIMATIC WinCC V7.5 (All versions < V7.5 SP2 Update 18), SIMATIC WinCC V8.0 (All versions < V8.0 Update 5). The affected products run their DB server with elevated privileges which could allow an authenticated attacker to execute arbitrary OS commands with administrative privileges. |
| Qlik Sense Enterprise for Windows before 14.187.4 allows a remote attacker to elevate their privilege due to improper validation. The attacker can elevate their privilege to the internal system role, which allows them to execute commands on the server. This affects February 2024 Patch 3 (14.173.3 through 14.173.7), November 2023 Patch 8 (14.159.4 through 14.159.13), August 2023 Patch 13 (14.139.3 through 14.139.20), May 2023 Patch 15 (14.129.3 through 14.129.22), February 2023 Patch 13 (14.113.1 through 14.113.18), November 2022 Patch 13 (14.97.2 through 14.97.18), August 2022 Patch 16 (14.78.3 through 14.78.23), and May 2022 Patch 17 (14.67.7 through 14.67.31). This has been fixed in May 2024 (14.187.4), February 2024 Patch 4 (14.173.8), November 2023 Patch 9 (14.159.14), August 2023 Patch 14 (14.139.21), May 2023 Patch 16 (14.129.23), February 2023 Patch 14 (14.113.19), November 2022 Patch 14 (14.97.19), August 2022 Patch 17 (14.78.25), and May 2022 Patch 18 (14.67.34). |
| Aircompressor is a library with ports of the Snappy, LZO, LZ4, and Zstandard compression algorithms to Java. All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. Users should update to Aircompressor 0.27 or newer where these issues have been fixed. When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. There are no known workarounds for this issue. |
| Statamic is a, Laravel + Git powered CMS designed for building websites. In affected versions users registering via the `user:register_form` tag will have their password confirmation stored in plain text in their user file. This only affects sites matching **all** of the following conditions: 1. Running Statamic versions between 5.3.0 and 5.6.1. (This version range represents only one calendar week), 2. Using the `user:register_form` tag. 3. Using file-based user accounts. (Does not affect users stored in a database.), 4. Has users that have registered during that time period. (Existing users are not affected.). Additionally passwords are only visible to users that have access to read user yaml files, typically developers of the application itself. This issue has been patched in version 5.6.2, however any users registered during that time period and using the affected version range will still have the the `password_confirmation` value in their yaml files. We recommend that affected users have their password reset. System administrators are advised to upgrade their deployments. There are no known workarounds for this vulnerability. Anyone who commits their files to a public git repo, may consider clearing the sensitive data from the git history as it is likely that passwords were uploaded. |
| Improper input validation in the SMM communications buffer could allow a privileged attacker to perform an out of bounds read or write to SMRAM potentially resulting in loss of confidentiality or integrity. |
| The integer overflow vulnerability within AMD Graphics driver could allow an attacker to bypass size checks potentially resulting in a denial of service |
