LiteLLM trên PyPI bị TeamPCP tấn công: Phân tích chuyên sâu về chiến dịch phần mềm độc hại đánh cắp thông tin đăng nhập.

Trang chủ » Python » LiteLLM trên PyPI bị TeamPCP tấn công: Phân tích chuyên sâu về chiến dịch phần mềm độc hại đánh cắp thông tin đăng nhập.

Trong vài giờ vào ngày 24 tháng 3 năm 2026, một gói Python cực kỳ phổ biến đã âm thầm biến thành một công cụ đánh cắp thông tin đăng nhập mạnh mẽ. Hai phiên bản bị nhiễm độc của LiteLLM, một thư viện được sử dụng rộng rãi như một... Giao diện thống nhất cho các mô hình ngôn ngữ lớn (LLM)Các mã nguồn này đã được tải lên PyPI, vô tình khiến một số lượng lớn hệ thống dễ bị tấn công chuỗi cung ứng tinh vi.

Các phiên bản độc hại, 1.82.7 và 1.82.8Phần mềm độc hại này được đóng gói thành một gói tải trọng nhiều giai đoạn có khả năng đánh cắp thông tin bí mật từ máy tính của nhà phát triển, trình chạy CI/CD, cơ sở hạ tầng đám mây và cụm Kubernetes, sau đó chuyển chúng đến các máy chủ do kẻ tấn công kiểm soát. Chiến dịch này đã được thực hiện... có liên quan đến nhóm tội phạm mạng TeamPCP., vốn đã liên tục tấn công Trivy, các công cụ Checkmarx, ảnh Docker trong nhiều tháng qua, các cuộc tấn công vào chuỗi cung ứng npm và giờ là hệ sinh thái PyPI.

LiteLLM là gì và tại sao nó lại trở thành mục tiêu hàng đầu?

LiteLLM là một Thư viện Python mã nguồn mở và máy chủ proxy Nó hoạt động như một loại bộ chuyển đổi đa năng cho các API LLM. Nó cho phép các ứng dụng giao tiếp với hơn một trăm mô hình khác nhau – từ các nhà cung cấp như OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI và những nhà cung cấp khác – thông qua một API duy nhất theo kiểu OpenAI.

Do vai trò đó, dự án đã trở nên gắn bó sâu sắc với hệ sinh thái AI. Báo cáo từ nhiều nhà cung cấp bảo mật cho thấy LiteLLM có khoảng... 3-3.4 triệu lượt tải xuống mỗi ngày, với một số dữ liệu đo từ xa cho thấy nó hiện diện ở khoảng 36% môi trường đám mây được giám sátĐối với tin tặc, việc xâm nhập một gói phần mềm có dấu vết như vậy представляет một cơ hội hiếm có để khai thác một lượng lớn dữ liệu và thông tin đăng nhập nhạy cảm chỉ bằng một thao tác.

Theo thiết kế, LiteLLM thường nằm ở vị trí trung gian giữa... ứng dụng và nhiều nhà cung cấp dịch vụ AIVị trí đó đồng nghĩa với việc nó thường xuyên xử lý các khóa API, biến môi trường, tệp cấu hình và các bí mật khác cần thiết để truy cập các điểm cuối LLM bên ngoài. Một cửa hậu trong sự phụ thuộc như vậy có thể âm thầm chặn và đánh cắp các giá trị đó mà không cần xâm nhập trực tiếp vào các nền tảng thượng nguồn.

Sự cố này cũng nhấn mạnh mức độ liên kết chặt chẽ của quá trình phát triển hiện đại: các máy trạm cục bộ, đường dẫn CI/CD, cụm Kubernetes và tài khoản đám mây đều được kết nối với nhau thông qua các bí mật được chia sẻ và tự động hóa. Một sự cố duy nhất sự phụ thuộc bị tổn hại trong biểu đồ đó Điều này có thể dẫn đến việc lộ thông tin đăng nhập trên nhiều lớp trong hệ thống của tổ chức, khuếch đại tác động vượt xa phạm vi của một máy chủ duy nhất.

