Docker Hub heeft een kritieke kwetsbaarheid gepatcht die het mogelijk maakte dat één gebruiker containerafbeeldingen kon beheren met de rechten van een ander account. De fout draaide om het omzetten van een persoonlijk account naar een organisatie, waarbij persoonlijke toegangstokens (PAT’s) tijdens die transitie onbedoeld konden worden toegeschreven aan een andere eigenaar.
Docker meldt dat er geen aanwijzingen zijn gevonden dat de kwetsbaarheid actief is misbruikt. Toch is dit type misconfiguratie of account-mapping precies het soort issue dat in containeromgevingen tot grote gevolgen kan leiden, omdat tokens rechtstreeks rechten geven op de Docker Hub registry.
Wat was de Docker Hub tokenbug?
De kwetsbaarheid staat geregistreerd als CVE-2026-105445 en kreeg van Docker de beoordeling critical. De fout zat in de functie die een persoonlijk account omzet naar een organisatie.
Volgens Docker werden bij zo’n conversie de persoonlijke toegangstokens (PAT’s) van het oorspronkelijke persoonlijke account overgezet naar de gebruiker die als organisatie-eigenaar werd aangewezen. Het token zelf bleef daarbij hetzelfde, inclusief het geheime deel. Alleen de identiteit achter het token, oftewel wie er “eigenaar” werd voor de registry, kon hierdoor veranderen.
Belangrijk detail: de toegang was beperkt tot de registry. De kwetsbaarheid gaf geen mogelijkheid om in de webinterface instellingen aan te passen, zoals het wijzigen van wachtwoord, e-mailadres of twee-factor authenticatie. Ook betekende het niet dat een aanvaller een account volledig kon overnemen.
Waarom kon iemand hiermee pushen, pullen en verwijderen?
In Docker Hub functioneert een PAT als een soort “vervanging” voor een wachtwoord: wie het token heeft, kan acties uitvoeren op basis van het permissieniveau dat is gekozen bij het aanmaken van dat token.
Door de conversie naar een organisatie kon het token vervolgens werken alsof het behoorde tot een andere gebruiker. In de praktijk kon dat binnen de registry betekenen dat de aangewezen eigenaar-identity toegang kreeg om binnen diens repository’s te pushen, pullen en verwijderen. Docker benadrukt dat dit ook publiceren onder een legitieme naam kon omvatten.
Misbruikscenario volgens onderzoekers (GhostPat)
De onderzoekers die het probleem rapporteerden, beschreven een scenario waarbij een aanvaller:
- een PAT aanmaakt op een account dat hij of zij beheert;
- dat account converteert naar een organisatie;
- een andere gebruiker aanwijst als eigenaar van die organisatie.
Daarna zou het token in de registry kunnen functioneren met rechten die horen bij de gebruiker die als eigenaar is opgegeven. Volgens Docker en de onderzoekers kreeg die genoemde eigenaar daarvoor geen extra bevestiging en werd hij of zij niet automatisch op de hoogte gebracht via een melding.
Zo lang zat de bug open
Docker geeft aan dat de kwetsbaarheid open stond van 26 augustus 2024 tot het moment van de fix op 30 september. Dat is iets meer dan twee jaar.
Omdat Docker Hub zelf de patch heeft aangebracht, is er volgens Docker geen software-update die gebruikers moeten installeren. Je kunt dit zien als een “server-side” probleem: de wijziging zit in de manier waarop Docker Hub conversies en token-eigendom verwerkt.
Welke acties heeft Docker ondernomen na ontdekking?
Docker rapporteert dat het de impact heeft onderzocht door elke accountconversie te beoordelen die tijdens de periode dat de bug actief was. Daarbij werden registry-logs en tokengegevens met elkaar vergeleken.
Daarnaast onderzocht Docker pushes die gebeurden met overgedragen tokens: in totaal ging het om ongeveer 304.000 push-acties. Docker zegt daarbij geen bewijs te hebben gevonden dat de kwetsbaarheid is misbruikt.
Het bedrijf geeft wel aan dat er een uitdaging zit in de logging: Docker-registratielogs tonen wanneer een token is gebruikt, maar ze onthullen niet direct het bestaan of de geschiedenis van elk token. Als een overgedragen token nooit is gebruikt, kan dat dus buiten beeld blijven. Daarom behandelde Docker elk token dat tijdens een conversie was overgezet als mogelijk getroffen, ook als er geen gebruikslog zichtbaar was.
Wat is er bekend over mogelijke misbruikpogingen?
Hoewel Docker stelt dat er geen bewijs van exploitatie is gevonden, verwijst het wel naar eerdere observaties: in maart en april zouden aanvallers gestolen publisher-credentials hebben gebruikt om malafide Trivy-images en malafide KICS-images te pushen naar repositories van de eigen uitgevers.
Die context is relevant omdat het laat zien hoe snel het in de praktijk mis kan gaan zodra aanvallers legitieme publicatietokens of registry-toegang krijgen. Zelfs zonder bevestigde exploit van deze specifieke tokenbug blijft het advies om supply-chain risico’s actief te beperken.
Gerelateerd: als je kijkt naar aanvallen op container-ecosystemen, helpt het om ook breder te lezen over hoe kwaadwillenden vertrouwen misbruiken. Zie bijvoorbeeld ons artikel over GitHub dat Trusted Publishing verder aanscherpt: dat soort maatregelen gaat vaak over het verkleinen van de kansen dat gestolen credentials ongezien kunnen worden ingezet.
Wie werd geïnformeerd en wat kun je zelf checken?
Volgens Docker zijn op 2 oktober e-mails verstuurd naar gebruikers van wie tokens waren overgezet, en ook naar de eigenaren van de betrokken organisaties. Docker omschrijft de groep die benaderd werd als “beperkt” en noemt geen exact aantal.
Als je geen e-mail hebt ontvangen, stelt Docker dat je in principe niet blootgesteld bent en er niets te checken is.
Daarnaast deactiveerde Docker op 8 oktober de overgedragen tokens die het had geïdentificeerd. Tokens die de eigenaar vroeg om te behouden, werden niet gedeactiveerd.
Praktische checklist voor je PAT’s
Docker adviseert gebruikers om hun tokens te controleren en alles in te trekken wat ze niet herkennen of niet meer gebruiken. Concreet noemt Docker een werkwijze zoals:
- Ga naar Account settings en open Personal access tokens.
- Bekijk wanneer elk token is aangemaakt en wanneer het voor het laatst is gebruikt.
Docker beschrijft ook twee signalen om op te letten:
- Tokens die je niet zelf hebt gemaakt (let op de beschrijving, omdat die keuzevrij is bij het aanmaken van tokens).
- Een organisatie die je herinnert niet bewust te hebben toegevoegd of waarbij je plots als eigenaar voorkomt via de account-switcher.
Waarom organisatie-tokens beter passen bij automation
Een belangrijk onderdeel van Docker’s advies is dat je voor geautomatiseerde taken bij voorkeur gebruikmaakt van organization access tokens, en niet van PAT’s van één persoon. De reden is dat organisatie-tokens beter passen bij rollen en ownership binnen teams of organisaties.
Docker geeft aan dat organisatie-tokens doorgaans alleen werken als je een abonnement hebt (Docker Team of Docker Business). Ze worden beheerd door een organisatie-eigenaar of een rol met de juiste rechten.
Daarnaast noemt Docker dat organisatie-owners in bepaalde configuraties ook kunnen terugkijken in activity logs: daar zie je pushed tags en soms welke token een push heeft uitgevoerd. Docker Home bewaart logs 30 dagen; oudere entries zijn via de Docker Hub API beschikbaar.
Wil je die aanpak vertalen naar je bredere beveiligingsbeleid? Dan is het nuttig om te kijken naar identiteits- en tokenbesturing in automatisering. Ook in onze eerdere stukken over controle via identiteit zie je terug dat wie beheert en wie vertrouwt, vaak het verschil maakt tussen “incident” en “compromis”.
Wat betekent dit voor teams die containers publiceren?
De kern van de Docker Hub tokenbug is niet alleen de codefout zelf, maar ook het principe: in containerregistries zijn rechten gekoppeld aan tokens, en ownership-wijzigingen in accountstructuren kunnen onverwachte gevolgen hebben.
Voor teams betekent dit praktisch:
- Werk met een minimale set tokens en automatiseer waar mogelijk met rollen die passen bij organisaties.
- Controleer periodiek of tokens nog verklaren wat ze doen (wanneer zijn ze gebruikt, door welk systeem, voor welke repos?).
- Bewaar auditeerbaarheid: zorg dat je weet welke CI/CD-pipelines welke registry-acties uitvoeren.
Hoewel Docker zegt dat er geen bewijs is van exploitatie, toont deze zaak hoe belangrijk het is om accountconversies en het toekennen van eigenaren zorgvuldig te beheren. Zeker als meerdere systemen, CI-runners of externe partijen betrokken zijn.
Conclusie
De Docker Hub tokenbug (CVE-2026-105445) maakte het mogelijk dat bij het omzetten van een persoonlijk account naar een organisatie PAT’s konden “overgaan” naar een andere eigenaar. Daardoor kon een ander account (binnen registry-limieten) images pushen, pullen en verwijderen met rechten die bij die nieuwe identiteit hoorden.
Docker heeft de fout op 30 september gepatcht en stelt dat er geen bewijs van misbruik is gevonden. Toch is het verstandig om je eigen PAT’s te reviseren, tokens die je niet herkent in te trekken en automation waar mogelijk te verschuiven naar organisatie-tokens met duidelijk beheer.
Bron: https://thehackernews.com/2026/10/docker-fixes-critical-two-year-old-hub.html
