ghsa

A critical vulnerability was discovered in the `ismp-grandpa` crate, that allowed a malicious prover easily convince the verifier of the finality of arbitrary headers. ### Description The vulnerability manifests as a verifer that only accepts incorrect signatures of Grandpa precommits and was introduced in this [specific commit](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/5ca3351a19151f1a439c30d5cbdbfdc72a11f1a8#diff-3835cc24fb2011b3e8246036059acd8c2c2a9a869eedf7a210d18edb6543318dL262). Perhaps due to unfamiliarity with core substrate APIs. The `if` statement should have included a negation check, similar to the previous code, but this was omitted. Causing the verifier to **only** accept invalid signatures. This vulnerability remained undetected even with [integration tests](https://github.com/polytope-labs/ismp-substrate/pull/64/commits/04d5be207b082eb61d586d52e1685e2e060347e6#diff-4aedbca82d26bebc03f274e23fd5697c3346ffff54405c87af9018f3aef708b2R1-R160), as the...

When logs are written to a widely-writable directory (the default), an unprivileged attacker may predict a privileged process's log file path and pre-create a symbolic link to a sensitive file in its place. When that privileged process runs, it will follow the planted symlink and overwrite that sensitive file. To fix that, glog now causes the program to exit (with status code 2) when it finds that the configured log file already exists.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-q53r-9hh9-w277. This link is maintained to preserve external references. ## Original Description A vulnerability, which was classified as critical, has been found in Pimcore customer-data-framework up to 4.2.0. Affected by this issue is some unknown functionality of the file /admin/customermanagementframework/customers/list. The manipulation of the argument filterDefinition/filter leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 4.2.1 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability was found in CRI-O. A path traversal issue in the log management functions (UnMountPodLogs and LinkContainerLogs) may allow an attacker with permissions to create and delete Pods to unmount arbitrary host paths, leading to node-level denial of service by unmounting critical system directories.

A flaw was found in Infinispan, when using JGroups with JDBC_PING. This issue occurs when an application inadvertently exposes sensitive information, such as configuration details or credentials, through logging mechanisms. This exposure can lead to unauthorized access and exploitation by malicious actors.

Use of Arrays.equals() in LlapSignerImpl in Apache Hive to compare message signatures allows attacker to forge a valid signature for an arbitrary message byte by byte. The attacker should be an authorized user of the product to perform this attack. Users are recommended to upgrade to version 4.0.0, which fixes this issue. The problem occurs when an application doesn’t use a constant-time algorithm for validating a signature. The method Arrays.equals() returns false right away when it sees that one of the input’s bytes are different. It means that the comparison time depends on the contents of the arrays. This little thing may allow an attacker to forge a valid signature for an arbitrary message byte by byte. So it might allow malicious users to submit splits/work with selected signatures to LLAP without running as a privileged user, potentially leading to DDoS attack. More details in the reference section.

### Description The vllm/model_executor/weight_utils.py implements hf_model_weights_iterator to load the model checkpoint, which is downloaded from huggingface. It use torch.load function and weights_only parameter is default value False. There is a security warning on https://pytorch.org/docs/stable/generated/torch.load.html, when torch.load load a malicious pickle data it will execute arbitrary code during unpickling. ### Impact This vulnerability can be exploited to execute arbitrary codes and OS commands in the victim machine who fetch the pretrained repo remotely. Note that most models now use the safetensors format, which is not vulnerable to this issue. ### References * https://pytorch.org/docs/stable/generated/torch.load.html * Fix: https://github.com/vllm-project/vllm/pull/12366

### Summary Imgproxy does not block the `0.0.0.0` address, even with `IMGPROXY_ALLOW_LOOPBACK_SOURCE_ADDRESSES` set to false. This can expose services on the local host. ### Details imgproxy protects against SSRF against a loopback address with the following check ([source](https://github.com/imgproxy/imgproxy/blob/0f37d62fd8326a32c213b30dd52e2319770885d8/security/source.go#L43C1-L47C1)): ``` if !config.AllowLoopbackSourceAddresses && ip.IsLoopback() { return ErrSourceAddressNotAllowed } ``` This check is insufficient to prevent accessing services on the local host, as services may receive traffic on `0.0.0.0`. Go's `IsLoopback` ([source](https://github.com/golang/go/blob/40b3c0e58a0ae8dec4684a009bf3806769e0fc41/src/net/ip.go#L126-L131)) strictly follows the definition of loopback IPs beginning with `127`. `0.0.0.0` is not blocked.

A cross-site scripting (XSS) vulnerability in the Events/Agenda module of Dolibarr v21.0.0-beta allows attackers to execute arbitrary web scripts or HTMl via a crafted payload injected into the Title parameter.

A cross-site scripting (XSS) vulnerability in the Product module of Dolibarr v21.0.0-beta allows attackers to execute arbitrary web scripts or HTMl via a crafted payload injected into the Title parameter.