Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-q53r-9hh9-w277: pimcore/customer-data-framework vulnerable to SQL Injection

An SQL injection vulnerability allows any authenticated user to execute arbitrary SQL commands on the server. This can lead to unauthorized access to sensitive data, data modification, or even complete control over the server. Details The vulnerability is found in the URL parameters of the following endpoint: `GET /admin/customermanagementframework/customers/list?add-new-customer=1&apply-segment-selection=Apply&filterDefinition[allowedRoleIds][]=1&filterDefinition[allowedUserIds][]=2&filterDefinition[id]=0&filterDefinition[name]=RDFYjolf&filterDefinition[readOnly]=on&filterDefinition[shortcutAvailable]=on&filter[active]=1&filter[email]=testing%40example.com&filter[firstname]=RDFYjolf&filter[id]=1&filter[lastname]=RDFYjolf&filter[operator-customer]=AND&filter[operator-segments]=%40%40dz1Uu&filter[search]=the&filter[segments][832][]=847&filter[segments][833][]=835&filter[segments][874][]=876&filter[showSegments][]=832 HTTP/1.1` The parameters filterDefinition and filter are vulnerable...

ghsa
#sql#vulnerability#web#git#auth
GHSA-xr3m-6gq6-22cg: Pimcore Authenticated Stored Cross-Site Scripting (XSS) Via Search Document

### Summary A Stored Cross-Site Scripting (XSS) vulnerability in PIMCORE allows remote attackers to inject arbitrary web script or HTML via the PDF upload functionality. This can result in the execution of malicious scripts in the context of the user's browser when the PDF is viewed, leading to potential session hijacking, defacement of web pages, or unauthorized access to sensitive information. ### Details The vulnerability is present in the PDF upload functionality of the PIM Core Upload module. When a user uploads a PDF file, the application fails to properly sanitize the content, allowing embedded scripts to be executed when the PDF is viewed. The affected code is located in the file handling and rendering logic of the PDF upload feature. ### PoC 1. Log in as Administrator ![image](https://github.com/user-attachments/assets/7945bbd7-5277-4a0e-8365-56e5df319bae) 2. Hover to Assets ![image](https://github.com/user-attachments/assets/f24645ee-d740-4a5e-81d1-b8bf48b71cce)...

GHSA-58fx-7v9q-3g56: ArgoCD Namespace Isolation Break

A flaw was found in ArgoCD. The openshift.io/cluster-monitoring label is applied to all namespaces that deploy an ArgoCD CR instance, allowing the namespace to create a rogue PrometheusRule. This issue can have adverse effects on the platform monitoring stack, as the rule is rolled out cluster-wide when the label is applied.

GHSA-wwx5-gpgr-vxr7: ismp-grandpa crate accepted incorrect signatures

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...

GHSA-6wxm-mpqj-6jpf: Insecure Temporary File usage in github.com/golang/glog

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.

GHSA-8m8m-98c9-vw7q: Duplicate Advisory: pimcore/customer-data-framework vulnerable to SQL Injection: Hibernate

## 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.

GHSA-hp5j-2585-qx6g: CRI-O Path Traversal vulnerability

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.

GHSA-269m-c36j-r834: Infinispan vulnerable to Insertion of Sensitive Information into Log File

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.

GHSA-p953-3j66-hg45: Apache Hive vulnerable to Observable Timing Discrepancy and Authentication Bypass by Spoofing

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.

GHSA-rh4j-5rhw-hr54: vllm: Malicious model to RCE by torch.load in hf_model_weights_iterator

### 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