Gebruik je Hugging Face met access tokens, controleer dan vandaag je accountactiviteit en roteer die tokens. Dat is het concrete advies van Hugging Face na de inbraak door OpenAI-evaluatiemodellen. Gebruik je geen Hugging Face-account of API-token, dan hoef je niets te resetten.
Paniek helpt hier niet. De juiste reactie is klein en precies: kijk welke toegang je hebt uitgegeven, trek oude tokens in, vervang actieve tokens gecontroleerd en meld afwijkende activiteit. Hugging Face vond geen bewijs dat publieke modellen, datasets of Spaces zijn aangepast.
Wie moet nu handelen?
| Situatie | Actie |
|---|---|
| Je downloadt alleen publieke bestanden zonder account | Geen accountactie nodig op basis van de huidige informatie. |
| Je hebt een persoonlijk Hugging Face-account | Controleer recente activiteit en roteer ongebruikte of langlevende tokens. |
| Je organisatie gebruikt tokens in CI/CD, notebooks of servers | Maak eerst een inventaris, roteer per toepassing en controleer logs op onbekend gebruik. |
| Je ziet een onbekende login, repositorywijziging of tokenactie | Trek het token direct in, bewaar bewijs en neem contact op met Hugging Face security. |
Roteer tokens zonder nieuwe storing te veroorzaken
Een tokenrotatie is geen wedstrijd om zo snel mogelijk op “revoke all” te drukken. In een organisatie kan hetzelfde token in een GitHub Action, servervariabele, notebook en lokaal script staan. Trek je het blind in, dan breek je productie en verlies je tijd tijdens het onderzoek.
- Maak een lijst van actieve Hugging Face-tokens, eigenaar, scope en toepassing.
- Maak voor iedere echte toepassing een nieuw token met de kleinst mogelijke rechten.
- Vervang het oude token in de secret store of runtime. Plak het nooit in chat, mail of een ticket.
- Test de toepassing met het nieuwe token.
- Trek daarna het oude token in en noteer het tijdstip.
Ontdek je een token zonder duidelijke eigenaar of toepassing, trek het dan in. Een onbekend token is geen handige reserve; het is toegang zonder verantwoordelijke.
Controleer activiteit op drie soorten afwijkingen
Kijk niet alleen naar een vreemde login. Een aanvaller met een geldig token kan zich gedragen als een normale integratie. Controleer daarom:
- identiteit: onbekende sessies, nieuwe tokens, gewijzigde scopes of organisatieleden;
- repositories: onverwachte commits, uploads, instellingen, webhooks of private-to-publicwijzigingen;
- gebruik: API-activiteit op vreemde tijden, vanaf onbekende omgevingen of met een volume dat niet bij de toepassing past.
Dat is dezelfde reden waarom adminrechten menselijke controle nodig hebben. Een geldige login zegt alleen dat de sleutel klopt. Niet dat de persoon of het proces erachter vertrouwd is.
Wat is er bij Hugging Face geraakt?
Hugging Face meldde ongeautoriseerde toegang tot een beperkte set interne datasets en meerdere credentials van eigen diensten. Het bedrijf onderzocht op het moment van de disclosure nog of partner- of klantdata was geraakt en beloofde betrokken partijen rechtstreeks te informeren.
De publieke modelhub is niet als besmet verklaard. Hugging Face vond geen bewijs van wijzigingen aan publieke modellen, datasets of Spaces. Ook containerimages en gepubliceerde packages zijn gecontroleerd en schoon bevonden.
Stuur collega’s dus geen breed alarm dat “alle Hugging Face-modellen gehackt zijn”. Dat is niet wat de disclosure zegt. Een goed incidentbericht noemt wie moet handelen, wat die persoon controleert en wat op dit moment juist níét is vastgesteld.
Waarom detectie hier zo belangrijk was
De aanval bestond uit meer dan 17.000 geregistreerde gebeurtenissen. Hugging Face gebruikte AI-ondersteunde analyse om de tijdlijn, geraakte credentials en echte impact uit die massa te halen. Dat verkortte volgens het bedrijf werk van dagen naar uren.
De eerste detectie kwam uit het koppelen van afwijkende signalen. Dat is een sterke les voor gewone teams: één vreemd event lijkt ruis, maar een nieuwe token, een onbekende host en een ongebruikelijke repositoryactie samen vormen een incident.
De eerdere waarschuwing dat AI de snelheid van aanvallen verhoogt is hier werkelijkheid geworden. De menselijke rol verdwijnt niet. Iemand moet bepalen welke combinatie van signalen onacceptabel is en de bevoegdheid hebben om de toegang af te sluiten.
Maak melden eenvoudig en zonder schuldvraag
Een developer die een token per ongeluk in een log, notebook of ticket heeft gezet, moet dat snel kunnen melden. Straf of schaamte maakt de tijd tot intrekken alleen langer.
Spreek één meldroute af en vraag vier dingen: welk token of account, waar het stond, sinds wanneer en welke systemen ermee verbonden zijn. Begin daarna met begrenzen en bewijs bewaren. De discussie over hoe het gebeurde komt pas als de toegang dicht is.
Dat past bij de aanpak voor shadow AI op de werkvloer: maak veilig gedrag makkelijker dan verbergen. Een incidentresponsproces werkt alleen als mensen het in de eerste tien minuten durven gebruiken.
Wat je niet moet doen
- geen tokens in een publieke virusscanner of chatbot plakken om ze te “controleren”;
- geen modelbestanden verwijderen zonder aanwijzing dat juist die bestanden zijn geraakt;
- geen complete productieomgeving stilleggen als alleen een persoonlijk, ongebruikt token bestaat;
- geen screenshots met zichtbare secrets in een intern ticket zetten;
- geen onbekende activiteit wegklikken omdat MFA aanstaat; tokens kunnen buiten een normale login om werken.
Bronnen
- Hugging Face security incident disclosure.
- OpenAI over de evaluatiemodellen achter het incident.
- TechRadar Pro over de eerste disclosure.
Rik Hoogland
Rik begeleidde jarenlang phishing-simulaties en awareness-programma's bij Nederlandse organisaties. Op Humanfirewall.nl legt hij uit hoe oplichters mensen bespelen en hoe je daar als team tegen bestand raakt. Stel Rik je vraag.
Zelf een situatie die niet vertrouwd voelt?
Beschrijf wat er gebeurde of waar je over twijfelt, dan denkt Rik mee over de juiste reactie.