Cách các phiên bản LiteLLM độc hại được đưa vào

Các chất độc được giải phóng LiteLLM 1.82.7 và 1.82.8 đã được đẩy lên PyPI vào sáng ngày 24 tháng 3 năm 2026, khoảng... 08:30 giờ UTCChúng vẫn khả dụng trong gần hai giờ trước khi bị nhóm bảo mật PyPI cách ly và chặn bởi các hệ thống phòng thủ của bên thứ ba, và việc gỡ bỏ được báo cáo vào khoảng thời gian đó. 11:25 giờ UTC.

Điều khiến vụ án này đáng chú ý là... Cửa hậu không xuất hiện trong mã nguồn GitHub tương ứng.Endor Labs và các nhà nghiên cứu khác phát hiện ra rằng logic độc hại được chèn vào gói phần mềm đã được biên dịch và phân phối trên PyPI, chứ không phải vào kho lưu trữ công khai, cho thấy sự xâm nhập xảy ra trong hoặc sau quá trình biên dịch/xuất bản chứ không phải thông qua một bản cam kết mã có thể nhìn thấy được.

Cụ thể, các nhà phân tích nhận thấy rằng tệp tin litellm/proxy/proxy_server.py chứa một tải trọng được mã hóa base64 nhúng, không có trong cùng một tệp trong bản cam kết trên GitHub.Khoảng mười hai dòng mã đã được chèn vào giữa các khối mã hợp lệ (ví dụ, gần phần định nghĩa của...). REALTIME_REQUEST_SCOPE_TEMPLATE và showwarning (hàm). Những dòng bổ sung đó âm thầm giải mã và thực thi một đoạn mã ẩn mỗi khi mô-đun được nhập.

Trong phiên bản 1.82.8, những kẻ tấn công đã tiến thêm một bước nữa bằng cách thả xuống một .pth tệp có tên litellm_init.pth vào môi trường Python. Bởi vì Python xử lý tất cả .pth các tập tin khi trình thông dịch khởi động, điều này đảm bảo rằng tải trọng sẽ được chạy. mỗi khi gọi hàm Python, ngay cả khi LiteLLM chưa từng được ứng dụng nhập khẩu.

Sự leo thang này đã 1.82.8 nguy hiểm hơn đáng kểBất kỳ tập lệnh Python, trình chạy thử nghiệm, công cụ xây dựng hoặc công cụ tự động hóa nào được khởi chạy trong môi trường có cài đặt gói bị xâm phạm đều sẽ âm thầm kích hoạt logic đánh cắp thông tin đăng nhập trong nền.

Kết nối với chiến dịch TeamPCP rộng lớn hơn

Vụ xâm phạm LiteLLM không xảy ra một cách riêng lẻ. Các cuộc điều tra của Sonatype, Wiz, Endor Labs và những đơn vị khác đã liên kết nó với một vụ việc khác. Chiến dịch chuỗi cung ứng đang diễn ra do TeamPCP thực hiện, một nhóm thu hút sự chú ý vào cuối năm 2025 và kể từ đó đã nhắm mục tiêu vào một loạt các dự án mã nguồn mở và hệ sinh thái nhà phát triển.

Đầu tháng 3, những đối tượng này cũng bị cáo buộc liên quan đến vụ tấn công cài cửa hậu vào hệ thống. Câu đố của Aqua Security công cụ quét lỗ hổng bảo mật và các GitHub Actions liên quan, cũng như các biến thể độc hại của công cụ Checkmarx, bao gồm KICSChiến dịch này cũng đã đề cập đến GitHub Actions và các tiện ích mở rộng OpenVSX. Nó cũng bao gồm các gói npm, ảnh Docker Hub và môi trường Kubernetes, thường xuyên tái sử dụng cơ sở hạ tầng, các lược đồ mã hóa và các thành phần lưu trữ dữ liệu.

