LiteLLM 1.107.0 Bị Cài Mã Độc Trên PyPI Và Docker, Đánh Cắp Khoá API Và Mở Cửa Hậu

Ngày 21/10/2026 bản LiteLLM 1.107.0 bị cài mã đánh cắp thông tin đăng nhập và cửa hậu chạy mỗi giờ; theo LiteLLM, gói PyPI tải được từ 11:39 đến 13:23 UTC và image Docker đến 14:20, bản sạch gần nhất là 1.106.2. Theo LiteLLM, kẻ tấn công dùng token GitHub CLI của ba kỹ sư để chạy quy trình phát hành

Ngày 21/10/2026, bản LiteLLM 1.107.0, thư viện và máy chủ trung gian nhiều đội dùng để gọi nhiều nhà cung cấp mô hình AI qua một giao diện chung, bị cài mã độc đánh cắp thông tin đăng nhập và một cửa hậu chạy mỗi giờ. Gói xuất hiện trên PyPI từ 11:39 UTC và các image Docker từ 11:46 UTC; theo chính LiteLLM, gói PyPI bị gỡ lúc 13:23 và Docker Hub được dọn lúc 14:20. Ai cài hoặc chạy các bản đó trong khung giờ này nên coi máy là đã bị xâm nhập và đổi toàn bộ khoá. Bản sạch gần nhất là 1.106.2.

Chuyện gì đã xảy ra

Theo bài sự cố LiteLLM đăng ngày 21/10 (cập nhật lần cuối 20:30 UTC, tình trạng "đã khoanh vùng, điều tra tiếp tục"), quy trình phát hành của họ bị xâm nhập vào sáng sớm 21/10 và đẩy 1.107.0 lên PyPI và các kho Docker. Bản này chứa mã độc đã biên dịch, đánh cắp thông tin đăng nhập và nạp công cụ thực thi mã từ xa. Thẻ v1.107.0 trên GitHub chính thức không chứa các tệp độc; gói được dựng từ một kho do kẻ tấn công kiểm soát.

Các nguồn không hoàn toàn khớp ở mép khung giờ: Wiz ghi PyPI cách ly từ 13:20, SafeDep quan sát thấy 1.107.0 đã biến mất lúc 13:40, còn LiteLLM ghi 13:23. Bài này dùng số của LiteLLM vì đó là bên vận hành kho; chênh lệch chỉ vài phút. LiteLLM cũng nói khách hàng lấy bản doanh nghiệp từ kho riêng của hãng không bị ảnh hưởng.

Mã độc làm gì

SafeDep và Wiz, hai hãng bảo mật phân tích độc lập, mô tả giống nhau về cơ bản. Cài 1.107.0 thả ba tệp vào thư mục site-packages: cook.pth, cook.py và sitecustomize.py. Python nạp chúng mỗi lần khởi động, kể cả khi chưa từng import litellm, nên pip, trình soạn thảo và công việc CI trên máy đó đều chạy mã độc.

• Đánh cắp thông tin (cook.py). Theo SafeDep, gồm 16 mô-đun nhắm vào khoá SSH, thông tin đăng nhập AWS, Azure, Google Cloud, Kubernetes, Docker, bí mật CI/CD, mật khẩu trình duyệt, khoá GPG và TLS, token của các công cụ AI (Claude Code, Cursor, Codex, Gemini CLI, Hugging Face và nhiều công cụ khác), biến môi trường, và đọc trực tiếp bảng khoá nhà cung cấp mô hình trong cơ sở dữ liệu của LiteLLM Proxy. Dữ liệu được mã hoá rồi gửi tới một tên miền giả danh LiteLLM.
• Cửa hậu (sitecustomize.py). Một tiến trình nền, mỗi giờ đọc địa chỉ máy chủ từ một tệp trong kho GitHub của kẻ tấn công, chạy lại bộ đánh cắp và tải mã giai đoạn hai về chạy. Theo Wiz, tệp địa chỉ chưa bao giờ được điền ngoài giá trị thử, và kho đã bị GitHub gỡ lúc khoảng 13:30 UTC; SafeDep nói không khôi phục được địa chỉ máy chủ và cảnh báo máy nào đã chạy tiến trình nền trước khi kho bị xoá có thể đã nhận mã giai đoạn hai. Hai nhận định này không mâu thuẫn nhưng cũng chưa loại trừ nhau: chưa ai cho thấy có máy nào nhận mã giai đoạn hai, và chưa ai chứng minh là không.

