LiteLLM 1.107.0 bị cài mã độc: kiểm tra đúng gói đã chạy

LiteLLM ngày 21/10/2026 xác nhận bản phát hành 1.107.0 trên PyPI và các image container liên quan đã bị chèn mã độc, với khả năng đánh cắp thông tin xác thực và tải mã từ xa. Sự cố nằm ở chuỗi tạo, phát hành gói; kiểm tra mã nguồn trong GitHub không đủ xác nhận gói đã cài là an toàn.

Đối tượng cần rà soát gồm máy lập trình, môi trường CI và dịch vụ AI gateway từng cài hoặc chạy artifact bị ảnh hưởng. Chỉ đổi phiên bản trong tệp cấu hình chưa xử lý được những khóa đã có thể bị đọc trước đó.

Phạm vi phải xác định theo artifact, không chỉ tên dự án

Báo cáo của nhóm duy trì xác nhận bảy wheel PyPI 1.107.0 bị ảnh hưởng. Gói độc xuất hiện khoảng 11:39–13:23 UTC ngày 21/10, tương đương 18:39–20:23 giờ Việt Nam. Các tag Docker gồm v1.107.0, latest, main-latest và main-stable cũng từng trỏ tới image bị xâm phạm.

Tag là nhãn có thể thay đổi. Một container chạy với tên latest không nhất thiết hiển thị ngay phiên bản 1.107.0 trong lịch sử triển khai, nên cần đối chiếu cả thời điểm kéo image và digest thực tế. Theo dự án, registry enterprise riêng không chịu ảnh hưởng của sự cố này.

Nhóm duy trì cho biết tag mã nguồn v1.107.0 chính thức không chứa các tệp độc, trong khi artifact bị xâm phạm được xây từ repository do kẻ tấn công kiểm soát. Phân biệt này giúp tránh hai kết luận sai: mọi mã trong dự án đều độc, hoặc repository sạch đồng nghĩa gói phân phối cũng sạch.

Mã có thể chạy trước khi ứng dụng import LiteLLM

Phân tích trực tiếp của JFrog Security Research mô tả các tệp được thêm vào khu vực site-packages, tận dụng cơ chế khởi động Python. Vì thế, hành vi độc có thể được kích hoạt khi trình thông dịch chạy, kể cả ứng dụng chưa gọi import litellm.

Điều này thay đổi cách xử lý sự cố. Một thao tác quản trị tưởng như vô hại trong chính môi trường bị ảnh hưởng có thể khởi động Python thêm lần nữa. Nhóm duy trì cảnh báo không bắt đầu khắc phục bằng việc chạy pip ngay trong môi trường đó.

JFrog cũng phân biệt wheel với bản phân phối mã nguồn. Kiểm tra một tag hoặc một loại gói duy nhất không cho thấy đầy đủ những gì hệ thống thực sự cài. Đây là vấn đề về tính toàn vẹn của đầu ra phát hành, vượt ra ngoài việc duyệt các thay đổi trong mã ứng dụng.

Vì sao AI gateway làm phạm vi khóa cần rà soát rộng hơn?

Tài liệu LiteLLM mô tả gateway như điểm chung để ứng dụng gọi nhiều nhà cung cấp mô hình, quản lý khóa và ngân sách, đồng thời ghi nhận chi phí. Vai trò tập trung ấy thuận tiện cho vận hành, nhưng cũng khiến thông tin xác thực mà tiến trình tiếp cận trở thành tài sản quan trọng.

Mend.io báo cáo mã đánh cắp tìm tới nhiều nhóm bí mật, gồm khóa đám mây, thông tin phát triển và dữ liệu cấu hình. Với một proxy có cơ sở dữ liệu được cấu hình, các khóa nhà cung cấp mô hình lưu trong hệ thống cũng nằm trong phạm vi cần xem xét.

Không có căn cứ để suy rằng chỉ cần đổi một API key là đủ cho mọi triển khai. Danh mục thu hồi phải dựa trên những gì máy hoặc container có quyền đọc: biến môi trường, tài khoản dịch vụ, token CI và các bí mật có thể truy cập từ tiến trình bị ảnh hưởng.

Khôi phục phần mềm và thu hồi quyền là hai việc riêng

Nhóm duy trì khuyến nghị xây lại image hoặc môi trường ảo từ nguồn sạch, ghim vào phiên bản đã được xác nhận, đồng thời thu hồi và thay các thông tin xác thực có thể bị lộ. Tại bản cập nhật được đọc cho bài này, mốc được dự án khuyến nghị là 1.106.2 hoặc phiên bản chỉ định phát hành trước sự cố.

Với trường hợp nghi đã chạy artifact độc, nên xử lý như một sự cố bảo mật: cô lập môi trường, giữ bằng chứng phù hợp, xác định phạm vi truy cập rồi xây lại và kiểm tra hoạt động sử dụng khóa. Bài này không chạy mẫu mã độc và không xác nhận tình trạng của hệ thống của độc giả.

Không tìm thấy một tệp chỉ dấu không chứng minh môi trường sạch. Container có thể đã khởi động lại hoặc tệp tạm đã mất. Ngược lại, việc một tag nay trỏ tới image sạch không thay đổi lịch sử artifact từng được kéo về và thực thi.

Hướng điều tra nguyên nhân vẫn cần theo các cập nhật của dự án. Đối với đội sử dụng, kết quả cần đạt không chỉ là hết phiên bản 1.107.0: còn phải xác nhận artifact thay thế, phạm vi bí mật đã thu hồi và dấu vết sử dụng trái phép sau thời điểm phơi nhiễm.

Nguồn và ảnh nhận diện

Nguồn: báo cáo LiteLLM ngày 21/10, JFrog, Mend.io và tài liệu gateway. Thời gian phân phối nêu theo nhóm duy trì; không diễn giải thời gian nhóm bảo mật đăng xác nhận thành thời gian chính xác gỡ mọi artifact.

Ảnh: biểu tượng LiteLLM, bản PNG từ selfh.st/icons qua trang nguồn, giấy phép CC BY 4.0; giữ nguyên ảnh, ghi công selfh.st/icons. Đây là ảnh nhận diện phần mềm, không phải ảnh bằng chứng tấn công hoặc sự bảo trợ của dự án.