Duy Linh✔
Writer
Vụ tấn công LiteLLM vào tháng 3/2026 không đơn thuần là một vụ phát tán gói Python độc hại trong thời gian ngắn trên PyPI. Sự cố cho thấy một điểm yếu trong quy trình phát triển có thể biến cơ sở hạ tầng AI thành kênh giá trị cao để đánh cắp thông tin đăng nhập, xâm nhập môi trường đám mây và lạm dụng chuỗi cung ứng phần mềm.
Hai phiên bản LiteLLM bị ảnh hưởng chỉ tồn tại trên PyPI khoảng 40 phút trước khi được cách ly. Tuy nhiên, khoảng thời gian ngắn này không đồng nghĩa với mức độ rủi ro thấp. Các cơ chế cài đặt phụ thuộc tự động, tạo phẩm được lưu trong bộ nhớ đệm, trình chạy CI tạm thời và môi trường phát triển có thể khiến một bản phát hành bị nhiễm mã độc lan truyền rất nhanh.
LiteLLM xác nhận hai phiên bản bị ảnh hưởng được phát hành lúc 10:39 UTC và bị cách ly khoảng 40 phút sau đó. Theo các báo cáo kỹ thuật công khai, vấn đề ban đầu không xuất phát trực tiếp từ LiteLLM mà bắt đầu từ một lỗ hổng ảnh hưởng đến trình quét bảo mật Trivy được sử dụng trong môi trường CI của LiteLLM.
Một thành phần thượng nguồn bị nhiễm độc đã lan truyền thông qua một đường dẫn phụ thuộc không được ghim. Điều này cho phép kẻ tấn công chiếm được thông tin đăng nhập phục vụ phát hành và đưa các bản dựng LiteLLM bị nhiễm mã độc lên PyPI.
Sự cố cho thấy chuỗi cung ứng phần mềm có thể bị lạm dụng qua nhiều lớp: công cụ bảo mật, hệ thống tự động hóa CI/CD, quy trình xuất bản gói phần mềm và cuối cùng là thư viện cổng AI.
Mã độc được cho là sử dụng một tệp <span>.pth</span> của Python. Cách thức này có thể kích hoạt mã khi trình thông dịch Python khởi động, thay vì chỉ thực thi khi một gói cụ thể được nhập rõ ràng.
Điểm khác biệt này có ý nghĩa lớn về mặt vận hành. Nó có thể vượt qua giả định rằng một gói là an toàn chỉ vì nhà phát triển không trực tiếp gọi gói đó, đồng thời làm giảm hiệu quả của những biện pháp kiểm soát chỉ tập trung vào các tập lệnh chạy trong quá trình cài đặt.
Các nhà nghiên cứu mô tả tải trọng là một chuỗi nhiều giai đoạn, được thiết kế để thu thập thông tin đăng nhập, thiết lập quyền truy cập và nhắm mục tiêu vào môi trường Kubernetes. Nhóm tin tặc TeamPCP được công khai liên kết với chiến dịch này, trong đó các phiên bản LiteLLM độc hại 1.82.7 và 1.82.8 được phát tán lên PyPI ngày 24/3.
Dữ liệu về nguy cơ bị tấn công do CloudSEK công bố xác định hơn 2.500 tổ chức và 434.000 pipeline CI/CD có nguy cơ bị ảnh hưởng. Tuy nhiên, những con số này không đồng nghĩa tất cả các tổ chức được liệt kê đều đã bị tấn công, mất thông tin đăng nhập hoặc tiếp tục bị xâm nhập.
Cổng thông tin về nguy cơ của CloudSEK nên được xem là manh mối để xác thực, thay vì danh sách nạn nhân cuối cùng. Việc xác nhận một tổ chức thực sự bị ảnh hưởng cần dựa trên quá trình kiểm tra riêng tư, thông báo có mục tiêu, rà soát thông tin xác thực và phân tích nhật ký.
Do đó, các tuyên bố công khai chỉ nên dừng ở mức 'có khả năng bị ảnh hưởng' nếu chưa có điều tra độc lập xác nhận việc thực thi gói độc hại, rò rỉ bí mật, truy cập trái phép hoặc sử dụng thông tin đăng nhập bị đánh cắp.
Rủi ro chiến lược của sự cố nằm ở vị trí của LiteLLM trong các hệ thống AI hiện đại. Cổng AI có thể tập trung mã thông báo của nhà cung cấp mô hình, logic định tuyến, tích hợp ứng dụng, dữ liệu quan sát và quyền truy cập vào các dịch vụ nội bộ.
Môi trường thực thi tác nhân và máy chủ Giao thức ngữ cảnh mô hình cũng mở rộng phạm vi tin cậy khi cho phép mô hình gọi công cụ, truy vấn kho dữ liệu và kích hoạt các hành động nghiệp vụ.
Vì vậy, việc xâm phạm lớp này có thể tạo ra đường dẫn không chỉ tới API, lời nhắc và mô hình AI, mà còn tới danh tính, nền tảng đám mây, kho mã nguồn và các quy trình sản xuất liên quan.
Các tổ chức đã cài đặt hoặc thực thi LiteLLM 1.82.7 hoặc 1.82.8 nên giả định rằng mọi thông tin xác thực mà quy trình bị ảnh hưởng có thể truy cập đều cần được thay đổi. Phạm vi này bao gồm thông tin đăng nhập đám mây, mã thông báo GitHub hoặc GitLab, thông tin đăng nhập registry, bí mật Kubernetes, khóa SaaS, cơ sở dữ liệu và khóa API của nhà cung cấp AI.
Các nhóm cũng nên xây dựng lại những runner bị ảnh hưởng từ các image đã được xác minh là sạch, đồng thời điều tra các hoạt động thoát dữ liệu bất thường, kho lưu trữ mới, bản phát hành không mong muốn, hoạt động của token và các sự kiện kiểm toán trên đám mây hoặc cụm máy chủ.
Sự cố LiteLLM nhấn mạnh một vấn đề rộng hơn: cơ sở hạ tầng AI đang trở thành mục tiêu chiến lược trong chuỗi cung ứng phần mềm bởi nó kết hợp dữ liệu, danh tính, năng lực tính toán và thực thi tự động trong cùng một mặt phẳng điều khiển.
Các chuyên gia bảo mật cần mở rộng quản trị phụ thuộc vượt ra ngoài việc đơn thuần quản lý phiên bản gói. Điều này bao gồm gắn các hành động và tạo phẩm CI với các hàm băm đã được xác minh, giảm phạm vi và thời hạn của thông tin xác thực, áp dụng nhận dạng khối lượng công việc và liên tục kiểm kê các cổng AI, tác nhân, kho lưu trữ vectơ, dịch vụ MCP và những triển khai AI bóng.
Hai phiên bản LiteLLM bị ảnh hưởng chỉ tồn tại trên PyPI khoảng 40 phút trước khi được cách ly. Tuy nhiên, khoảng thời gian ngắn này không đồng nghĩa với mức độ rủi ro thấp. Các cơ chế cài đặt phụ thuộc tự động, tạo phẩm được lưu trong bộ nhớ đệm, trình chạy CI tạm thời và môi trường phát triển có thể khiến một bản phát hành bị nhiễm mã độc lan truyền rất nhanh.
LiteLLM xác nhận hai phiên bản bị ảnh hưởng được phát hành lúc 10:39 UTC và bị cách ly khoảng 40 phút sau đó. Theo các báo cáo kỹ thuật công khai, vấn đề ban đầu không xuất phát trực tiếp từ LiteLLM mà bắt đầu từ một lỗ hổng ảnh hưởng đến trình quét bảo mật Trivy được sử dụng trong môi trường CI của LiteLLM.
Một thành phần thượng nguồn bị nhiễm độc đã lan truyền thông qua một đường dẫn phụ thuộc không được ghim. Điều này cho phép kẻ tấn công chiếm được thông tin đăng nhập phục vụ phát hành và đưa các bản dựng LiteLLM bị nhiễm mã độc lên PyPI.
Sự cố cho thấy chuỗi cung ứng phần mềm có thể bị lạm dụng qua nhiều lớp: công cụ bảo mật, hệ thống tự động hóa CI/CD, quy trình xuất bản gói phần mềm và cuối cùng là thư viện cổng AI.
Mã độc được cho là sử dụng một tệp <span>.pth</span> của Python. Cách thức này có thể kích hoạt mã khi trình thông dịch Python khởi động, thay vì chỉ thực thi khi một gói cụ thể được nhập rõ ràng.
Điểm khác biệt này có ý nghĩa lớn về mặt vận hành. Nó có thể vượt qua giả định rằng một gói là an toàn chỉ vì nhà phát triển không trực tiếp gọi gói đó, đồng thời làm giảm hiệu quả của những biện pháp kiểm soát chỉ tập trung vào các tập lệnh chạy trong quá trình cài đặt.
Các nhà nghiên cứu mô tả tải trọng là một chuỗi nhiều giai đoạn, được thiết kế để thu thập thông tin đăng nhập, thiết lập quyền truy cập và nhắm mục tiêu vào môi trường Kubernetes. Nhóm tin tặc TeamPCP được công khai liên kết với chiến dịch này, trong đó các phiên bản LiteLLM độc hại 1.82.7 và 1.82.8 được phát tán lên PyPI ngày 24/3.
Cơ sở hạ tầng AI trở thành mục tiêu có giá trị cao
Với những môi trường bị ảnh hưởng, rủi ro không chỉ nằm ở cấu hình của LiteLLM. Một tiến trình hoạt động trong môi trường xây dựng với quyền truy cập phù hợp có thể tiếp cận khóa đám mây, mã thông báo kho lưu trữ, khóa SSH, mã thông báo tài khoản dịch vụ Kubernetes, thông tin xác thực xuất bản gói, biến môi trường và khóa của các nhà cung cấp LLM.Dữ liệu về nguy cơ bị tấn công do CloudSEK công bố xác định hơn 2.500 tổ chức và 434.000 pipeline CI/CD có nguy cơ bị ảnh hưởng. Tuy nhiên, những con số này không đồng nghĩa tất cả các tổ chức được liệt kê đều đã bị tấn công, mất thông tin đăng nhập hoặc tiếp tục bị xâm nhập.
Cổng thông tin về nguy cơ của CloudSEK nên được xem là manh mối để xác thực, thay vì danh sách nạn nhân cuối cùng. Việc xác nhận một tổ chức thực sự bị ảnh hưởng cần dựa trên quá trình kiểm tra riêng tư, thông báo có mục tiêu, rà soát thông tin xác thực và phân tích nhật ký.
Do đó, các tuyên bố công khai chỉ nên dừng ở mức 'có khả năng bị ảnh hưởng' nếu chưa có điều tra độc lập xác nhận việc thực thi gói độc hại, rò rỉ bí mật, truy cập trái phép hoặc sử dụng thông tin đăng nhập bị đánh cắp.
Rủi ro chiến lược của sự cố nằm ở vị trí của LiteLLM trong các hệ thống AI hiện đại. Cổng AI có thể tập trung mã thông báo của nhà cung cấp mô hình, logic định tuyến, tích hợp ứng dụng, dữ liệu quan sát và quyền truy cập vào các dịch vụ nội bộ.
Môi trường thực thi tác nhân và máy chủ Giao thức ngữ cảnh mô hình cũng mở rộng phạm vi tin cậy khi cho phép mô hình gọi công cụ, truy vấn kho dữ liệu và kích hoạt các hành động nghiệp vụ.
Vì vậy, việc xâm phạm lớp này có thể tạo ra đường dẫn không chỉ tới API, lời nhắc và mô hình AI, mà còn tới danh tính, nền tảng đám mây, kho mã nguồn và các quy trình sản xuất liên quan.
Các tổ chức đã cài đặt hoặc thực thi LiteLLM 1.82.7 hoặc 1.82.8 nên giả định rằng mọi thông tin xác thực mà quy trình bị ảnh hưởng có thể truy cập đều cần được thay đổi. Phạm vi này bao gồm thông tin đăng nhập đám mây, mã thông báo GitHub hoặc GitLab, thông tin đăng nhập registry, bí mật Kubernetes, khóa SaaS, cơ sở dữ liệu và khóa API của nhà cung cấp AI.
Các nhóm cũng nên xây dựng lại những runner bị ảnh hưởng từ các image đã được xác minh là sạch, đồng thời điều tra các hoạt động thoát dữ liệu bất thường, kho lưu trữ mới, bản phát hành không mong muốn, hoạt động của token và các sự kiện kiểm toán trên đám mây hoặc cụm máy chủ.
Sự cố LiteLLM nhấn mạnh một vấn đề rộng hơn: cơ sở hạ tầng AI đang trở thành mục tiêu chiến lược trong chuỗi cung ứng phần mềm bởi nó kết hợp dữ liệu, danh tính, năng lực tính toán và thực thi tự động trong cùng một mặt phẳng điều khiển.
Các chuyên gia bảo mật cần mở rộng quản trị phụ thuộc vượt ra ngoài việc đơn thuần quản lý phiên bản gói. Điều này bao gồm gắn các hành động và tạo phẩm CI với các hàm băm đã được xác minh, giảm phạm vi và thời hạn của thông tin xác thực, áp dụng nhận dạng khối lượng công việc và liên tục kiểm kê các cổng AI, tác nhân, kho lưu trữ vectơ, dịch vụ MCP và những triển khai AI bóng.
Được phối hợp thực hiện bởi các chuyên gia của Bkav,
cộng đồng An ninh mạng Việt Nam WhiteHat
và cộng đồng Khoa học công nghệ VnReview
