LiteLLM pada PyPI terjejas oleh TeamPCP: kaji lebih lanjut kempen perisian hasad pencurian kelayakan

Kemaskini terakhir: 03/25/2026
Pengarang C SourceTrail
  • Pakej LiteLLM PyPI telah di-backdoor dalam versi 1.82.7 dan 1.82.8 dengan muatan pencurian kelayakan berbilang peringkat yang dipautkan kepada TeamPCP.
  • Perisian hasad tersebut telah menuai rahsia merentasi awan, CI/CD, Kubernetes dan sistem setempat, lalu mengalirkan data yang disulitkan ke domain yang dikawal oleh penyerang.
  • Penyerang berkemungkinan telah beralih melalui pelanggaran rantaian bekalan Trivy, menyalahgunakan token PyPI yang dicuri semasa proses bina dan terbitan roda.
  • Pembela digesa untuk menganggap persekitaran yang terjejas sebagai terjejas, memutar semua kelayakan, mencari artifak kegigihan dan menyematkan LiteLLM ke versi yang selamat.

Insiden perisian hasad LiteLLM pada PyPI

Selama beberapa jam pada 24 Mac 2026, pakej Python yang sangat popular secara senyap-senyap bertukar menjadi pencuri kelayakan yang kuat. Dua keluaran LiteLLM yang diracun, sebuah perpustakaan yang digunakan secara meluas sebagai antara muka bersepadu kepada model bahasa besar (LLM), telah dimuat naik ke PyPI, mendedahkan sejumlah besar sistem kepada serangan rantaian bekalan yang canggih buat seketika.

Versi berniat jahat, 1.82.7 dan 1.82.8, menggabungkan muatan berbilang peringkat yang mampu menyedut rahsia daripada mesin pembangun, pelari CI/CD, infrastruktur awan dan kluster Kubernetes, kemudian mengeluarkannya ke pelayan yang dikawal oleh penyerang. Kempen ini telah terikat dengan kumpulan ancaman TeamPCP, yang telah berbulan-bulan melancarkan Trivy, Checkmarx tooling, Docker images, serangan terhadap rantaian bekalan npm dan kini ekosistem PyPI.

Apakah LiteLLM dan mengapa ia menjadi sasaran utama?

Risiko rantaian bekalan pakej LiteLLM

LiteLLM ialah sebuah pustaka Python sumber terbuka dan pelayan proksi yang bertindak sebagai sejenis penyesuai universal untuk API LLM. Ia membolehkan aplikasi berkomunikasi dengan lebih seratus model berbeza – daripada penyedia seperti OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI dan lain-lain – melalui API gaya OpenAI tunggal.

Disebabkan peranan itu, projek ini telah tertanam secara mendalam di seluruh ekosistem AI. Laporan daripada pelbagai vendor keselamatan menunjukkan bahawa LiteLLM melihat secara kasar 3-3.4 juta muat turun setiap hari, dengan beberapa telemetri menunjukkan ia terdapat dalam kira-kira 36% persekitaran awan yang dipantauBagi penyerang, menjejaskan pakej dengan jejak itu mewakili peluang yang jarang berlaku untuk memanfaatkan aliran data dan kelayakan sensitif yang besar dengan satu langkah.

Secara reka bentuknya, LiteLLM sering terletak betul-betul di antara aplikasi dan pelbagai penyedia perkhidmatan AIKedudukan itu bermakna ia secara rutin mengendalikan kunci API, pembolehubah persekitaran, fail konfigurasi dan rahsia lain yang diperlukan untuk mencapai titik akhir LLM luaran. Pintu belakang dalam kebergantungan sedemikian boleh memintas dan mengeluarkan nilai tersebut secara senyap-senyap tanpa memerlukan pelanggaran langsung platform huluan itu sendiri.

Insiden itu juga menggariskan betapa rumitnya pembangunan moden: stesen kerja tempatan, saluran paip CI/CD, kluster Kubernetes dan akaun awan semuanya diikat bersama melalui rahsia dan automasi yang dikongsi. Satu kebergantungan yang terjejas dalam graf itu boleh mendedahkan kelayakan merentasi banyak lapisan susunan organisasi, menguatkan impak yang jauh melangkaui satu hos.

