LiteLLM is a proxy server

CVE-2026-42208 is a pre-auth SQL injection in LiteLLM proxy API key verification. Affected versions are >=1.81.16 and <1.83.7; the vulnerable path sits in the proxy’s auth check, where a caller-controlled Authorization header is mixed into a database query instead of parameterized, letting an unauthenticated remote client reach the database through normal LLM routes like /chat/completions.

Vendor severity is directionally right in practice, even though the published scoring is messy: the GitHub CNA advisory shows Critical 9.3, while NVD enrichment shows Critical 9.8 as of 2026-05-08. The real-world risk is not abstract SQLi math; it is that LiteLLM is a credential concentrator for OpenAI, Anthropic, Bedrock, Azure OpenAI, and other upstream keys, and this bug hits that credential broker *before* auth with confirmed exploitation and KEV listing.

Why this verdict

• Pre-auth remote path: no credentials, no user click, normal API route, and the vulnerable code runs in the auth-check itself.
• Blast radius is credential-centric: LiteLLM is an AI gateway that stores or brokers upstream provider secrets, so a database read is effectively a pivot into paid model accounts and downstream tenant activity.
• Active exploitation and KEV erase wishful thinking: once CISA KEV and observed exploitation are on the board, this stops being theoretical patch debt and becomes an attacker-validated path.
• Only modest downward friction: the bug requires a LiteLLM proxy deployment on a narrow version band and meaningful network reachability, which trims exposed population but does not make the instances that *are* exposed any safer.

Why not higher?

There is real friction in the reachable population: this is a specific open-source AI gateway, not a mass-enterprise platform, and many deployments are internal-only. Also, successful monetization still depends on useful secrets being present and valid, not just on proving SQLi.

Why not lower?

Dropping this to HIGH or below would ignore two practitioner-grade facts: it is pre-auth over the network and it is already KEV-listed / exploited. When the vulnerable component is the place where you centralize OpenAI, Anthropic, Bedrock, and other keys, the impact is much closer to secret-store compromise than to a routine web-app SQLi.

1. Disable the vulnerable path — If you cannot patch at once, set general_settings.disable_error_logs: true exactly as the GHSA workaround states. Do this immediately, within hours, because KEV/active exploitation overrides the normal SLA and this removes the unauthenticated input path called out by the vendor.
2. Pull the proxy off untrusted networks — Restrict LiteLLM ingress to private networks, VPN, service mesh, or an allowlisted API gateway. Do this immediately, within hours for any instance reachable from the internet or broad user VLANs, because attacker position is the biggest remaining friction and you can force that friction yourself.
3. Rotate upstream provider secrets — Treat internet-facing vulnerable instances as potential secret exposure events and rotate OpenAI, Anthropic, Bedrock, Azure OpenAI, and master/virtual keys. Do this immediately, within hours if the instance was exposed during the vulnerable window, because patching does not invalidate already-stolen credentials.
4. Alert on malformed bearer tokens — Add detections for quotes, UNION, SQL comment markers, and abnormal bearer-token length in Authorization headers to LiteLLM routes. Deploy within 3 days at the latest on monitored edges, but faster is better because exploitation has already been seen.
5. Constrain provider-side blast radius — Where supported, scope provider API keys to least privilege, lower spend caps, and isolate prod vs test credentials. Deploy within 3 days for exposed deployments so a stolen LiteLLM secret cannot automatically become unrestricted provider abuse.

Run this on the target host or container image that actually serves the LiteLLM proxy, not from an auditor workstation. Invoke it as python3 check_cve_2026_42208.py /path/to/config.yaml; it needs read access to the Python environment where litellm is installed and optional read access to the LiteLLM config file. No root is required unless your config path is protected.

#!/usr/bin/env python3
# Check LiteLLM for CVE-2026-42208
# Usage: python3 check_cve_2026_42208.py /etc/litellm/config.yaml
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import re
import sys

try:
    from importlib import metadata
except Exception:
    print('UNKNOWN')
    sys.exit(2)


def parse_version(v):
    nums = [int(x) for x in re.findall(r'\d+', v)]
    while len(nums) < 3:
        nums.append(0)
    return tuple(nums[:3])


def version_in_range(v, lower, upper):
    return parse_version(lower) <= parse_version(v) < parse_version(upper)


def config_has_workaround(path):
    if not path:
        return False
    if not os.path.exists(path):
        return False
    try:
        text = open(path, 'r', encoding='utf-8', errors='ignore').read()
    except Exception:
        return False

    # Cheap stdlib-only check. We do not require PyYAML.
    # Accepts forms like:
    # general_settings:
    #   disable_error_logs: true
    general_block = re.search(r'general_settings\s*:(.*?)(?:\n\S|\Z)', text, flags=re.S)
    if general_block and re.search(r'disable_error_logs\s*:\s*true\b', general_block.group(1), flags=re.I):
        return True

    # Fallback if file is flattened or templated.
    if re.search(r'disable_error_logs\s*:\s*true\b', text, flags=re.I):
        return True
    return False


def main():
    cfg = sys.argv[1] if len(sys.argv) > 1 else os.environ.get('LITELLM_CONFIG')

    try:
        version = metadata.version('litellm')
    except metadata.PackageNotFoundError:
        print('UNKNOWN')
        sys.exit(2)
    except Exception:
        print('UNKNOWN')
        sys.exit(2)

    if version_in_range(version, '1.81.16', '1.83.7'):
        if config_has_workaround(cfg):
            # Vulnerable package present, but vendor workaround appears enabled.
            # Treat as UNKNOWN because this is mitigated, not patched.
            print('UNKNOWN')
            sys.exit(2)
        print('VULNERABLE')
        sys.exit(1)

    # Outside the affected range for this CVE.
    print('PATCHED')
    sys.exit(0)


if __name__ == '__main__':
    main()

Sources

1. NVD CVE-2026-42208
2. GitHub Security Advisory GHSA-r75f-5x8p-qvmc
3. LiteLLM patched release v1.83.7-stable
4. LiteLLM release notes
5. LiteLLM getting started / proxy docs
6. Sysdig exploitation research
7. CISA KEV catalog entry filter