Các báo cáo hiện có và phân tích từ giới nghiên cứu bảo mật cho biết LiteLLM 1.107.0 là bản phát hành chứa mã độc, được phân phối ngày 21/10/2026 qua PyPI và một số thẻ container chính thức. Phiên bản được báo cáo là an toàn để hạ cấp là 1.106.2. Với những người đã cài đặt hoặc chạy các thành phần bị ảnh hưởng, biện pháp cần làm không chỉ là nâng cấp thông thường: cô lập môi trường, dựng lại từ nền tảng sạch và luân chuyển toàn bộ thông tin xác thực có thể truy cập.

Những thành phần LiteLLM nào được báo cáo đã bị xâm phạm

Các thông tin hiện có cho thấy LiteLLM 1.107.0 là bản phát hành bị xâm phạm, với phạm vi ảnh hưởng được cho là bao gồm cả gói PyPI lẫn các ảnh container chính thức. Cảnh báo được cung cấp nêu các gói PyPI và ảnh Docker, bao gồm latest và main-stable; trong khi các báo cáo bảo mật của Wiz và Aikido cũng đề cập v1.107.0 cùng main-latest.

Phạm vi này quan trọng vì một số người dùng bị ảnh hưởng có thể không trực tiếp chọn 1.107.0. Các đội ngũ sử dụng thẻ ảnh thay đổi theo thời gian có thể đã kéo về một bản dựng nhiễm độc theo quy trình triển khai thông thường, thay vì chủ động nâng phiên bản.

Trong phạm vi được báo cáo, các thông tin đáng chú ý nhất hiện nay gồm:

Thời điểm dọn dẹp trên các kênh không hoàn toàn trùng khớp trong các báo cáo hiện có. Một đoạn trích từ issue GitHub liên quan đến BerriAI/litellm cho biết PyPI đã được làm sạch, trong khi các thẻ Docker trôi nổi tại một thời điểm ngày 21/10 vẫn bị nhiễm; Wiz sau đó mô tả các thẻ này đã bị gỡ bỏ. Điều này củng cố bức tranh tổng thể về sự cố, nhưng không xác định một mốc hoàn tất dọn dẹp duy nhất.

Vì sao payload được báo cáo đặc biệt rủi ro

JFrog cho biết gói wheel LiteLLM độc hại đã sử dụng hook khởi động Python, cho phép payload chạy khi Python khởi động trong môi trường bị ảnh hưởng, thay vì phải chờ ứng dụng trực tiếp import LiteLLM. Trong đoạn trích hiện có, JFrog quy hành vi này cho tệp cook.pth, được xử lý trong quá trình khởi tạo site thông thường của Python.

Nếu cơ chế này thực sự tồn tại, ranh giới phơi nhiễm sẽ rộng hơn nhiều so với việc gọi một thư viện lỗi. Việc khởi động Python trong môi trường bị ảnh hưởng có thể kích hoạt logic đánh cắp thông tin xác thực, lý giải vì sao hướng dẫn ứng phó tập trung vào cô lập và luân chuyển bí mật, thay vì chỉ thay thế một phiên bản gói.

Cảnh báo được cung cấp cho biết dữ liệu nhạy cảm có nguy cơ bị lộ gồm thông tin xác thực đám mây, khóa API AI và khóa riêng SSH. Các báo cáo riêng vào tháng 3/2026 đã tóm tắt một bài đăng của Andrej Karpathy, trong đó mô tả một cuộc tấn công LiteLLM PyPI rộng hơn, đánh cắp khóa SSH, thông tin xác thực đám mây, cấu hình Kubernetes, thông tin xác thực Git, biến môi trường, khóa CI/CD và mật khẩu cơ sở dữ liệu. Tuy nhiên, báo cáo trước đó không xác lập phạm vi thẻ Docker hoặc danh sách chính xác các thành phần 1.107.0 trong sự kiện tháng 10.

Người dùng bị ảnh hưởng nên làm gì ngay

Biện pháp ứng phó được báo cáo là ngừng sử dụng 1.107.0, hạ cấp hoặc khóa về 1.106.2, cô lập mọi máy chủ hoặc container từng cài đặt hay chạy thành phần bị ảnh hưởng, dựng lại từ môi trường sạch và luân chuyển các thông tin xác thực mà môi trường đó có thể truy cập. Aikido và JFrog đều đặt trọng tâm vào việc gói hoặc ảnh độc hại có từng được cài đặt hay thực thi hay không, chứ không phải liệu chúng hiện còn sẵn có hay không.

Sự khác biệt này rất quan trọng. Nâng cấp tại chỗ có thể loại bỏ phiên bản độc hại cho các lần sử dụng sau, nhưng không thể trả lời liệu bí mật đã bị lộ trong thời gian gói wheel hoặc ảnh nhiễm độc hoạt động hay chưa.

Với đội ngũ vận hành, ngưỡng kích hoạt hành động cần được hiểu theo diện rộng: bất kỳ ai đã cài litellm==1.107.0, kéo một thẻ trôi nổi được báo cáo là bị ảnh hưởng hoặc khởi động Python trong môi trường phơi nhiễm đều nên coi máy chủ hoặc container có nguy cơ bị xâm phạm. Các báo cáo hiện có ủng hộ việc dựng lại từ ảnh hoặc môi trường sạch, đồng thời luân chuyển mọi thông tin xác thực đám mây, API, SSH, cơ sở dữ liệu hoặc loại tương tự mà môi trường chạy đó có thể truy cập.