Bagaimana versi LiteLLM yang berniat jahat diperkenalkan

Versi LiteLLM yang di-backdoor pada PyPI

Pembebasan yang beracun LiteLLM 1.82.7 dan 1.82.8 telah dihantar ke PyPI pada pagi 24 Mac 2026, sekitar 08:30UTCMereka kekal tersedia selama hampir dua jam sebelum dikuarantin oleh pasukan keselamatan PyPI dan disekat oleh pertahanan pihak ketiga, dengan penyingkiran dilaporkan sekitar 11:25UTC.

Apa yang menjadikan kes ini penting ialah pintu belakang tidak muncul dalam sumber GitHub yang sepadanEndor Labs dan penyelidik lain mendapati bahawa logik berniat jahat telah disuntik ke dalam roda terbina yang diedarkan pada PyPI, bukan ke dalam repositori awam, menunjukkan bahawa kompromi berlaku semasa atau selepas proses bina/terbitkan dan bukannya melalui komit kod yang boleh dilihat.

Secara khususnya, penganalisis memerhatikan bahawa fail tersebut litellm/proxy/proxy_server.py mengandungi muatan yang dikodkan base64 terbenam yang tiada dalam fail yang sama dalam komit GitHubKira-kira sedozen baris telah disisipkan di antara blok kod yang sah (contohnya, berhampiran definisi REALTIME_REQUEST_SCOPE_TEMPLATE dan juga showwarning Baris tambahan tersebut menyahkod dan melaksanakan skrip tersembunyi secara senyap setiap kali modul diimport.

Dalam versi 1.82.8, penyerang melangkah lebih jauh dengan menjatuhkan .pth fail bernama litellm_init.pth ke dalam persekitaran Python. Kerana Python memproses semua .pth fail semasa permulaan penterjemah, ini memastikan muatan akan berjalan pada setiap pemanggilan Python, walaupun LiteLLM itu sendiri tidak pernah diimport oleh aplikasi tersebut.

Peningkatan ini menjadikan 1.82.8 jauh lebih berbahaya: sebarang skrip Python, pelari ujian, alat binaan atau automasi yang dilancarkan dalam persekitaran dengan pakej yang dikompromi dipasang akan mencetuskan logik pencurian kelayakan secara senyap-senyap di latar belakang.

Sambungan ke kempen TeamPCP yang lebih luas

Kempen rantaian bekalan TeamPCP

Kompromi LiteLLM tidak berlaku secara berasingan. Siasatan oleh Sonatype, Wiz, Endor Labs dan lain-lain mengaitkannya dengan kempen rantaian bekalan berterusan yang dijalankan oleh TeamPCP, sebuah kumpulan yang mendapat perhatian pada akhir tahun 2025 dan sejak itu telah menyasarkan beberapa projek sumber terbuka dan ekosistem pembangun.

Terdahulu pada bulan Mac, pelakon yang sama dikaitkan dengan penyahkodan Trivi Aqua Security pengimbas kerentanan dan Tindakan GitHub yang berkaitan, serta varian alat Checkmarx yang berniat jahat, termasuk KICS, Tindakan GitHub dan sambungan OpenVSX. Kempen ini juga telah menyentuh pakej npm, imej Docker Hub dan persekitaran Kubernetes, kerap menggunakan semula infrastruktur, skema penyulitan dan artifak kegigihan.

Mengesan kembali insiden LiteLLM, penyelenggara mendedahkan bahawa a Token penerbitan PyPI disimpan sebagai pembolehubah persekitaran dalam repositori GitHub LiteLLM telah diasingkan melalui aliran kerja Trivy yang terjejas. Token tersebut kemudiannya disalahgunakan untuk terbitkan keluaran PyPI yang tercemar, membolehkan penyerang memintas perlindungan dua faktor pada akaun pengguna dan menyuntik roda berniat jahat tanpa mengubah kod sumber awam.

Penyelidik juga menunjukkan komitmen dan aliran kerja yang mencurigakan yang dicipta sekitar 23 Mac dalam repositori berkaitan LiteLLM, termasuk cabang jangka pendek dan aliran kerja GitHub Actions yang membawa kunci awam RSA biasa yang dilihat merentasi muatan TeamPCP yang lain. Telemetri daripada aliran kerja menunjukkan bahawa rahsia yang tersedia untuk pelari CI tersebut mungkin telah diakses dan diekstrak.

Merentasi insiden, kumpulan itu telah menunjukkan corak yang konsisten: mencuri kelayakan dalam satu persekitaran, kemudian beralih ke ekosistem seterusnyaDalam kes ini, salah konfigurasi dalam Tindakan GitHub Trivy membenarkan kecurian token istimewa; token tersebut membawa kepada keluaran Trivy yang berniat jahat dan imej Docker; yang seterusnya, membolehkan pencerobohan perkakasan Checkmarx dan akhirnya pakej LiteLLM PyPI.

Cara perisian hasad LiteLLM beroperasi

Analisis daripada pelbagai vendor menggambarkan pintu belakang LiteLLM sebagai muatan Python berbilang peringkat, base64-dikaburkan direka bentuk untuk menjadi tersembunyi, fleksibel dan berdaya tahan. Logiknya disusun dalam kira-kira tiga lapisan, setiap satu mengendalikan fasa serangan yang berbeza.

Dalam lapisan pertama, kod yang disuntik dalam proxy_server.py atau litellm_init.pth fail menyahkod dan melancarkan orkestrator tersembunyiDaripada menggunakan fungsi yang mudah ditandai seperti exec(), skrip bergantung pada panggilan subproses dan fungsi pustaka standard untuk menjalankan muatan yang dinyahkod dan menangkap outputnya, membantu ia digabungkan ke dalam tingkah laku aplikasi biasa.

Sebaik sahaja berjalan, orkestrator ini mengumpul output daripada peringkat seterusnya, menyulitkan data yang dituai dengan AES‑256‑CBC dan kemudian menyulitkan kunci sesi AES itu sendiri menggunakan kunci awam RSA berkod keras yang dimasukkan ke dalam kod. Gumpalan dan kunci yang disulitkan digabungkan ke dalam arkib bernama tpcp.tar.gz, mengulangi operasi TeamPCP yang lain dan bersedia untuk pengekstrakan penapisan.

Lapisan kedua bertanggungjawab untuk peninjauan sistem yang agresif dan penuaian kelayakanIa menyenaraikan nama hos, maklumat pengguna dan rangkaian serta pembolehubah persekitaran, kemudian mengimbas senarai panjang laluan dan fail konfigurasi untuk bahan sensitif. Sasaran termasuk:

  • Kekunci SSH dan fail konfigurasi (klien dan pelayan)
  • Kelayakan awan untuk AWS, GCP dan Azure, termasuk token yang diperoleh daripada metadata
  • Fail konfigurasi kubernetes, token akaun perkhidmatan dan rahsia kluster
  • Fail persekitaran seperti .env varian yang sering digunakan untuk menyimpan kunci API
  • Konfigurasi CI/CD, rahsia dan token akses
  • Terraform, Helm dan artifak IaC atau penggunaan lain
  • Rentetan sambungan pangkalan data dan fail konfigurasi
  • Kunci peribadi TLS/SSL dan bahan pengesahan
  • Dompet cryptocurrency dan data berkaitan

Dalam sesetengah persekitaran, pencuri tidak berhenti pada pengumpulan. Ia cuba untuk menggunakan kelayakan yang ditemui secara aktif, contohnya dengan menanyakan API penyedia awan, mendapatkan rahsia Kubernetes atau meneroka sumber yang boleh dicapai, meningkatkan peluang pergerakan lateral dan kompromi susulan.

Lapisan ketiga menyediakan kegigihan dan kawalan jauhIa menulis skrip Python ke cakera (biasanya diperhatikan sebagai sysmon.py) dan mendaftarkannya sebagai perkhidmatan yang telah lama beroperasi, selalunya menyamar sebagai sesuatu yang tidak berbahaya seperti "Perkhidmatan Telemetri Sistem". Perkhidmatan ini secara berkala menghubungi infrastruktur penyerang, biasanya setiap 50 minit, untuk mendapatkan arahan atau muatan tambahan.

Para penyelidik menyatakan beberapa tingkah laku aneh di sini: apabila vendor keselamatan tertentu cuba mendapatkan muatan daripada titik akhir arahan dan kawalan, pelayan tersebut bertindak balas dengan pautan ke versi remaster lagu “Bad Apple!!”, nampaknya sebagai taktik pengalihan terhadap analisis automatikWalau bagaimanapun, pada sistem yang dijangkiti, mekanisme yang sama secara senyap-senyap boleh memberikan fungsi baharu dari semasa ke semasa.

Saluran penyusupan dan infrastruktur penyerang

Merentasi insiden LiteLLM, penganalisis memerhatikan komunikasi dengan sekurang-kurangnya dua domain utama yang dikawal oleh penyerang: modellitellmcloud and checkmarxzoneIni sejajar dengan infrastruktur yang digunakan dalam aktiviti TeamPCP terdahulu dan memainkan peranan yang berbeza.

Arkib yang disulitkan tpcp.tar.gz biasanya dimuat naik ke models.litellmcloud, membolehkan pengendali mendapatkan semula kelayakan yang dicuri daripada beribu-ribu persekitaran hiliran. Dalam beberapa varian, sublaluan yang berbeza bagi checkmarxzone (sebagai contoh, checkmarxzone/raw or .../vsx) digunakan untuk menyampaikan skrip kegigihan atau peringkat tambahan.

Mengenai sistem yang terjejas, pihak pembela telah melaporkan satu set masalah berulang penunjuk kompromi (IoCs) berkaitan dengan perisian hasad LiteLLM:

  • Kehadiran arkib tpcp.tar.gz dalam direktori sementara atau direktori kerja
  • Fail sementara seperti /tmp/pglog and /tmp/.pg_state
  • Skrip Python dan laluan konfigurasi yang berkaitan dengan sysmon.py dan fail perkhidmatan yang sepadan (selalunya di bawah direktori konfigurasi pengguna atau systemd)
  • Unexpected litellm_init.pth fail dalam pakej tapak Python untuk versi 1.82.8
  • Trafik keluar atau carian DNS yang menghala ke modellitellmcloud or checkmarxzone

Logik berniat jahat dikesan pada fail termasuk proxy_server.py (LiteLLM 1.82.7 dan 1.82.8) dan litellm_init.pth (1.82.8). Vendor keselamatan telah mengkatalogkan hash dan IoC selanjutnya dan terus mengemas kini nasihat mereka apabila butiran forensik tambahan muncul.

Kesan terhadap persekitaran AI, awan dan CI/CD

Kerana LiteLLM banyak digunakan dalam Aplikasi dan perkhidmatan berpacu AI, jejari letupan praktikal bagi kompromi ini melangkaui pengguna pakej mudah. ​​Persekitaran awan di mana LiteLLM berfungsi sebagai pintu masuk kepada penyedia LLM berkemungkinan mempunyai rahsia yang terletak bersama dalam ruang masa jalan atau konfigurasi yang sama.

Wiz dan pemerhati lain menganggarkan bahawa LiteLLM muncul sekitar satu pertiga daripada persekitaran awan yang diperhatikan, menggariskan potensi jangkauan. Beberapa sumber yang dipetik oleh BleepingComputer telah mencadangkan bahawa bilangan peristiwa pengekstrakan data mungkin mencecah ratusan ribu, walaupun pengesahan bebas tentang kiraan tepat masih belum selesai.

Terutamanya, perisian hasad itu menekankan Tingkah laku yang peka terhadap KubernetesDalam banyak analisis, muatan cuba menggunakan pod istimewa merentasi semua nod dalam kluster, kemudian menggunakan pod tersebut untuk mengakses rahsia dan objek konfigurasi. Dalam operasi TeamPCP yang berasingan tetapi berkaitan, penyelidik telah melihat kluster Kubernetes disasarkan dengan skrip yang memadamkan nod apabila persekitaran kelihatan terletak di Iran, sambil memasang pintu belakang (seperti yang dipanggil CanisterWorm) di tempat lain.

Tumpuan pada perkakasan CI/CD juga jelas. Dengan menjejaskan Trivy GitHub Actions, sambungan Checkmarx VS Code dan GitHub Actions, dan kini LiteLLM, penyerang mendapat titik masuk di mana automasi sudah mempunyai keistimewaan yang luas melalui repositori, bina artifak dan kelayakan penggunaan. Pendekatan ini menjadikan alat yang berorientasikan keselamatan sebagai batu loncatan untuk kompromi yang lebih luas.

Pegawai FBI dan penyelidik industri telah memberi amaran bahawa dengan sejumlah besar bukti kelayakan yang dicuri di tangan, adalah munasabah untuk menjangkakan lebih banyak pemberitahuan pelanggaran, pencerobohan sekunder dan percubaan pemerasan dalam beberapa minggu dan bulan selepas pendedahan LiteLLM awal.

Langkah pengesanan, pembendungan dan pemulihan

Untuk organisasi yang mungkin telah menarik atau melaksanakan versi LiteLLM 1.82.7 atau 1.82.8 daripada PyPI, panduan daripada vendor keselamatan dan penyelenggara PyPI adalah terus terang: anggap sistem yang terjejas sebagai terjejasHanya menyahpasang pakej tidak akan mengalih keluar mekanisme persistensi atau membatalkan sebarang kecurian kelayakan yang mungkin telah berlaku.

Tindakan segera yang disyorkan termasuk:

  • Kenal pasti sebarang pemasangan LiteLLM 1.82.7 atau 1.82.8 merentasi mesin pembangun, pelari CI/CD, kontena dan persekitaran pengeluaran.
  • Alih keluar versi berniat jahat dan pin LiteLLM pada keluaran yang diketahui baik (dengan 1.82.6 disebut secara meluas sebagai versi bersih terakhir pada masa pelaporan).
  • Putar semua kelayakan boleh diakses daripada persekitaran yang terjejas: kunci SSH, kunci dan token penyedia awan, rahsia Kubernetes, rahsia CI/CD, kelayakan pangkalan data, kunci TLS dan sebarang dompet atau rahsia berkaitan pembayaran.
  • Cari artifak kegigihan, Seperti sysmon.py, definisi perkhidmatan sistemd yang mencurigakan dan fail luar biasa di bawah ~/.config atau direktori sementara seperti /tmp/pglog and /tmp/.pg_state.
  • Periksa kluster Kubernetes untuk pod istimewa yang tidak dijangka, terutamanya dalam ruang nama seperti kube-system, dan untuk akaun perkhidmatan atau pengikatan peranan yang luar biasa.
  • Pantau sambungan keluar dan pertanyaan DNS untuk domain penyerang yang diketahui seperti models.litellmcloud and checkmarxzone.

Dalam persekitaran di mana pintu belakang mungkin telah dilaksanakan untuk sebarang tempoh yang ketara, ramai pakar mencadangkan bahawa pembinaan semula sepenuhnya daripada garis dasar yang boleh dipercayai mungkin jalan paling selamat, terutamanya untuk infrastruktur kritikal. Memandangkan sifat perisian hasad, gangguan halus atau muatan tambahan tidak dapat diketepikan semata-mata dengan mengalih keluar pakej LiteLLM.

Organisasi juga digalakkan untuk menerima pakai langkah-langkah yang lebih mantap pengurusan kebergantungan dan pertahanan rantaian bekalan: menyematkan pada versi tertentu yang disahkan, mendayakan alat yang menyekat atau menandakan pakej berniat jahat yang diketahui pada masa pengingesan dan menggabungkan analisis tingkah laku automatik yang dapat mengesan aktiviti rangkaian atau sistem fail yang tidak dijangka semasa binaan dan ujian.

Apa yang dikatakan oleh kes LiteLLM tentang rantaian bekalan perisian AI

Insiden LiteLLM mengetengahkan trend yang lebih luas yang telah meningkat sejak beberapa tahun kebelakangan ini: Komponen leveraj tinggi dalam AI dan susunan awan menjadi sasaran utama untuk penyerang rantaian bekalan. Daripada mengejar aplikasi pengguna akhir secara langsung, pelaku ancaman semakin mencari titik dalam rantaian alat di mana pengkompromian satu perpustakaan atau pemalam menghasilkan akses kepada banyak organisasi hiliran.

Pakej seperti LiteLLM berkesan berada pada tahap titik tercekik untuk rahsiaMereka menjadi perantara panggilan kepada penyedia AI, menyentuh sistem automasi CI/CD dan infrastruktur, dan selalunya dijalankan dengan kebenaran yang lebih tinggi. Memandangkan lebih banyak perusahaan bergegas untuk mengintegrasikan keupayaan LLM menggunakan perkakasan sumber terbuka, nilai komponen sedemikian – dan insentif untuk melakukan backdoor – hanya akan meningkat.

Pada masa yang sama, serangan itu menggambarkan cabaran mempertahankan saluran paip binaan dan penerbitan. Dalam kes ini, penyerang didakwa memanfaatkan salah konfigurasi aliran kerja Trivy untuk mencuri token, kemudian menggunakan token tersebut untuk menolak pakej yang tercemar ke PyPI, semuanya sambil membiarkan pokok sumber awam kelihatan bersih. Tag versi dan langkah binaan menjadi sebahagian daripada permukaan serangan, mengeksploitasi fakta bahawa banyak saluran paip bergantung pada tag dan bukannya komit yang disematkan dan mungkin secara tersirat mempercayai artifak yang datang daripada penyelenggara yang biasa.

Vendor seperti Sonatype, Wiz dan Endor Labs menekankan kepentingan perlindungan automatik, masa nyata yang boleh mengesan tingkah laku anomali – seperti destinasi rangkaian yang tidak kelihatan sebelum ini atau penyusupan keluar yang disulitkan – walaupun metadata pakej dan sejarah repositori kelihatan sah. Tembok api repositori, pengimbas yang dipacu oleh risikan ancaman dan analisis kontekstual kebergantungan semakin dilihat sebagai lapisan yang diperlukan, bukan tambahan pilihan.

Bagi penyelenggara dan organisasi, kompromi LiteLLM merupakan peringatan bahawa pengendalian rahsia, pengerasan CI/CD dan penggiliran kelayakan adalah asas kepada keselamatan rantaian bekalan. Penggiliran kelayakan yang tidak lengkap atau bukan atom dalam insiden terdahulu meninggalkan peluang yang dapat digunakan semula oleh TeamPCP beberapa minggu kemudian, menunjukkan bagaimana satu kesilapan langkah dalam tindak balas insiden boleh merebak merentasi ekosistem.

Kempen yang melanda LiteLLM bermula dengan apa yang kelihatan seperti isu aliran kerja yang terhad dan sejak itu merangkumi GitHub Actions, Docker Hub, Insiden npm Shai-Hulud, OpenVSX dan PyPI. Dengan pintu belakang bersembunyi dalam alat dan penyambung AI yang dipercayai secara meluas, dan kelayakan yang dicuri mengalir ke infrastruktur penyerang, episod ini menggariskan betapa cepatnya rantaian bekalan perisian boleh menjadi permukaan serangan yang menarik dan sangat berkesan.

ataque Shai-Hulud a la cadena de suministro de npm
artikel berkaitan:
Shai-Hulud: el ataque que sacude la cadena de suministro de npm
Related posts: