What happened
NVD published CVE-2026-105148 (7.3 v3.1, 5.5 v4.0) on 2026-10-04 for an SSRF (CWE-918) in SciPhi-AI R2R up to 3.6.6. The Retrieval Completion API passes user-controlled generation_config.api_base into a LiteLLM acomplete() call whenever the model prefix selects the LiteLLM provider; the container then POSTs /v1/chat/completions to the attacker URL (User-Agent litellm/...), and for OpenAI-compatible prefixes appends the process's OPENAI_API_KEY as a Bearer token. The public gist demonstrates both the plain SSRF and key-forwarding on a real setup.
Why it matters
R2R is self-hosted retrieval-augmented GenAI middleware that holds the operator's upstream LLM provider keys. This flaw lets an unauthenticated attacker turn the RAG server into a scanning proxy into its internal network and cloud metadata, and exfiltrates the live OPENAI_API_KEY - the crown jewel for billing abuse, model access, and potential data exposure. Together with CVE-2026-105147 (hard-coded secrets) the R2R control plane is effectively open on default installs.
Attack vector
The public completion/agent endpoints accept a client-controlled generation_config.api_base (and model prefix). For any model string routed to LiteLLM (e.g. custom/, together_ai/, huggingface/ prefixes), R2R issues an HTTP request to that api_base; for OpenAI-compatible prefixes the Authorization: Bearer <OPENAI_API_KEY> header is attached. An unauthenticated caller can both SSRF into the R2R container's network or cloud metadata and harvest the LLM provider key. Public exploit gist exists.
Affected systems
SciPhi-AI R2R up to 3.6.6 (py/shared/abstractions/llm.py; POST /v3/retrieval/completion and /v3/retrieval/agent)
Mitigation
No vendor response or patch seen. Guard the API: enable authentication (default r2r.toml has require_authentication=false), whitelist accepted api_base values, treat retrieval completion endpoints as high-trust. Disclosure gist: https://gist.github.com/DReazer/6c1fd0ef98900fbbfa383faa20f731f6