29 thg 4, 2026

CVE-2026-42208: Khi Hệ Thống Xác Thực Của AI Proxy Chính Là Cửa Hậu

Hàm xác thực API key của LiteLLM dính lỗi SQL injection pre-auth (CVSS 9.3). Sáu lỗ hổng nghiêm trọng trong một tháng. AI proxy giờ là mục tiêu giá trị cao.

Bảo mật

Thẻ (5)

# security # litellm # sql-injection # ai-infrastructure # cve

Bạn tin tưởng LLM proxy sẽ xác thực API key. Đó là nhiệm vụ của nó. Hàm xác thực của LiteLLM nối thẳng header Authorization vào câu truy vấn SQL. Không parameterized binding. Không escaping. Chỉ nối chuỗi thô trong đúng cái hàm được thiết kế để chặn kẻ tấn công. CVSS 9.3, pre-auth, không cần tương tác. Ổ khóa cửa chính làm bằng bìa carton.

Chuyện Gì Đã Xảy Ra

CVE-2026-42208 là lỗ hổng SQL injection pre-authentication trong proxy server của LiteLLM. Tencent YunDing Security Lab phát hiện ra, và mức độ nghiêm trọng gần như tối đa cho SQLi.

Dữ kiện chính:

• CVSS v4 Score: 9.3 (Critical)
• CWE: CWE-89 (SQL Injection)
• Phiên bản bị ảnh hưởng: v1.81.16 đến v1.83.6
• Đã sửa trong: v1.83.7+
• Attack vector: Network, low complexity, không cần xác thực, không cần tương tác
• GHSA: GHSA-r75f-5x8p-qvmc

Kẻ tấn công gửi header Authorization được craft đặc biệt tới bất kỳ LLM endpoint nào — ví dụ POST /chat/completions. Request không cần key hợp lệ. Không cần key gì cả. Đường xử lý lỗi của proxy lấy giá trị header thô rồi nhét thẳng vào câu SQL — giống như đứa trẻ cắm nĩa vào ổ điện.

Pattern bị lỗi trông như thế này:

# Code "bảo mật" mà thực ra là backdoor
# (I wish I were joking)
async def verify_key(api_key: str):
    query = f"SELECT * FROM keys WHERE key = '{api_key}'"
    result = await db.execute(query)
    return result

Bản sửa là thứ đáng lẽ phải có từ đầu:

# Parameterized query — the bare minimum for 2026
async def verify_key(api_key: str):
    query = "SELECT * FROM keys WHERE key = ?"
    result = await db.execute(query, [api_key])
    return result

Khai thác thành công cho kẻ tấn công full read-write access vào database của proxy. Database đó chứa API key cho mọi LLM provider bạn cấu hình — OpenAI, Anthropic, Google, Cohere, tất cả. Một HTTP header được craft cẩn thận, và ai đó sở hữu toàn bộ ngân sách AI của bạn.

Điểm Mù Trong Xử Lý Lỗi

Đây là phần đáng lo nhất: lỗ hổng không nằm trong logic xác thực chính. Nó nằm trong đường xử lý lỗi.

Hãy hình dung như lắp cửa thép két sắt cho nhà, rồi để bảng điều khiển hệ thống báo động mở toang qua cửa sổ không khóa. Happy path — key hợp lệ, auth thành công — không vấn đề gì. Sad path — key sai, ghi log lỗi — là nơi mọi thứ sụp đổ.

Tại sao chuyện này xảy ra? Ba lý do:

Developer test thành công. Test suite có mười case cho “key hợp lệ trả về 200” và một case cho “key sai trả về 401.” Không ai viết test cho “key sai chứa SQL metacharacter trong error logger.”

Security review tập trung vào auth middleware. Khi security engineer audit proxy, họ nhìn vào authentication decorator, JWT validator, rate limiter. Hiếm khi họ trace xem chuyện gì xảy ra khi auth thất bại và request rơi vào error logging.

Error handler “chỉ ghi log thôi.” Developer coi code xử lý lỗi là low-risk vì nó không ra quyết định. Nhưng khoảnh khắc code “ghi log” đó chạm database, nó đang ra quyết định — chỉ là không ai giám sát.

# Looks harmless. Isn't.
async def log_failed_auth(request):
    api_key = request.headers.get("Authorization", "unknown")
    # This "harmless" log entry is a SQL injection vector
    await db.execute(
        f"INSERT INTO error_logs (key, endpoint, ts) "
        f"VALUES ('{api_key}', '{request.path}', NOW())"
    )