Wiz còn đánh giá mã độc có "dấu hiệu rõ rệt của việc viết với sự hỗ trợ của mô hình ngôn ngữ" (tên biến dài dòng, xử lý lỗi quá rộng, một mô-đun chết chưa từng được gọi) và việc dùng đồng thời .pth và sitecustomize.py là "trường hợp đầu tiên được ghi nhận ngoài thực tế". Cả hai là đánh giá của Wiz, Locaith chưa kiểm được.

Kẻ tấn công vào bằng cách nào: lời LiteLLM kể

Đây là phần LiteLLM tự thuật và đang còn điều tra. Sau sự cố tháng 3, hãng nói đã siết quy trình: phát hành từ kho riêng, dùng Trusted Publishers của GitHub, thẻ Docker bất biến, ký image. Theo bài, kẻ tấn công có thông tin đăng nhập GitHub CLI (dạng OAuth token) của ba kỹ sư. Một trong ba token thuộc một trong hai chủ sở hữu tổ chức GitHub; kẻ tấn công dùng nó để tắt bảo vệ nhánh và đẩy cưỡng bức thay đổi cho phép quy trình phát hành trỏ sang kho nguồn khác. Lúc 10:08 bảo vệ nhánh từng từ chối một thay đổi trái phép, năm giây sau một thông tin đăng nhập có quyền cao đã vượt qua. Quy trình chạy trên kho giả Berri-AI/litellm (gạch nối, giống tên tổ chức thật BerriAI), token của kỹ sư thứ hai được dùng để duyệt bước sản xuất, và token của kỹ sư thứ ba xoá hồ sơ chạy quy trình lúc 11:53 để hạn chế nhật ký điều tra. Wiz thêm rằng kẻ tấn công đẩy 10 commit lên kho giả từ 08:56 đến 10:46 UTC.

Về nguồn gốc các token, LiteLLM viết rằng họ quan sát thấy "trong một số tình huống cụ thể, Claude Code sẽ nhúng OAuth token của GitHub CLI vào nội dung phản hồi", và khi nội dung phản hồi được ghi nhật ký thì token có thể nằm trong nhật ký LiteLLM. Họ tìm thấy một tài khoản tên vô hại trong hệ thống LiteLLM nội bộ đang mở ra Internet, cho rằng kẻ tấn công lấy token từ nhật ký đó, và nghi ngờ kẻ tấn công vào hệ thống này nhờ một lỗ hổng vừa được vá nhưng chưa xác nhận. Locaith lưu ý đây là giả thuyết của LiteLLM đang điều tra, đến ngày 22/10 chúng tôi không tìm thấy phản hồi nào từ Anthropic về nhận định liên quan đến Claude Code. SafeDep, phân tích từ hiện vật phát hành chứ không từ nhật ký của LiteLLM, đi đến kết luận tương thích: gói được dựng từ nguồn git bị sửa trong quy trình riêng của BerriAI, không có lần chạy GitHub Actions công khai nào dựng ra nó.

Nếu đã cài hoặc chạy 1.107.0 thì làm gì

Phần dưới đây theo hướng dẫn trong bài của LiteLLM (do một người phát hiện sự cố đóng góp); các tên tệp, tên miền và dấu hiệu nhận biết lấy từ SafeDep và Wiz.

