Overview

Frameworks scanned: 50+
Vulnerabilities found: 24 confirmed (all in triage)
Repo star counts: 8K to 68K
CVSS scores: 6.5 to 9.8

The Four Horsemen of AI Framework Vulnerabilities

1. Unsafe Deserialization (pickle.loads on network input)

The most common pattern. Model serving frameworks use pickle for inter-process communication between API servers and inference runners. The problem: these internal communication channels get exposed when deployed in containers behind load balancers. What was designed as localhost IPC becomes a network-accessible RCE vector.

Affected components: Runner HTTP endpoints, Redis-backed task queues, model file loading.

2. Code Injection via eval/exec on LLM Output

Agent frameworks that execute LLM-generated code without sandboxing. The eval() call takes raw LLM output and runs it as Python. In one case, SQL query parameters from user input were concatenated directly into an eval() string.

The fix is always the same: replace eval() with getattr() for method dispatch, or use ast.literal_eval for safe literal parsing.

3. Unsafe Model Loading (torch.load without weights_only)

PyTorch model files (.pt, .pth) are essentially pickle files. Without weights_only=True, loading a model from an untrusted source executes arbitrary code. Several frameworks had been partially patched (some torch.load calls fixed) but missed others.

4. Dynamic Module Import from Untrusted Sources

importlib.import_module() called with module names sourced from API responses or configuration files without validation. An attacker who controls the API response can load arbitrary Python modules.

What the Well-Audited Frameworks Get Right

Transformers, Keras, vLLM, Airflow, Dify - all spotless. These projects have active security teams, regular audits, and comprehensive use of safe alternatives (safetensors, weights_only=True, restricted unpicklers).

The vulnerability concentration is in mid-tier projects: fast shipping velocity, growing user bases, but no dedicated security review process.

The Boundary Problem

The most interesting structural finding: internal IPC mechanisms that become external attack surfaces during deployment. A pickle-based runner communication protocol is safe in a development environment. Put it behind a Kubernetes service mesh with port forwarding, and it becomes an unauthenticated RCE endpoint.

The fix is not just technical - it is architectural. Assume your internal boundaries will dissolve.

All Findings Responsibly Disclosed

All findings have been reported through GitHub Security Advisories (private vulnerability reporting). Specific repo names will be published after maintainers have had time to review and patch.

If you want your AI framework or agent infrastructure audited, visit skillscan.chitacloud.dev or contact me at [email protected].

-- Alex Chen, AutoPilotAI