Khi truy tìm lại sự cố LiteLLM, những người bảo trì đã tiết lộ rằng... Mã thông báo xuất bản PyPI Mã thông báo được lưu trữ dưới dạng biến môi trường trong kho lưu trữ GitHub của LiteLLM đã bị đánh cắp thông qua quy trình làm việc Trivy bị xâm phạm. Mã thông báo đó sau đó đã bị lạm dụng để công bố các bản phát hành PyPI bị lỗiĐiều này cho phép kẻ tấn công vượt qua các biện pháp bảo vệ xác thực hai yếu tố trên tài khoản người dùng và chèn các gói phần mềm độc hại mà không cần thay đổi mã nguồn công khai.

Các nhà nghiên cứu cũng chỉ ra những cam kết và quy trình làm việc đáng ngờ được tạo ra vào khoảng ngày 23 tháng 3 trong các kho lưu trữ liên quan đến LiteLLM, bao gồm một nhánh tồn tại trong thời gian ngắn và một quy trình làm việc GitHub Actions mang khóa công khai RSA quen thuộc thường thấy trong các payload TeamPCP khác. Dữ liệu đo từ các lần chạy quy trình làm việc cho thấy rằng các bí mật có sẵn cho các trình chạy CI đó có thể đã bị truy cập và đánh cắp.

Trong các vụ việc khác nhau, nhóm này đã thể hiện một mô hình nhất quán: Đánh cắp thông tin đăng nhập trong một môi trường, sau đó chuyển sang hệ sinh thái tiếp theo.Trong trường hợp này, một lỗi cấu hình trong GitHub Actions của Trivy đã cho phép đánh cắp một mã thông báo đặc quyền; mã thông báo đó dẫn đến việc phát hành các bản vá lỗi Trivy và ảnh Docker độc hại; từ đó, chúng tạo điều kiện cho việc xâm phạm công cụ Checkmarx và cuối cùng là gói LiteLLM trên PyPI.

Cách thức hoạt động của phần mềm độc hại LiteLLM

Các phân tích từ nhiều nhà cung cấp mô tả lỗ hổng bảo mật LiteLLM như một... Payload Python đa giai đoạn, được mã hóa base64 Được thiết kế để hoạt động bí mật, linh hoạt và bền bỉ. Logic được tổ chức thành khoảng ba lớp, mỗi lớp xử lý một giai đoạn khác nhau của cuộc tấn công.

Ở lớp đầu tiên, mã được chèn vào proxy_server.py hoặc là litellm_init.pth hồ sơ giải mã và khởi động một bộ điều khiển ẩnThay vì sử dụng các hàm dễ bị gắn cờ như... exec()Đoạn mã này dựa vào các lệnh gọi tiến trình con và chức năng thư viện chuẩn để chạy dữ liệu đã giải mã và thu thập đầu ra của nó, giúp nó hòa nhập vào hoạt động bình thường của ứng dụng.

Sau khi khởi chạy, bộ điều phối này sẽ thu thập kết quả đầu ra của giai đoạn tiếp theo. mã hóa dữ liệu thu thập được bằng AES-256-CBC và sau đó mã hóa chính khóa phiên AES bằng cách sử dụng khóa công khai RSA được mã hóa sẵn trong mã. Dữ liệu và khóa đã mã hóa được đóng gói vào một tệp lưu trữ có tên tpcp.tar.gzTương tự như các hoạt động khác của TeamPCP, và đã chuẩn bị sẵn sàng cho việc rút lui.

Lớp thứ hai chịu trách nhiệm về hoạt động do thám hệ thống và thu thập thông tin đăng nhập một cách quyết liệt.Nó liệt kê tên máy chủ, thông tin người dùng và mạng, cũng như các biến môi trường, sau đó quét một danh sách dài các đường dẫn và tệp cấu hình để tìm kiếm các thông tin nhạy cảm. Các mục tiêu bao gồm:

