Unsloth Studio kjørte kode fra modellrepoet bare ved å lese config.json

Pillar Security beskrev 29. september en kritisk sårbarhet for vilkårlig kodekjøring i Unsloth Studio, nettgrensesnittet som følger med det populære finjusteringsbiblioteket unsloth. Å velge en modell i modellvelgeren fikk backend til å laste ned og kjøre Python-kode fra modellens repo. Studio lastet aldri vektene og kjørte ingen inferens, for det holdt å lese config.json. Versjon 2026.5.10 og eldre er rammet, og hullet er lukket i 2026.6.9, som kom på PyPI 22. juni. Ingen CVE er tildelt, fordi Unsloth valgte å ikke publisere advisoryen for en betafunksjon.

Feilen ligger i hvordan Studio sjekket modellens egenskaper. I Hugging Faces transformers kan config.json ha et auto_map-felt som peker til egne Python-filer i repoet, og med trust_remote_code=True blir de importert og kjørt. Funksjonen load_model_config i Studio hadde True som standardverdi, og kallet som sjekker om modellen har bildestøtte, overstyrte den aldri. Brukerens egen innstilling, som står på False, ble ikke konsultert. Sjekken kunne også trigges direkte over HTTP via endepunktene /api/models/config og /api/models/check-vision.

Koden kjører med dine rettigheter i Studio-prosessen, på en maskin som typisk har GPU-er, Hugging Face-tokens, SSH-nøkler og skynøkler. Passordet og at backend som standard bare lytter på 127.0.0.1, hjelper ikke, fordi det er du som innlogget bruker som velger modellen. Kjører du Studio med -H 0.0.0.0, i Colab eller med flere brukere, blir skadeomfanget større.

«Generelt mener vi at programvare aldri bør bli et kjøretøy for å kjøre upålitelig kode fra upålitelige kilder uten eksplisitt samtykke» — Ariel Fogel, Pillar Security

Unsloth var uenig i vurderingen. Ifølge Pillar viste vedlikeholderne til at Hugging Face skanner etter skadevare, og til at Studio er i beta. Pillar svarer at proof-of-concept-repoet ikke ble flagget, fordi koden er harmløs i hvile: den åpner kalkulatoren og skriver én linje til en fil. En ekte angriper kan la en slik auto_map-modul hente og kjøre neste steg først når den kjøres. Og selv om Studio kalles beta, fulgte koden med i en vanlig pip install unsloth.

Mønsteret er ikke nytt i år. Pillar viser til tre CVE-er fra 2026 i samme klasse: CVE-2026-46432 i LMDeploy, CVE-2026-4944 i vLLM, der hardkodet trust_remote_code=True overstyrte brukerens --trust-remote-code=False, og CVE-2026-6859 i InstructLab. Unsloth Studio kombinerte feilene fra LMDeploy og vLLM og flyttet utløseren fram til modellvalget, et steg brukeren aldri oppfatter som farlig.

Hva bør du gjøre?

1. Kjør pip install -U unsloth og sjekk at du har 2026.6.9 eller nyere. Siste versjon på PyPI er 2026.9.12, og Pillar anbefaler oppdatering også om du bare bruker kjernebiblioteket, siden den sårbare koden lå i samme pakke.
2. Søk gjennom egen kode og verktøyene rundt den etter trust_remote_code=True, og sørg for at det bare slås på når du selv ber om det for en bestemt modell.
3. Lås modellversjoner til en commit-hash, velg safetensors der du kan, og last modeller i en sandkasse på maskiner som har nøkler og tokens.