algorithmicsuperintelligence/optillm - security scan

Repository: algorithmicsuperintelligence/optillm Commit scanned: eaf171aa6da5682ba1014ef342556f40247f5b35 Scan date: 2026-07-18 Disclosure status: disclosed (one focused issue filed)

Summary

Severity Count
Critical 0
High 1
Medium 56
Low 0
Info 0

Total findings: 57 (1 real residual after curation)

OptiLLM is an OpenAI-API-compatible optimizing inference proxy (4.2k★): you point your client at it, it applies a reasoning technique (MoA, MCTS, best-of-n, a Z3 solver, code execution, URL reading, web search, deep research…) and forwards to the real model behind a configured base_url. So the interesting surface is the proxy: how it authenticates callers, what it forwards, and what its approaches reach out to. Most of it is done carefully. One egress path isn’t guarded, and that’s the finding.

The one that matters: readurls fetches attacker-named URLs with no SSRF guard

This is the same class as a2a-python’s push-notification webhook (undefended, deployer-hardening note) and IBM/mcp-context-forge’s gateway egress (thoroughly defended). OptiLLM sits at the a2a end: the guard is simply absent, and here the URL is fully attacker-chosen (it comes from the prompt), not a registered webhook — which is why it’s worth a filing rather than a footnote.

What the maintainer already does well

Before the residual, the defenses — because they’re the reason the other 56 findings collapse:

What looks scary but isn’t

Secondary note (defense-in-depth, not filed)

server.py:713 logs the caller’s bearer token at DEBUG (logger.debug(f"Intercepted Bearer Token: {bearer_token}")). Since OptiLLM supports “bring-your-own-key” pass-through (a client key starting with sk- becomes the upstream key, server.py:797), that log line can write a real provider API key to disk when debug logging is on. Redact to a prefix (sk-…{last4}) or drop the value. Debug-gated, so a hardening nit rather than a filing.

Patterns observed

This is the credit-the-defense scan again, and the third proxy/gateway in a row (codex-lb, IBM/mcp-context-forge, now OptiLLM) where the finding count is dominated by CI lint and the real question is one the scanner can’t ask: for every place the service reaches out, is the egress bounded? OptiLLM bounds the two that a scanner would worry about — the core forward (operator-set base_url) and auth (timing-safe, localhost default) — but the plugin egress surface is where it drifts. Of the URL-touching approaches (readurls, web_search, deep_research, mcp), readurls is the one that fetches a fully caller-chosen URL with no allow/deny on the destination host. That’s the whole delta between “well-built proxy” and “filed issue.”

The other pattern worth naming: on a code-executor framework the severity histogram lies twice. It over-counts (51 action-pin lints, 2 torch-perf hits) and it mis-frames — the two exec/ExecutePreprocessor sites read as critical RCE but are the advertised product, while the genuinely interesting item (readurls SSRF) carries no scanner flag at all. The curation move that pays off is the one from the ag2 / Agently lineage: separate “runs code by design” from “reaches the network by accident,” and check whether each advertised boundary is honest. OptiLLM’s code-exec is honest; its URL-fetch quietly reaches further than “fetch a webpage” implies.

Notes on the tool

Disclosure timeline

Reproduce

git clone https://github.com/algorithmicsuperintelligence/optillm /tmp/scan-target
python scanner/run_scan.py --repo /tmp/scan-target --reports-dir ./reports/algorithmicsuperintelligence-optillm --min-severity medium