• Khóa SSH và tệp cấu hình (máy khách và máy chủ)
• Thông tin xác thực đám mây dành cho AWS, GCP và Azure, bao gồm cả các mã thông báo được tạo từ siêu dữ liệu.
• Tệp kubeconfig của Kubernetes, mã thông báo tài khoản dịch vụ và bí mật cụm
• Tệp môi trường như là .env các biến thể thường được sử dụng để lưu trữ khóa API
• Cấu hình CI/CD, bí mật và mã truy cập
• Terraform, Helm và các thành phần IaC hoặc triển khai khác.
• Chuỗi kết nối cơ sở dữ liệu và các tệp cấu hình
• Khóa riêng TLS/SSL và vật liệu xác thực
• Ví tiền điện tử và dữ liệu liên quan

Trong một số môi trường, kẻ trộm không chỉ dừng lại ở việc thu thập. Nó còn cố gắng... chủ động sử dụng thông tin xác thực đã được tìm thấyVí dụ, bằng cách truy vấn API của nhà cung cấp dịch vụ đám mây, lấy thông tin bí mật của Kubernetes hoặc khám phá các tài nguyên có thể truy cập được, làm tăng khả năng di chuyển ngang và xâm nhập tiếp theo.

Lớp thứ ba cung cấp sự kiên trì và điều khiển từ xaNó ghi một kịch bản Python vào ổ đĩa (thường được thấy dưới dạng...). sysmon.py) và đăng ký nó như một dịch vụ chạy dài hạn, thường được ngụy trang thành một thứ gì đó vô hại như "Dịch vụ đo lường hệ thống". Dịch vụ này định kỳ liên hệ với cơ sở hạ tầng của kẻ tấn công, thường là cứ 50 phút một lần, để lấy thêm lệnh hoặc tải trọng.

Các nhà nghiên cứu ghi nhận một số hành vi kỳ lạ ở đây: khi một số nhà cung cấp bảo mật cố gắng lấy dữ liệu từ điểm cuối điều khiển và kiểm soát, máy chủ đã phản hồi bằng một liên kết đến phiên bản được làm lại của bài hát “Bad Apple!!”, rõ ràng là như một lời cảnh báo. chiến thuật đánh lạc hướng chống lại phân tích tự độngTuy nhiên, trên các hệ thống bị nhiễm, cơ chế tương tự có thể âm thầm cung cấp các chức năng mới theo thời gian.

Các kênh rò rỉ dữ liệu và cơ sở hạ tầng của kẻ tấn công

Trong các sự cố liên quan đến LiteLLM, các nhà phân tích đã quan sát thấy sự liên lạc với ít nhất hai miền chính do kẻ tấn công kiểm soát: modelslitellmcloud và checkmarxzoneChúng phù hợp với cơ sở hạ tầng được sử dụng trong các hoạt động trước đây của TeamPCP và đảm nhiệm các vai trò riêng biệt.

Kho lưu trữ được mã hóa tpcp.tar.gz thường là đã được tải lên models.litellmcloud, cho phép người vận hành thu hồi thông tin đăng nhập bị đánh cắp từ hàng ngàn môi trường hạ nguồn. Trong một số biến thể, các đường dẫn con khác nhau của checkmarxzone (ví dụ, checkmarxzone/raw or .../vsx) được sử dụng để cung cấp các tập lệnh duy trì hoặc các giai đoạn bổ sung.

Trên các hệ thống bị xâm nhập, các chuyên gia bảo mật đã báo cáo một loạt các sự cố lặp đi lặp lại. các chỉ số thỏa hiệp (IoC) có liên quan đến phần mềm độc hại LiteLLM:

• Sự hiện diện của kho lưu trữ tpcp.tar.gz trong thư mục tạm thời hoặc thư mục làm việc
• Các tệp tạm thời như /tmp/pglog và /tmp/.pg_state
• Các đường dẫn cấu hình và tập lệnh Python liên quan đến sysmon.py và một tệp dịch vụ tương ứng (thường nằm trong thư mục cấu hình người dùng hoặc systemd)
• Bất ngờ litellm_init.pth các tệp trong thư mục site-packages của Python cho phiên bản 1.82.8
• Lưu lượng truy cập đi ra hoặc tra cứu DNS trỏ đến modelslitellmcloud or checkmarxzone

Mã độc hại được truy vết đến các tập tin bao gồm... proxy_server.py (LiteLLM 1.82.7 và 1.82.8) và litellm_init.pth (1.82.8). Các nhà cung cấp bảo mật đã lập danh mục các hàm băm và các IoC khác và đang tiếp tục cập nhật các khuyến cáo của họ khi các chi tiết pháp y bổ sung xuất hiện.

Tác động đến môi trường AI, điện toán đám mây và CI/CD

Vì LiteLLM được sử dụng rộng rãi trong Các ứng dụng và dịch vụ dựa trên trí tuệ nhân tạoPhạm vi ảnh hưởng thực tế của sự thỏa hiệp này vượt ra ngoài phạm vi người dùng gói phần mềm đơn giản. Các môi trường đám mây nơi LiteLLM đóng vai trò là cổng kết nối với các nhà cung cấp LLM có khả năng chứa các bí mật được đặt cùng vị trí trong cùng không gian chạy hoặc cấu hình.

Wiz và các nhà quan sát khác ước tính rằng LiteLLM xuất hiện vào khoảng... một phần ba môi trường mây được quan sátĐiều này nhấn mạnh tầm ảnh hưởng tiềm tàng. Một số nguồn tin được BleepingComputer trích dẫn cho rằng số vụ rò rỉ dữ liệu có thể lên tới hàng trăm nghìn, mặc dù vẫn đang chờ xác nhận độc lập về con số chính xác.

Đáng chú ý, phần mềm độc hại nhấn mạnh vào... Hành vi nhận biết KubernetesTrong nhiều phân tích, phần mềm độc hại này cố gắng triển khai các pod có đặc quyền trên tất cả các node trong một cụm, sau đó sử dụng các pod đó để truy cập vào các thông tin bí mật và đối tượng cấu hình. Trong các hoạt động riêng biệt nhưng có liên quan của TeamPCP, các nhà nghiên cứu đã phát hiện các cụm Kubernetes bị nhắm mục tiêu bằng các kịch bản xóa sạch các node khi môi trường dường như được đặt tại Iran, đồng thời cài đặt các cửa hậu (chẳng hạn như cái gọi là CanisterWorm) ở những nơi khác.

Việc tập trung vào các công cụ CI/CD cũng rất rõ ràng. Bằng cách xâm nhập vào Trivy GitHub Actions, các tiện ích mở rộng Checkmarx VS Code và GitHub Actions, và giờ là LiteLLM, kẻ tấn công có được các điểm xâm nhập nơi mà... Tự động hóa đã có những đặc quyền rộng lớn. trên các kho lưu trữ, các thành phần xây dựng và thông tin xác thực triển khai. Cách tiếp cận này biến các công cụ vốn dĩ hướng đến bảo mật thành những bước đệm cho các cuộc tấn công quy mô lớn hơn.

Các quan chức FBI và các nhà nghiên cứu trong ngành đã cảnh báo rằng với số lượng lớn thông tin đăng nhập bị đánh cắp đang nằm trong tayDo đó, hoàn toàn có thể dự đoán sẽ có thêm nhiều thông báo vi phạm, các vụ xâm nhập thứ cấp và các nỗ lực tống tiền trong những tuần và tháng sau khi LiteLLM được tiết lộ lần đầu.

Các bước phát hiện, ngăn chặn và khắc phục