Bản sửa không chỉ là parameterize một query này. Mà là audit mọi đường mà user input có thể đi tới — đặc biệt những đường bạn nghĩ “chỉ ghi log thôi.”

Sáu Lỗ Hổng, Một Tháng — Một Mô Hình

CVE-2026-42208 không xảy ra đơn lẻ. LiteLLM có sáu security advisory được công bố riêng trong tháng 4 năm 2026, cộng thêm một cuộc tấn công supply chain. Đây không phải tháng xui — đây là một mô hình.

Ngoài ra, SentinelOne phát hiện tấn công supply chain: ai đó publish phiên bản trojaned v1.82.7 và v1.82.8 lên PyPI. Package hợp pháp, bị chiếm đoạt, vũ khí hóa, và đẩy lên cùng registry mà developer tin tưởng cho pip install.

Bề mặt tấn công của LLM proxy điển hình lớn hơn hầu hết team nhận ra:

flowchart TD
  A[Client Request] -->|Authorization header| B[API Key Verification]
  A -->|OIDC token| C[Identity Provider]
  B -->|valid| D[LLM Router]
  B -->|invalid| E[Error Logger]
  D --> F[Provider APIs]
  D --> G[Request Cache]
  H[Admin API] -->|config changes| D
  H -->|user management| B
  I[MCP Endpoints] -->|tool calls| D
  J[Prompt Templates] -->|render| D
  E -->|writes| K[Database]
  B -->|reads| K
  H -->|reads/writes| K

Các dự án AI infrastructure phát triển nhanh. LiteLLM thêm hỗ trợ provider mới, auth method mới, và tính năng admin mới với tốc độ startup. Security review không theo kịp khi bề mặt tấn công mở rộng hàng tuần. Điều này không riêng LiteLLM — đây là câu chuyện của mọi AI proxy, gateway, và orchestration layer đang ship tính năng nhanh hơn ship audit.

Gia Cố LLM Proxy Của Bạn

Nếu bạn đang chạy LiteLLM, bản sửa ngay lập tức rất đơn giản: nâng cấp lên v1.83.7 hoặc mới hơn. Query bị lỗi giờ đã dùng parameterized binding.

Ngoài CVE cụ thể này, đây là checklist gia cố cho bất kỳ triển khai LLM proxy nào:

1. Parameterized query ở mọi nơi — kể cả error path. Audit mọi lệnh db.execute(), không chỉ những lệnh trong auth middleware. Những lệnh trong error handler, analytics, và admin logging là những lệnh kẻ tấn công tìm ra trước.

2. Audit error handler với cùng mức nghiêm ngặt như auth code. Nếu security review bỏ qua các block try/except và error logger, bạn đang để cửa sau mở. Mọi đường code chạm user input đều là ranh giới bảo mật.

3. Pin phiên bản proxy. Không auto-update AI infrastructure. Chạy litellm==latest trong production là rủi ro supply chain. Pin phiên bản cụ thể, review changelog trước khi nâng cấp, và verify checksum.

4. Network-segment proxy. LLM proxy của bạn giữ API key cho mọi provider bạn dùng. Nó là secrets manager dù bạn có định thế hay không. Đặt sau private network, giới hạn inbound access, và giám sát outbound connection.

5. Rotate tất cả LLM API key nếu bạn chạy phiên bản bị ảnh hưởng.

Đây là error logging an toàn trông như thế nào:

# Safe: parameterized insert, truncated input, no raw user data in SQL
async def log_failed_auth(request):
    api_key = request.headers.get("Authorization", "unknown")
    # Truncate to prevent storage abuse, parameterize to prevent SQLi
    safe_prefix = api_key[:8] + "..." if len(api_key) > 8 else api_key
    await db.execute(
        "INSERT INTO error_logs (key_prefix, endpoint, ts) VALUES (?, ?, ?)",
        [safe_prefix, request.path, datetime.utcnow()]
    )

LLM proxy của bạn lưu credentials cho mọi AI provider bạn dùng. Nó route mọi prompt tổ chức bạn gửi đi. Nó không phải convenience wrapper — nó là critical infrastructure. Hãy đối xử với nó như secrets manager. Khóa chặt network. Audit đường xử lý lỗi.

Bug quan trọng không nằm trong code bạn review cẩn thận. Chúng nằm trong code bạn cho là nhàm chán.