# SCAN: litellm
date: 2026-02-13 | program: litellm | repo: https://github.com/BerriAI/litellm | bounty: $0-$1500

## summary
raw_findings: ~71 trufflehog + manual review | real: 2 (medium) | high_conf: 0 | med_conf: 2 | low_conf: 0 | false_pos: many
scan_method: manual_review (semgrep failed, trufflehog 71 findings mostly test/doc FPs)
scanner_status: INCOMPLETE — agent ran 77 tool calls before hitting API limit

## findings

### F1: SSRF via http_request Primitive in Custom Code Guardrails
severity: medium | confidence: medium | type: SSRF | cwe: CWE-918
file: litellm/proxy/guardrails/custom_code_guardrail.py (http_request primitive)
tool: manual

analysis: The http_request function provided as a primitive to custom code guardrails has zero SSRF protection — no blocking of private/internal IPs (169.254.169.254, 10.x, 172.16.x, etc.). A guardrail admin can make requests to internal services.
mitigating factor: Guardrail CRUD endpoints require admin access (enforced by route-based role checks in auth).
recommendation: log — admin-only, low exploitability

### F2: Missing Builtins Restriction in Production Custom Code Guardrails
severity: medium | confidence: medium | type: Sandbox Escape | cwe: CWE-693
file: litellm/proxy/guardrails/custom_code_guardrail.py (_compile_custom_code ~line 156)
tool: manual

analysis: The _compile_custom_code method uses dynamic code compilation without setting builtins to empty dict in the execution globals. The test endpoint (test_custom_code) DOES restrict builtins and validates against FORBIDDEN_PATTERNS — but the production compilation path does not. This means admins who create guardrails have unrestricted code capabilities.
mitigating factor: Guardrail creation is admin-only. Admins typically already have significant server access.
recommendation: log — admin-only reduces severity to design limitation

## areas confirmed secure
- SQL queries: Properly parameterized ($1, $2). sort_by validated against whitelist.
- YAML: Uses safe_load everywhere.
- Jinja2: Uses ImmutableSandboxedEnvironment.
- File upload: UUID-based filenames, not exploitable.
- ast.literal_eval: Used safely (literals only).
- api_base: Comes from server config, not user request parameters.
- Pass-through endpoints: ast.literal_eval on body is safe.

## assessment
litellm is well-maintained with good security practices. The two medium findings are both admin-gated, making them low-priority for bounty reporting. Per decision matrix: medium confidence + medium severity → log, skip.

## priority actions
| # | Finding | Severity | Confidence | Action |
|---|---------|----------|------------|--------|
| F1 | SSRF in guardrail http_request | medium | medium | log, skip |
| F2 | Sandbox escape in guardrail compilation | medium | medium | log, skip |