• Xác định có bị ảnh hưởng không. Nếu môi trường đã khởi động Python với litellm==1.107.0 (kiểm bằng pip show litellm) hoặc container chạy image có digest nêu trong bài LiteLLM, coi là đã bị xâm nhập. Tìm thư mục litellm-1.107.0.dist-info, cook.pth và sitecustomize.py; thấy một cái là xác nhận bị ảnh hưởng, không thấy thì chưa chứng minh sạch.
• Đừng bắt đầu bằng pip install. Mỗi lần Python khởi động trong môi trường đó là chạy lại mã độc, kể cả khi chạy pip. Xoá cook.pth, cook.py, sitecustomize.py và các tệp .pyc tương ứng khỏi mọi thư mục site-packages, kết thúc tiến trình Python nền (nó giữ khoá /tmp/remote_code_loader.lock), rồi cài lại ghim ở 1.106.2, tốt hơn là dựng lại toàn bộ image và môi trường ảo.
• Đổi mọi thứ máy đó chạm tới được. Vai trò IAM của instance hoặc tác vụ, mọi khoá nhà cung cấp trong cơ sở dữ liệu LiteLLM Proxy cùng khoá master và khoá ảo, mật khẩu DATABASE_URL, và mọi bí mật nằm trong biến môi trường của bất kỳ tiến trình nào trên máy. Nếu máy có Internet ra ngoài, coi như dữ liệu đã bị gửi đi; tệp /tmp/.pc_once_72129118c59f5636c0bb có mặt là xác nhận, vắng mặt không chứng minh gì vì container và dọn thư mục tạm xoá nó.
• Với AWS, LiteLLM khuyên kiểm CloudTrail tìm lệnh GetCallerIdentity từ vai trò của instance quanh thời điểm cài, rồi tìm việc dùng thông tin vai trò đó từ bên ngoài hạ tầng của mình.

Bài học thực dụng cho đội dùng thư viện AI

Phần này là khuyến nghị của Locaith, không phải của các nguồn trên. Cơ hội của kẻ tấn công ở đây là các môi trường cài bản mới nhất không ghim phiên bản; LiteLLM nói rõ người bị ảnh hưởng là người dùng "một phiên bản không ghim". Ghim phiên bản chính xác và băm tệp trong tệp khoá phụ thuộc (ví dụ pip install --require-hashes), không cho CI tự nâng cấp lên bản vừa ra trong vài giờ đầu, và tách khoá nhà cung cấp mô hình thành loại có hạn mức chi tiêu thấp, để một lần lộ không biến thành hoá đơn lớn. Với bất kỳ cổng AI nào chứa khoá của nhiều nhà cung cấp, hãy hỏi nó đang chạy bản nào, ai đẩy bản đó, và khoá nằm ở đâu.

Giới hạn của bài này

Locaith đọc ngày 22/10/2026 bài sự cố của LiteLLM (cập nhật 20:30 UTC ngày 21/10), bài của Wiz (cập nhật đến 21:45 UTC) và bài của SafeDep. Locaith không tải hay phân tích gói độc, không tự kiểm hash, và không xác minh độc lập chuỗi tấn công LiteLLM mô tả. Số lượng khách hàng hay máy bị ảnh hưởng chưa được công bố ở bất kỳ nguồn nào chúng tôi đọc. LiteLLM nói sẽ cập nhật mỗi hai giờ; nếu có thay đổi sau thời điểm đọc, bài này chưa phản ánh.

Openclaw bot: Những thông tin chấn động gần đây

Tìm hiểu về Clawbot, Picoclaw và tốc độ xử lý vượt trội gấp 200 lần trên phần cứng phổ thông.

GPT 5.4: Bước nhảy vọt về Context và Coding

Khám phá sức mạnh của model GPT 5.4 mới nhất trong việc hỗ trợ lập trình viên và xử lý ngữ cảnh sâu.