LiteLLM 1.107.0 bị cài mã đánh cắp thông tin: nguyên nhân là một khóa lộ từ tháng 5 chưa thu hồi

Trong nhiều hệ thống AI, thành phần được gọi nhiều nhất không phải là model mà là lớp trung gian mỏng nằm giữa mã nguồn của bạn và các nhà cung cấp model. LiteLLM là một ví dụ điển hình. Đây là SDK Python kiêm proxy mã nguồn mở, cho phép gọi OpenAI, Anthropic, Bedrock, Vertex và hàng chục API khác qua cùng một giao diện. Theo số liệu của Socket mà Help Net Security dẫn lại, thư viện này có khoảng 23 triệu lượt tải mỗi tuần. Ngày 21/10/2026, một phiên bản độc hại là litellm==1.107.0 đã được phát hành qua chính quy trình phát hành (release pipeline) của LiteLLM, có chữ ký số và thông tin nguồn gốc build (provenance) hợp lệ.

Ngày 23/10, LiteLLM công bố bản báo cáo sự cố (postmortem) mà họ gọi là “nguồn chính thức”. Báo cáo này sửa lại một phần đáng kể lời giải thích ban đầu và truy nguyên sự cố về một sai sót từ năm tháng trước. Kẻ tấn công không dùng kỹ thuật khai thác nào mới. Mọi lớp bảo vệ mà chúng vượt qua đều là những lớp mà rất nhiều đội phát triển khác cũng đang trông cậy.

Phiên bản độc hại tồn tại trong bao lâu

Theo LiteLLM và công ty bảo mật StepSecurity:

PyPI: cả bảy bản wheel (gói cài đặt dựng sẵn) của 1.107.0 cho macOS, Linux (glibc/musl) và Windows có mặt từ 11:39:51 đến khoảng 13:23 UTC ngày 21/10.
Container: các tag v1.107.0, latest, main-latest và main-stable của image litellm/litellm trên Docker Hub và ghcr.io/berriai/litellm (kèm hai biến thể -database và -non_root) chứa mã độc từ 11:46:56 UTC đến 13:51 UTC (GHCR) và 14:20 UTC (Docker Hub).
Tag git v1.107.0 chính thức không bị can thiệp. Bản build đã bị trỏ sang một kho mã giả mạo là Berri-AI/litellm (có dấu gạch ngang) thay cho kho thật BerriAI/litellm.
Phiên bản an toàn gần nhất là 1.106.2. Khách hàng doanh nghiệp lấy gói từ registry riêng của LiteLLM không bị ảnh hưởng.

Hơn hai tiếng nghe có vẻ ngắn. Nhưng các job CI dùng tag latest hoặc chạy pip install litellm không ghim phiên bản chính là những nơi nhận bản phát hành mới chỉ sau vài phút.

Mã độc làm gì

Theo phân tích của StepSecurity, các bản wheel cài thêm ba tệp vào site-packages:

cook.pth chỉ dài 12 byte, nội dung là import cook. Python tự thực thi các tệp .pth mỗi khi trình thông dịch khởi động, nên mã độc chạy cả trên những máy chưa từng import litellm. Chỉ cần một tiến trình Python bất kỳ trong môi trường đó khởi động, chẳng hạn trình chạy test hay linter.
cook.py là công cụ đánh cắp thông tin tự đặt tên privcollect, gồm 16 mô-đun thu thập. Nó nhắm tới khóa SSH, GPG, thông tin xác thực AWS/Azure/GCP và credential của vai trò lấy qua instance metadata, ~/.kube/config, credential của Docker, npm, PyPI và git, tệp .env, token của Vault và hệ thống CI, mật khẩu và cookie trình duyệt, cùng biến môi trường của mọi tiến trình qua /proc/<pid>/environ. Nó còn tìm token của các công cụ lập trình AI như Claude Code, Cursor, Copilot, Gemini CLI và Codex.
sitecustomize.py là bộ nạp (loader). Nó tách ra một tiến trình nền, cứ mỗi giờ đọc một tên máy chủ từ một tệp “hòm thư chết” (dead drop) trên GitHub, rồi tải mã Python từ http://<host>/codepy và chạy bằng exec(). Nhờ đó kẻ tấn công vẫn có quyền chạy mã từ xa sau khi đã lấy xong dữ liệu.

Dữ liệu đánh cắp được mã hóa AES-256, khóa phiên được bọc bằng một public key RSA-4096 nhúng sẵn, rồi gửi tới www.litellm.dev, tên miền đăng ký ngày 13/10. StepSecurity lưu ý rằng vì vậy nạn nhân không thể xem gói tin bắt được để biết mình đã mất những gì. Trong image litellm-database còn có một mô-đun truy vấn thẳng vào các bảng lưu API key của nhà cung cấp model trong cơ sở dữ liệu của proxy. Socket thận trọng hơn ở điểm này: đoạn mã cho thấy ý đồ, chưa chứng minh là đã thành công trên hệ thống cụ thể nào.

Wiz, theo Help Net Security, đã ghi nhận dữ liệu bị đem ra dùng. Khoảng bốn tiếng rưỡi sau khi dữ liệu rời máy nạn nhân, kẻ tấn công bắt đầu thử các credential AWS và kiểm tra quyền truy cập Amazon Bedrock. Kiểu tấn công này được gọi là LLMjacking, tức chiếm tài khoản của người khác để dùng model AI và để chủ tài khoản trả tiền. Đến nay chưa có nhóm tấn công nào bị nêu tên công khai.

Nguyên nhân thật: một khóa không ai thu hồi

Bài đăng đầu tiên của LiteLLM ngày 21/10 nghi ngờ token bị lấy từ log của một hệ thống nội bộ để lộ ra Internet, có thể qua một lỗ hổng vừa được vá. Báo cáo ngày 23/10 thay thế cách giải thích đó:

27/5/2026: tệp cấu hình opencode.json được đẩy lên kho công khai LiteLLM-Labs/lite-harness, trong đó có master key của một bản triển khai LiteLLM Agent Platform. Đây là dịch vụ thử nghiệm nội bộ (bản alpha), dùng để chạy các agent tự mở pull request trên GitHub. Báo cáo viết rằng commit đã bị ghi đè bằng force-push và các khóa lộ đã được xác định là cần thu hồi, “tuy nhiên master key đã không được thu hồi”.
10/10: kẻ tấn công dùng khóa này gọi API của Agent Platform. API trả về token GitHub CLI OAuth của một trong hai chủ sở hữu (owner) tổ chức GitHub của LiteLLM. Theo báo cáo, token này “không gắn với tài khoản dịch vụ và không bị giới hạn phạm vi quyền”.
Cùng tối hôm đó: với quyền owner, kẻ tấn công đẩy các nhánh CI tạm có workflow gửi secret của kho mã tới webhook.site. Trong số đó có token GitHub của hai người bảo trì (maintainer) khác, lưu dưới tên GH_TOKEN và RELEASE_PLEASE_TOKEN. Đợt thứ hai ngày 12/10 tiếp tục thu secret từ nhiều kho mã riêng tư.
21/10: cơ chế bảo vệ nhánh (branch protection) từ chối một thay đổi trái phép vào workflow phát hành riêng tư, nhưng năm giây sau token owner đã vô hiệu hóa nó. Trước đó trong tuần, LiteLLM đã nới quy định để hai kỹ sư bất kỳ có thể kích hoạt và phê duyệt một bản phát hành, nhằm đẩy nhanh việc vá lỗi cho các phiên bản cũ (backport). Kẻ tấn công đang giữ token của đúng hai kỹ sư. Sau đó, quy trình phát hành thật đã build, ký số và đăng tải các gói nhiễm độc.
Xóa dấu vết: token của một maintainer thứ ba được dùng để xóa lịch sử các lần chạy workflow, và kẻ tấn công force-push để đưa kho phát hành về trạng thái cũ.

Báo cáo còn nêu một điểm mà mọi tổ chức dùng GitHub nên biết. Token OAuth của GitHub CLI là loại “đã qua bước xác thực hai lớp (2FA)” và không bị yêu cầu xác thực lại khi thực hiện các thao tác nhạy cảm trên tổ chức. Một token gh bị đánh cắp vì thế làm được những việc mà chính chủ tài khoản đăng nhập trên web sẽ bị hỏi lại.

Ý nghĩa vượt ra ngoài LiteLLM

Đây là sự cố chuỗi cung ứng thứ hai trong năm của LiteLLM, sau vụ hồi tháng 3. Nhưng bài học áp dụng cho mọi dự án.

Có provenance không có nghĩa là đáng tin. Các gói độc được build và ký bởi đúng quy trình thật. Trusted publishing (cơ chế đăng gói qua danh tính CI) và attestation chỉ chứng minh workflow nào đã build gói, không chứng minh định nghĩa workflow đó chưa bị chiếm quyền.
Force-push không xóa được bí mật đã lộ. Commit công khai bị các công cụ tự động quét chỉ trong vài phút. Cách khắc phục duy nhất là thu hồi khóa, và ở đây chỉ một khóa trong cả loạt bị bỏ sót cũng đủ gây chuyện.
Cổng phê duyệt chỉ chắc bằng các token có thể vượt qua nó. “Hai kỹ sư” thực chất là hai credential, và cả hai đều là token OAuth cá nhân có thời hạn dài.
Hạ tầng AI gom tụ bí mật. Một AI gateway giữ khóa của mọi nhà cung cấp model, còn agent platform phải cấp token GitHub để agent mở được pull request. Agent càng được cấp credential thật, một dịch vụ alpha mang master key bị bỏ quên càng giống chiếc chìa khóa vạn năng. Việc mã độc nhắm thẳng vào cấu hình của các trợ lý lập trình AI cho thấy kẻ tấn công đã nhận ra điều này.

Nếu nghi ngờ bị ảnh hưởng

LiteLLM và StepSecurity thống nhất ở các bước chính. Đừng bắt đầu bằng pip uninstall, vì mỗi lần Python khởi động là mã độc lại chạy. Trước hết hãy dừng tiến trình đang giữ /tmp/remote_code_loader.lock và xóa cook.pth, cook.py, sitecustomize.py. Sau đó dựng lại môi trường và image từ đầu với 1.106.2 (ghim image theo digest) và chặn tên miền litellm.dev. Nếu bản 1.107.0 đã chạy trên máy có kết nối Internet ra ngoài, hãy coi như dữ liệu đã bị lấy và đổi toàn bộ những gì máy đó truy cập được. Với máy chạy proxy, việc này gồm mọi API key nhà cung cấp lưu trong cơ sở dữ liệu proxy, master key, salt key và mật khẩu cơ sở dữ liệu.

Những câu hỏi còn bỏ ngỏ

LiteLLM chưa công bố số lượt cài đặt bị ảnh hưởng và hẹn “tuần tới” sẽ nêu các thay đổi về quy trình. Công ty cũng chưa cho biết đã khôi phục quy định phê duyệt phát hành chặt chẽ như trước hay chưa, hay sẽ giới hạn quyền của token mà agent platform cấp phát ra sao. Trước khi có các câu trả lời đó, có thể tóm tắt thẳng thắn thế này: một dự án nổi tiếng có quy trình phát hành tưởng như chặt chẽ, nhưng chỉ một khóa lộ từ tháng 5 chưa thu hồi đã đủ để vượt qua tất cả.