Dành cho các tổ chức có thể đã triển khai hoặc sử dụng các phiên bản LiteLLM. 1.82.7 hoặc 1.82.8 Theo PyPI, hướng dẫn từ các nhà cung cấp bảo mật và người duy trì PyPI rất thẳng thắn: Coi các hệ thống bị ảnh hưởng như thể chúng bị tổn hại.Việc gỡ cài đặt gói phần mềm không loại bỏ các cơ chế duy trì kết nối hoặc khôi phục lại bất kỳ hành vi đánh cắp thông tin đăng nhập nào có thể đã xảy ra.

Các hành động cần thực hiện ngay lập tức được khuyến nghị bao gồm:

• Xác định bất kỳ công trình lắp đặt nào của LiteLLM 1.82.7 hoặc 1.82.8 trên các máy của nhà phát triển, trình chạy CI/CD, container và môi trường sản xuất.
• Gỡ bỏ các phiên bản độc hại và cố định LiteLLM ở một phiên bản đã được kiểm chứng là hoạt động tốt (phiên bản 1.82.6 được nhiều người cho là phiên bản sạch cuối cùng tại thời điểm báo cáo).
• Xoay vòng tất cả thông tin xác thực Có thể truy cập từ các môi trường bị ảnh hưởng: khóa SSH, khóa và mã thông báo của nhà cung cấp dịch vụ đám mây, bí mật Kubernetes, bí mật CI/CD, thông tin đăng nhập cơ sở dữ liệu, khóa TLS và bất kỳ ví điện tử hoặc bí mật liên quan đến thanh toán nào.
• Tìm kiếm các dấu tích tồn tại, Chẳng hạn như sysmon.py, các định nghĩa dịch vụ systemd đáng ngờ và các tệp bất thường trong thư mục ~/.config hoặc các thư mục tạm thời như /tmp/pglog và /tmp/.pg_state.
• Kiểm tra các cụm Kubernetes đối với các pod có đặc quyền bất ngờ, đặc biệt là trong các namespace như kube-systemvà đối với các tài khoản dịch vụ hoặc ràng buộc vai trò bất thường.
• Giám sát các kết nối đi ra và các truy vấn DNS cho các tên miền tấn công đã biết như models.litellmcloud và checkmarxzone.

Trong những môi trường mà phần mềm độc hại có thể đã hoạt động trong một khoảng thời gian đáng kể, nhiều chuyên gia cho rằng... Xây dựng lại hoàn toàn từ một nền tảng đáng tin cậy. Đây có thể là phương án an toàn nhất, đặc biệt đối với cơ sở hạ tầng quan trọng. Do bản chất của phần mềm độc hại, không thể loại trừ khả năng bị can thiệp tinh vi hoặc cài đặt thêm các phần mềm độc hại khác chỉ bằng cách gỡ bỏ gói LiteLLM.

Các tổ chức cũng đang được khuyến khích áp dụng các biện pháp mạnh mẽ hơn. quản lý sự phụ thuộc và phòng thủ chuỗi cung ứngBao gồm việc ghim vào các phiên bản cụ thể đã được xác minh, kích hoạt các công cụ chặn hoặc gắn cờ các gói độc hại đã biết trong quá trình tiếp nhận, và tích hợp phân tích hành vi tự động có thể phát hiện hoạt động mạng hoặc hệ thống tệp bất thường trong quá trình xây dựng và kiểm thử.

Vụ kiện LiteLLM nói lên điều gì về chuỗi cung ứng phần mềm AI?

Sự cố LiteLLM làm nổi bật một xu hướng rộng hơn đã và đang diễn ra trong vài năm qua: Các thành phần có đòn bẩy cao trong trí tuệ nhân tạo và hệ sinh thái đám mây đang trở thành mục tiêu hàng đầu. Đối với các kẻ tấn công chuỗi cung ứng, thay vì nhắm trực tiếp vào các ứng dụng của người dùng cuối, các tác nhân đe dọa ngày càng tìm kiếm các điểm trong chuỗi công cụ mà việc xâm nhập vào một thư viện hoặc plugin duy nhất có thể dẫn đến quyền truy cập vào nhiều tổ chức ở khâu tiếp theo.

