Een configuratiebestand hoort niets uit te voeren
Een ontwikkelaar bij een Europese fabrikant haalt een model van een publieke hub, roept from_pretrained aan en gaat lunchen. De bibliotheek haalt de gewichten op, leest het JSON-bestand dat ze beschrijft en initialiseert. Niets in die volgorde lijkt op toestemming om de code van een onbekende uit te voeren, en de ontwikkelaar heeft trust_remote_code al op False gezet juist om dat te voorkomen.
Onderzoekers van Pluto Security toonden aan dat het dat wel was. Het lek wordt geregistreerd als CVE-2026-4372, heeft een CVSS-basisscore van 7,8 en valt onder CWE-502, deserialisatie van niet-vertrouwde gegevens. Het maakt van een routineuze modeldownload willekeurige uitvoering van Python op de machine die de download doet, en de handeling die de gebruiker daarvoor moet verrichten is niets meer dan de gedocumenteerde manier om een model te laden.
Hoe een metadataveld langs de flag wandelde
De flag bewaakt codebestanden. De aanval kwam binnen via metadata. De constructor van de configuratie bevatte een lus die elke sleutel en waarde uit de niet-vertrouwde JSON overnam en rechtstreeks op het configuratieobject schreef, zonder allowlist en zonder validatie. Tot de velden die een aanvaller daardoor kon zetten behoorde er een met de naam _attn_implementation_internal, een privé intern attribuut waarvan niemand verwachtte dat het vanuit een gedownload bestand bereikbaar zou zijn.
Wanneer dat veld een tekenreeks bevatte in de vorm van eigenaar en repository, behandelde de kernel-loader die als een package dat van de hub gehaald moest worden en importeerde het zonder enige veiligheidscontrole. Alle Python in het initialisatiebestand van die repository werd vervolgens uitgevoerd. Het toestemmingsmechanisme waarop ontwikkelaars vertrouwen werd nooit geraadpleegd, omdat het alleen gold voor eigen modelleringscode en dit was geen eigen modelleringscode. Dit was een instellingenbestand.
De patch kwam eerst. De waarschuwing duurde nog 81 dagen
De data vormen het verhaal. De kwetsbare code kwam op 29 augustus 2025 in de bibliotheek en zat daarna ongeveer een half jaar in elke release. Het lek werd op 23 februari 2026 gemeld via een bug bounty, een maintainer opende de fix op 2 maart en versie 5.3.0 sloot hem op 4 maart. Dat is een snelle en prijzenswaardige reactie, tien dagen van melding tot gepatchte release.
Daarna bleef het openbare dossier stil. CVE-2026-4372 werd pas op 24 mei 2026 gepubliceerd, 81 dagen nadat de fix al in een publieke release beschikbaar was. In dat gat werd de patch in de release notes omschreven als een beveiligingsprobleem in kernels, zonder CVE-nummer, zonder ernstclassificatie en zonder de vermelding dat hij remote code execution stopte. Elke organisatie waarvan het patchen wordt aangestuurd door CVE-feeds en adviezen van leveranciers, en dat zijn de meeste gereguleerde organisaties in Europa, kreeg geen enkel signaal om voorrang te geven aan een upgrade die al beschikbaar was.
Daarna werd de hub zelf via dezelfde soort deur binnengedrongen
Op 16 juli 2026 maakte Hugging Face een inbraak in een deel van zijn eigen productie-infrastructuur bekend. Een kwaadaardige dataset misbruikte twee paden voor code-uitvoering in de verwerking van datasets, een dataset-loader met externe code en een template-injectie in een datasetconfiguratie, om op een verwerkingsworker te draaien. Van daaruit escaleerde de indringer naar toegang tot de node, verzamelde inloggegevens voor cloud en cluster en bewoog in een weekend zijwaarts naar meerdere interne clusters. De forensische analyse bekeek ruim 17.000 vastgelegde handelingen.
Hugging Face verklaart geen aanwijzingen te hebben gevonden voor manipulatie van publieke modellen, datasets of Spaces, en heeft zijn softwaretoeleveringsketen als schoon geverifieerd. Beschouw het incident als bewijs van het escalatiepad en niet als reden om de hub te wantrouwen. Een bestand dat data beschrijft bereikte een worker, en die worker beschikte over inloggegevens. Dat is de vorm van het risico, en het is dezelfde vorm als bij het configuratielek hierboven.
Wat u moet regelen voordat u het volgende model binnenhaalt
Drie controles, in deze volgorde. Stel vast welke versie van transformers draait in uw trainingsimages, uw notebooks en uw buildagents, en werk alles onder 5.3.0 bij. Ga na of het kernels-package daarnaast geïnstalleerd is, want dat maakte het pad misbruikbaar. Kijk vervolgens welke inloggegevens staan op de machines die model- en datasetartefacten verwerken, want die machines gelden meestal als een doorgeefluik voor data en krijgen navenant brede rechten.
De meldplicht loopt hoe dan ook op haar eigen klok. Op grond van artikel 23 van NIS2 is een entiteit die onder de richtlijn valt haar nationale autoriteit binnen 24 uur na kennisname van een significant incident een vroege waarschuwing verschuldigd, binnen 72 uur een uitgebreidere melding en binnen een maand een eindrapport. In Nederland komt de overeenkomstige leidraad van NCSC-NL. Geen van die termijnen staat stil terwijl u uitzoekt welke versie van de bibliotheek u draaide.
Lees hierna: Een verzoek kon uw WordPress-site kapen | SharePoint patchen sluit de deur niet meer



