In de AI-wereld is downloaden vaak genoeg om te starten, maar bij Hugging Face’s Diffusers blijkt die routine niet automatisch veilig. Onderzoekers van Zafran Labs hebben drie high-severity fouten (samen FaceHugger genoemd) openbaar gemaakt die kunnen leiden tot arbitrary code execution zodra een machine een (geconstrueerde) modelrepository laadt. Daarmee wordt de AI supply chain opvallend kwetsbaar: niet alleen data, maar ook code uit repositories kan ongezien in uw proces belanden.
Wat dit extra zorgwekkend maakt, is dat de beveiligingsmaatregel trust_remote_code in bepaalde scenario’s kan worden omzeild. In plaats van onbetrouwbare code tegen te houden, kunnen aanvallen misbruik maken van hoe de loader controleert en vervolgens onderdelen ophaalt.
Waarom Diffusers kwetsbaar is in AI-pipelines
Diffusers is een Python-bibliotheek waarmee ontwikkelaars diffusiemodellen kunnen gebruiken om beelden, video’s en audio te genereren. De kern van het probleem zit in de manier waarop Diffusers modellen lokaal kan laden vanuit een repository op de Hugging Face hub via de DiffusionPipeline-API.
Daarbij gebruikt de bibliotheek configuratiebestanden om specifieke pipeline- en componentklassen te initialiseren. En precies daar kan het misgaan: artefacten die doorgaans worden gezien als ‘passieve data’, blijken in de praktijk ook executabele codepaden te kunnen triggeren.
Omdat Hugging Face populair is in enterprise-omgevingen (denk aan productie-pipelines, CI/CD en containerimages), kan een kwetsbaarheidsketen snel opschalen. Als uw processen repositories als bron vertrouwen, kan een kwaadwillende partij de download- en laadstappen gebruiken als startpunt.
FaceHugger: drie manieren om trust_remote_code omzeilen
De onderzoekers beschrijven dat de varianten dezelfde onderliggende oorzaak delen: de controle rondom trust_remote_code bevindt zich slechts in de eerste fase. Als de loader in een later stadium ‘ziet’ dat er custom code bij hoort—maar die niet is meegewogen door de gate—dan kan de bescherming alsnog worden gepasseerd.
De aanvalspatronen zijn terug te voeren op Time-of-Check to Time-of-Use (TOCTOU). In plaats van één ‘atomische’ operatie blijkt het downloadproces in twee opeenvolgende HTTP-aanroepen te gebeuren. Hierdoor kan de inhoud tussen die momenten wijzigen of op een manier worden aangeboden waardoor de gate niet de juiste code beoordeelt.
CVE-2026-44827 (CVSS 8.8)
Deze fout draait om code-injection. Een aanvaller kan bij het laden via het custom_pipeline-pad een modelrepository zó voorbereiden dat arbitrary code wordt geladen, terwijl trust_remote_code=False (of het default gedrag) lijkt te worden gerespecteerd.
In de beschrijving wordt daarbij verwezen naar een specifiek geconstrueerd pipeline-naamscenario met de naam “None.py”, wat kan helpen om de flow te sturen naar het executiepunt.
CVE-2026-45804 (CVSS 7.5)
Hier gaat het om een race condition. De essentie is dat een aanvaller de repository kan beïnvloeden door configuratie te wijzigen tussen twee downloadaanroepen: hf_hub_download en snapshot_download. Daardoor kan er alsnog code in de repository terechtkomen die leidt tot uitvoering tijdens het laadproces.
CVE-2026-44513 (CVSS 8.8)
Deze variant lijkt sterk op CVE-2026-44827: opnieuw is er sprake van code-injection via het custom_pipeline-pad vanuit een hub repository, zó dat arbitrary code kan worden geladen ondanks een expliciete trust_remote_code=False (of het weglaten ervan).
De onderzoekers plaatsen deze drie CVE’s samen onder de paraplu FaceHugger omdat ze dezelfde route volgen: de beveiligingscheck dekt niet alle situaties waarin de loader uiteindelijk executiepaden activeert.
Impact: van model laden naar “initial access”
Het is verleidelijk om een AI-modelrepository te zien als een pakket met ‘alleen bestanden’. Maar de analyse benadrukt het bredere risico: configuratiebestanden, loaders en custom pipeline-code kunnen samen onopgemerkt doorschuiven naar uitvoerbare code. Wat begint als een normale modeldownload kan veranderen in een initial-access vector.
Dat is precies waarom AI-supply chain security zo’n thema is: uw pipeline vertrouwt op externe bronnen, vaak zonder dat die bronnen door dezelfde strenge governance gaan als traditionele applicatiecode.
Als u dit patroon eerder herkende bij andere softwarecomponenten, dan sluit dit ook aan bij eerdere aandacht voor supply chain-achtige routes en “wat te doen” bij hacks en patches. Zie bijvoorbeeld wat de implicaties zijn van hacks en patches.
Fix en mitigaties: wat u nu kunt doen
De kwetsbaarheden zijn na responsible disclosure verholpen in Diffusers versie 0.38.0, uitgebracht in het vroege voorjaar van 2026. Gebruikers die DiffusionPipeline.from_pretrained aanroepen met custom pipelines, worden als impacted beschreven.
Als u nog niet direct kunt patchen, geven de maintainers en onderzoekers gerichte workarounds. Die zijn vooral gericht op het terugdringen van de kans dat een loader onbetrouwbare codepaden tegenkomt.
Workaround 1: gebruik alleen geaudit bronmateriaal
Roep from_pretrained alleen aan met pretrained_model_name_or_path en custom_pipeline vanuit volledig vertrouwde bronnen, waarvan de inhoud aantoonbaar is beoordeeld. Gebruik daarnaast local snapshot-dirs die u zelf beheert, in plaats van repositories die u onvoldoende kent.
Workaround 2: voorkom mismatch tussen modelbron en custom pipeline
Een extra risico ontstaat wanneer custom_pipeline= wijst naar een andere hub repository dan de pretrained_model_name_or_path die u als basis laadt. De aanbeveling is om die situatie niet te gebruiken voordat u zeker weet dat de combinatie veilig is.
Workaround 3: inspecteer snapshots op onverwachte Python-bestanden
Voor lokale snapshots geldt: inspecteer de snapshot vooraf op onverwachte *.py-bestanden. Let daarbij extra op bestanden in submappen zoals unet/ en scheduler/, maar ook op de root van de snapshot.
Dat sluit aan bij het bredere verdedigingsprincipe dat u geen “code” moet verwachten zonder die ook daadwerkelijk te controleren. Voor organisaties die hun software supply chain langs hetzelfde denkraam willen leggen, kan het nuttig zijn om ook te kijken naar hoe men patchen en risicoreductie praktisch aanpakt, zoals beschreven in investeringsmanagement voor cybersecurity.
Praktische checklist voor teams die Diffusers gebruiken
Om de kans op trust_remote_code omzeilen te verkleinen, kunt u uw werkwijze rond AI-lading langs deze punten nalopen:
- Werk Diffusers bij naar 0.38.0 of hoger en controleer of uw runtimes die versie daadwerkelijk gebruiken.
- Beperk custom pipelines tot code uit bronnen die u kunt verifiëren en auditen.
- Voorkom repository-mismatch tussen de pretrained bron en de custom pipeline repository waar mogelijk.
- Inspecteer snapshots op onverwachte Python-bestanden vóórdat uw pipeline ze laadbaar maakt.
- Behandel modelrepos als onbetrouwbaar, vergelijkbaar met externe dependencies: niet “data-only”, maar mogelijk executie-aanleiding.
Door dit te combineren met standaard CI/CD- en containerhardeningsmaatregelen, verkleint u de kans dat een incidentele repository-actie direct vertaalt naar code-uitvoering op uw systemen.
Wat dit zegt over AI-supply chain security
FaceHugger laat zien dat de bedreiging niet in één losse bug zit, maar in de manier waarop AI-frameworks vertrouwen op externe artefacten. Het is een signaal dat beveiligingsgrenzen zoals trust_remote_code niet alleen functioneel moeten zijn, maar ook correct moeten dekken hoe loaders en downloadflows in de praktijk verlopen.
Voor organisaties die Hugging Face en vergelijkbare platforms gebruiken: beschouw het laden van modellen als een onderdeel van uw softwareleveringsketen. Dan hoort daar ook dezelfde discipline bij als bij het beheren van patches, het controleren van dependencies en het beperken van permissies.
Conclusie: als u Diffusers inzet, is het tijd om te controleren of u op 0.38.0 (of later) zit en uw gebruik van custom pipelines kritisch tegen het licht te houden. Zo voorkomt u dat een ogenschijnlijk normale modeldownload alsnog kan eindigen met arbitrary code execution via een route die trust_remote_code omzeilen mogelijk maakt.
Bron: https://thehackernews.com/2026/08/hugging-face-diffusers-flaws-could-let.html