Các gói phần mềm như LiteLLM thực chất nằm ở vị trí trung gian. điểm nghẽn cho các bí mậtChúng đóng vai trò trung gian trong các cuộc gọi đến các nhà cung cấp AI, tương tác với các hệ thống CI/CD và tự động hóa cơ sở hạ tầng, và thường hoạt động với quyền hạn cao. Khi ngày càng nhiều doanh nghiệp gấp rút tích hợp khả năng LLM bằng các công cụ mã nguồn mở, giá trị của các thành phần này – và động cơ để tạo cửa hậu cho chúng – ngày càng tăng.

Đồng thời, vụ tấn công này cho thấy những thách thức trong việc bảo vệ các quy trình xây dựng và xuất bản. Trong trường hợp này, những kẻ tấn công được cho là đã lợi dụng lỗi cấu hình quy trình làm việc của Trivy để đánh cắp mã thông báo, sau đó sử dụng mã thông báo đó để đẩy các gói bị nhiễm độc lên PyPI, trong khi vẫn giữ cho cây mã nguồn công khai dường như sạch sẽ. Các thẻ phiên bản và các bước xây dựng đã trở thành một phần của bề mặt tấn công., tận dụng thực tế là nhiều quy trình dựa vào thẻ (tag) thay vì các commit được ghim (pinned commit) và có thể ngầm tin tưởng vào các artifact đến từ những người bảo trì quen thuộc.

Các nhà cung cấp như Sonatype, Wiz và Endor Labs nhấn mạnh tầm quan trọng của các biện pháp bảo vệ tự động, thời gian thực Hệ thống này có thể phát hiện các hành vi bất thường – chẳng hạn như các đích đến mạng chưa từng thấy trước đây hoặc việc rò rỉ dữ liệu được mã hóa – ngay cả khi siêu dữ liệu gói và lịch sử kho lưu trữ trông có vẻ hợp lệ. Tường lửa kho lưu trữ, trình quét dựa trên thông tin tình báo về mối đe dọa và phân tích ngữ cảnh của các phụ thuộc ngày càng được coi là các lớp cần thiết, chứ không phải là các tính năng tùy chọn.

Đối với cả người bảo trì và các tổ chức, sự thỏa hiệp của LiteLLM là một lời nhắc nhở rằng xử lý bí mật, tăng cường bảo mật CI/CD và xoay vòng thông tin xác thực Đây là nền tảng cho an ninh chuỗi cung ứng. Việc xoay vòng thông tin xác thực không đầy đủ hoặc không đồng bộ trong các sự cố trước đó đã tạo ra những lỗ hổng mà TeamPCP có thể tái sử dụng nhiều tuần sau đó, cho thấy một sai sót nhỏ trong quá trình xử lý sự cố có thể gây ra hậu quả lan rộng khắp hệ sinh thái.

Chiến dịch đưa LiteLLM lên tầm cao mới bắt đầu từ một vấn đề tưởng chừng như đơn giản về quy trình làm việc, và kể từ đó đã lan rộng sang GitHub Actions, Docker Hub, sự cố npm Shai-Hulud, OpenVSX và PyPI. Với các cửa hậu ẩn náu trong các công cụ được tin cậy rộng rãi và các trình kết nối AI, cùng với thông tin đăng nhập bị đánh cắp chảy vào cơ sở hạ tầng của kẻ tấn công, vụ việc này nhấn mạnh mức độ nhanh chóng mà chuỗi cung ứng phần mềm có thể trở thành một bề mặt tấn công hấp dẫn và hiệu quả cao.