Docker avslørte 13. oktober 2026 en kritisk sårbarhet i Docker Hub som gjorde det mulig for en angriper å opptre som en annen bruker inne i registeret, med fulle rettigheter til å hente, laste opp og slette container-images. Sårbarheten, sporet som CVE-2026-105445, ble rettet internt allerede 30. september, men det er først nå selskapet har gått offentlig ut med detaljene. Ifølge Docker er det ingen tegn til at feilen ble utnyttet før den ble lukket, men saken treffer midt i en periode der container-forsyningskjeden er under hardt press fra flere kanter samtidig.
For norske og nordiske utviklingsmiljøer, som i stor grad bygger skyapplikasjoner på images hentet rett fra Docker Hub, er dette en påminnelse om hvor skjør tilliten til offentlige container-registre egentlig er. Et register som daglig håndterer milliarder av nedlastinger er i praksis selve ryggraden i hvordan container-baserte applikasjoner distribueres til Kubernetes-klynger, serverless-plattformer og CI/CD-pipeliner over hele verden. Når en identitetsfeil i selve registeret lar en bruker late som en annen, handler det ikke lenger bare om datalekkasje – det handler om hvem som egentlig signerer og leverer koden du kjører i produksjon.
Hva CVE-2026-105445 faktisk gjorde mulig
Kjernen i feilen lå i hvordan Docker Hub håndterte personlige tilgangstokener (PAT). I en normal flyt skal et PAT være bundet til én bruker og gi tilgang innenfor akkurat de rettighetene brukeren selv har. I Docker Hub sitt tilfelle kunne et token, under visse betingelser, bli “omtildelt” slik at det i praksis opptrådte som en helt annen konto på registernivå. Det betyr at angriperen ikke bare fikk innsyn – vedkommende fikk de samme handlingsrettighetene som offeret.
Docker selv beskriver konsekvensen presist i sitt sikkerhetsvarsel: “Within the scope of the token, a re-assigned PAT acted as the target user at the registry level, meaning an attacker could potentially pull, push, and/or delete images in the target’s repositories and in organizations where the target had access.” (Docker, offisielt sikkerhetsvarsel). Det er en kort setning med store implikasjoner: en angriper kunne i teorien slette produksjonsimages, erstatte dem med egne versjoner, eller trekke ut private images fra organisasjoner offeret hadde tilgang til.
Docker har selv forklart hvorfor alvorlighetsgraden ble satt så høyt. Siden feilen åpnet for at images kunne publiseres under et legitimt brukernavn, ble den behandlet som en risiko for hele forsyningskjeden, ikke bare som et vanlig tilgangsproblem (ifølge BleepingComputer, som siterte Dockers uttalelse om saken). Det er nettopp denne koblingen til forsyningskjeden – muligheten til at ondsinnet kode kan se ut som den kommer fra en pålitelig, kjent avsender – som gjør denne typen sårbarheter langt farligere enn en ordinær datalekkasje.
Tidslinjen: fra oppdagelse til offentliggjøring
Det gikk om lag to uker fra Docker rettet feilen internt til saken ble gjort offentlig kjent, en praksis som er vanlig i bransjen for å unngå å publisere detaljer før en patch faktisk er rullet ut og verifisert. Tabellen under oppsummerer de bekreftede datoene i saken.
| Dato | Hendelse |
|---|---|
| Ikke offentliggjort | Sårbarheten i PAT-håndteringen oppdages og rapporteres til Docker |
| 30. september 2026 | Docker ruller ut fiks for CVE-2026-105445 i produksjon |
| 13.–14. oktober 2026 | Docker publiserer sikkerhetsvarsel, saken dekkes av sikkerhetsmedier |
| 13. oktober 2026 | Docker bekrefter at de ikke har funnet bevis for utnyttelse av feilen |
At selskapet ikke har funnet spor av aktiv utnyttelse betyr ikke at risikoen var lav mens vinduet sto åpent. Det betyr at Dockers egne logger, så langt de har blitt gjennomgått, ikke viser mistenkelig aktivitet knyttet til omtildelte PAT-er. For organisasjoner som har publisert images til offentlige eller private repositories på Docker Hub i perioden før 30. september, er det likevel fornuftig å behandle saken som en påminnelse om å gå gjennom tilgangslogger selv, ikke bare stole blindt på leverandørens egen vurdering.
Hvorfor dette er mer enn “nok en CVE”
Container-registre skiller seg fra andre typer sky-infrastruktur ved at de er et tillitsknutepunkt. Når en Kubernetes-klynge eller en serverless-funksjon drar ned et image med tag latest eller en bestemt versjon, stoler hele kjeden – fra bygg-server til produksjonsmiljø – på at det som kommer tilbake faktisk er det som ble publisert av den angitte eieren. En sårbarhet som lar en angriper opptre som en annen bruker på registernivå, bryter nettopp denne antagelsen. Det er samme kategori risiko som gjorde angrep som SolarWinds og senere forsyningskjede-hendelser i åpen kildekode-økosystemet så alvorlige: det er ikke koden i seg selv som er svak, det er tilliten til hvor koden kommer fra som svikter.
Saken kommer dessuten i en periode der container- og sky-sikkerhet allerede er under press fra flere retninger samtidig. Samme uke ble det rapportert om forsinkelser og feilrater i Google Cloud Storage i regionen us-central1, der opplastinger og skriveoperasjoner fikk forhøyet ventetid og feilrate over en periode på rundt tolv og en halv time 8. oktober, forårsaket av en trafikkoptimalisering som skulle avlaste lokal kapasitetsmangel (ifølge Coloprice sin hendelsesoversikt). Det er ikke direkte koblet til Docker Hub-saken, men det illustrerer et mønster: kjernekomponentene i den globale sky-infrastrukturen – registre, lagring, identitetstjenester – får stadig tettere sammenvevde feilpunkter, og når ett ledd svikter, forplanter konsekvensene seg raskt nedover i leveransekjeden til tusenvis av selskaper.
Markedseffekt: hva skjer med tilliten til offentlige registre
Docker Hub er fortsatt det klart mest brukte offentlige container-registeret i verden, og brukes som standard base-image-kilde i de aller fleste Kubernetes-oppsett, CI/CD-pipeliner og lokale utviklermiljøer. Den posisjonen gjør enhver sikkerhetshendelse i registeret til noe langt mer enn en isolert feil hos én leverandør – det er en potensiell svakhet i forsyningskjeden til svært mange selskaper samtidig. Markedseffekten av denne typen hendelser er sjelden et umiddelbart kundetap, men den akselererer en trend som allerede er i gang: flere virksomheter setter opp private, speilede registre (såkalte “pull-through cache”-oppsett) i stedet for å la produksjonssystemer hente direkte fra offentlige kilder.
Dette gir også medvind til konkurrerende registre og skanningsverktøy som markedsfører seg på nettopp forsyningskjede-sikkerhet. Verktøy som Trivy, Grype og Snyk, som alle skanner container-images for sårbarheter før de når produksjon, har de siste årene fått økt oppmerksomhet nettopp fordi de fanger opp avvik mellom forventet og faktisk image-innhold. En hendelse som CVE-2026-105445 styrker argumentet for at image-skanning og signaturverifisering (for eksempel med Sigstore/Cosign) bør være obligatorisk i pipelinen, ikke en frivillig ekstra sjekk lenger ned i prosessen.
Sammenligning: container-registre og hvordan de håndterer tilgang
Ingen av de store alternative registrene har rapportert en tilsvarende sårbarhet i samme periode, men det er verdt å se på hvordan de ulike plattformene strukturerer tilgangsmodellene sine, siden det sier noe om hvor eksponert de er for lignende identitetsfeil.
| Register | Tilgangsmodell | Standard synlighet | Signaturstøtte |
|---|---|---|---|
| Docker Hub | Personlige tilgangstokener (PAT) + organisasjonsroller | Offentlig som standard for gratiskontoer | Støtter Docker Content Trust / Cosign |
| Amazon ECR | IAM-roller og -policyer integrert med AWS-kontoen | Privat som standard | Støtter Cosign via OCI-signaturer |
| Google Artifact Registry | IAM-roller integrert med GCP-prosjekt | Privat som standard | Støtter Binary Authorization og Cosign |
| Azure Container Registry | Azure AD / Entra ID-roller og tokens | Privat som standard | Støtter signering via Notation/Cosign |
| GitHub Container Registry | Personlige tilgangstokener + GitHub Actions-tokens | Kan settes offentlig eller privat per repo | Støtter Cosign via Sigstore-integrasjon |
Det som skiller Docker Hub fra de skyleverandør-eide alternativene, er at tilgangsmodellen historisk har vært mer selvstendig bygget rundt egne tokens og kontoer, i stedet for å arve den samlede identitets- og tilgangsstyringen (IAM) til en større skyplattform. Det er verken bedre eller dårligere i utgangspunktet, men det betyr at en feil i selve token-logikken, som i dette tilfellet, blir et isolert enkeltpunkt av svikt. Hos AWS, Google og Microsoft er registertilgangen flettet inn i de samme IAM-systemene som styrer resten av skyressursene, noe som i teorien gjør en lignende identitetsfeil mer kostbar å introdusere, men også mer alvorlig om den først skjer, fordi den potensielt rammer langt mer enn bare container-images.
Historisk kontekst: container-registre har vært et gjentakende mål
Dette er ikke første gang et stort container-register havner i søkelyset for identitets- eller tilgangsproblemer. Gjennom 2026 har flere relaterte sårbarheter blitt avdekket i verktøy og komponenter som er tett knyttet til container-forsyningskjeden. Containerd, kjøretidskomponenten som ligger under både Amazon EKS og Google GKE, fikk tidligere i år en sårbarhet med CVSS-score på 8,8. Skanneverktøyet Trivy ble selv rammet av et forsyningskjede-angrep med CVSS 9,4 som påvirket rundt 2.500 selskaper. Og policyverktøyet Kyverno, som mange bruker nettopp for å håndheve regler om hvilke images som er tillatt å kjøre i en Kubernetes-klynge, fikk hele 22 separate CVE-er, hvorav seks ble klassifisert som kritiske.
Mønsteret som trer frem er tydelig: etter hvert som containerøkosystemet har modnet og blitt selve standarden for hvordan skyapplikasjoner bygges og distribueres, har det også blitt et stadig mer attraktivt mål for sikkerhetsforskere og angripere. Hver nye lagdeling i stacken – kjøretid, registre, policyverktøy, skannere – introduserer et nytt sted der tillit kan brytes. Det er denne akkumulerte kompleksiteten som gjør at én enkelt feil i et token-system hos Docker Hub ikke kan sees isolert, men må forstås som del av en bredere trend der container-infrastrukturen gradvis blir et like attraktivt angrepsflate som tradisjonelle nettverksgrenser en gang var.
Hva betyr dette for norske og nordiske utviklingsmiljøer
Norske virksomheter, fra fintech-selskaper til offentlig sektor, har de siste årene flyttet stadig mer av sine arbeidsbelastninger over i containeriserte miljøer, ofte driftet på Kubernetes hos AWS, Azure eller Google Cloud. Mange av disse teamene bruker Docker Hub som primær kilde for base-images, enten direkte eller gjennom en pull-through-cache. Det gjør at en hendelse som CVE-2026-105445 ikke bare er en internasjonal nyhet, men en direkte operasjonell risiko for norske utviklingsteam som må vurdere om noen av deres images kan ha vært eksponert i perioden før 30. september.
Samtidig forsterker saken en trend som allerede er i gang i Norden: flere selskaper beveger seg mot strengere forsyningskjede-kontroll, der hvert image som går i produksjon må være signert, skannet og verifisert mot en kjent kildekode-commit før det slipper gjennom. For virksomheter underlagt NIS2-regelverket, som trådte i kraft i Norge gjennom digitalsikkerhetsloven, er denne typen hendelser også relevante fra et rapporteringsperspektiv: en identitetsfeil i et sentralt tredjepartsverktøy kan utløse vurderingsplikt om hvorvidt egne systemer har vært berørt, selv når leverandøren selv ikke har funnet bevis for utnyttelse.
Slik beskytter du organisasjonen mot lignende identitetsfeil
Det finnes ingen måte å garantere seg fullstendig mot feil hos en ekstern registerleverandør, men det er flere konkrete grep som reduserer eksponeringen betydelig. For det første bør organisasjoner som bruker Docker Hub i produksjon, rotere alle personlige tilgangstokener som var aktive før 30. september 2026, selv om Docker selv ikke har funnet bevis for misbruk. For det andre bør bruken av latest-tagger i produksjonsmiljøer fases ut til fordel for faste, innholdsadresserte image-hasher (digest-basert referering), slik at et image aldri kan byttes ut uten at referansen i seg selv endres.
For det tredje bør teams som ikke allerede gjør det, innføre obligatorisk signaturverifisering med verktøy som Cosign eller Notation i CI/CD-pipelinen, slik at et image som ikke er signert av en kjent, verifisert kilde, aldri kan nå en produksjonsklynge. Og for det fjerde bør skanningsverktøy som Trivy, Grype eller Snyk kjøres som en obligatorisk sperre (gate) i pipelinen, ikke bare som en rapporterende tjeneste i etterkant. Kombinert gir disse grepene et vesentlig smalere angrepsvindu neste gang et register, uansett hvilket, skulle oppleve en lignende identitetsfeil.
# Eksempel: verifiser image-signatur med Cosign før deploy
cosign verify --key cosign.pub docker.io/dittfirma/dittimage@sha256:abcd1234...
# Eksempel: referer alltid til digest, ikke tag, i produksjon
image: docker.io/dittfirma/dittimage@sha256:abcd1234ef567890...
# Eksempel: kjør Trivy som sperre i CI/CD
trivy image --exit-code 1 --severity CRITICAL,HIGH docker.io/dittfirma/dittimage:latestReaksjoner fra sikkerhetsmiljøet
Docker selv har vært tydelige på hvorfor de valgte å klassifisere feilen som kritisk, til tross for at det ikke er funnet bevis for aktiv utnyttelse. Selskapets begrunnelse er direkte knyttet til at en angriper kunne publisere images under et legitimt brukernavn, noe som flytter risikoen fra ren datatilgang til spørsmålet om hvem som faktisk sto bak koden som endte opp i produksjon hos sluttbrukere (ifølge BleepingComputer sin dekning av Dockers uttalelse). Det er en vurdering som stemmer godt overens med hvordan resten av sikkerhetsbransjen har reagert på saken: det er ikke omfanget av datalekkasjen som bekymrer mest, men presedensen en slik identitetsfeil setter for tilliten til hele container-økosystemet.
Dockers egen tekniske forklaring i sikkerhetsvarselet er verdt å lese i sin helhet for team som har brukt PAT-baserte integrasjoner mot Docker Hub, siden den beskriver nøyaktig hvilke scenarioer som var sårbare og hvilke som ikke var det. Selskapet har også bekreftet at tiltaket som ble rullet ut 30. september, lukker hele angrepsflaten, ikke bare et spesifikt utnyttelsesmønster.
Fem spådommer for container-sikkerhet fremover
- Flere registre innfører obligatorisk signaturkrav. I løpet av 2027 vil det bli vanligere at store registre krever kryptografisk signerte images som standard for organisasjonskontoer, ikke bare som en valgfri funksjon.
- Digest-basert referering blir normen, ikke unntaket. Flere Kubernetes-verktøy og CI/CD-plattformer vil begynne å advare eller blokkere bruk av mutable tags som
latesti produksjonsmanifester. - Private speilregistre vokser raskere enn direkte bruk av offentlige registre. Flere mellomstore og store selskaper vil sette opp egne pull-through-cache-løsninger for å redusere avhengigheten av ett enkelt offentlig register.
- Identitetsrelaterte CVE-er i containerverktøy fortsetter å øke. Gitt mønsteret fra containerd, Trivy og Kyverno tidligere i 2026, er det sannsynlig at flere lignende token- eller rollebaserte feil avdekkes i angrensende verktøy det neste året.
- NIS2-relatert rapporteringspress øker på norske virksomheter. Hendelser i sentrale tredjepartsverktøy som Docker Hub vil i økende grad utløse interne vurderinger av rapporteringsplikt, selv når leverandøren selv konkluderer med at ingen utnyttelse har funnet sted.
Hva Docker-saken lærer oss om tillit i skyen
Den dypere lærdommen fra CVE-2026-105445 er ikke at Docker Hub plutselig er utrygt å bruke. Det er heller en påminnelse om at ethvert sentralisert tillitspunkt i skyinfrastrukturen, uansett hvor godt driftet det er, representerer et enkeltpunkt av risiko for alle som er avhengige av det. Jo mer kritisk infrastruktur som bygges på toppen av container-registre, jo større blir konsekvensene når noe går galt, selv i de tilfellene der feilen rettes raskt og uten påvist misbruk. For norske utviklingsteam er budskapet enkelt: behandle hvert eksternt avhengighet, også de du har brukt i årevis uten problemer, som en risiko som krever aktiv overvåking, ikke passiv tillit.
Saken kommer også på et tidspunkt der norske og nordiske virksomheter uansett er i ferd med å modernisere container- og Kubernetes-oppsettene sine, drevet av både regulatoriske krav og et økende fokus på forsyningskjede-sikkerhet etter flere år med stadig mer sofistikerte angrep mot åpen kildekode-økosystemet. Docker Hub-saken føyer seg inn i et mønster de fleste sikkerhetsansvarlige allerede kjenner igjen: risikoen flytter seg stadig lenger opp i stacken, fra nettverk og servere til identitet, tilgang og tillit mellom tjenester.
Ofte stilte spørsmål om Docker Hub-sårbarheten
Hva er CVE-2026-105445?
Det er en kritisk sårbarhet i Docker Hub som lot en angriper, via en feilhåndtering av personlige tilgangstokener (PAT), opptre som en annen bruker på registernivå og dermed hente, laste opp eller slette images i den brukerens repositories.
Er sårbarheten fortsatt aktiv?
Nei. Docker rettet feilen i produksjon 30. september 2026, om lag to uker før den ble offentlig kjent 13. oktober.
Ble feilen utnyttet av angripere?
Docker opplyser at de ikke har funnet bevis for at sårbarheten ble utnyttet før den ble lukket, men selskapet har ikke garantert at ingen angrep fant sted, kun at ingen spor er funnet i gjennomgåtte logger.
Hvem er berørt av sårbarheten?
Alle brukere og organisasjoner som har brukt personlige tilgangstokener mot Docker Hub før 30. september 2026 kan i teorien ha vært eksponert, særlig de med delte eller organisasjonsbaserte tilganger.
Hva bør jeg gjøre som utvikler eller DevOps-ansvarlig?
Roter alle Docker Hub-tokener som var aktive før patchen, gå gjennom tilgangslogger for uvanlig aktivitet, bytt til digest-basert referering av images, og innfør signaturverifisering med verktøy som Cosign i CI/CD-pipelinen.
Er andre registre som Amazon ECR eller Google Artifact Registry rammet?
Nei, det er ingen rapporterte tilsvarende sårbarheter hos AWS, Google eller Microsoft sine container-registre i samme periode. CVE-2026-105445 er isolert til Docker Hub sin egen PAT-implementasjon.
Hvordan skiller denne saken seg fra Cloudflare Containers-hendelsen tidligere i år?
Cloudflare-saken dreide seg om risiko for at restdata fra tidligere arbeidsbelastninger kunne eksponeres mellom ulike kunders containere på infrastrukturnivå, mens Docker Hub-saken handler om en identitets- og tilgangsfeil i selve registertjenesten, der problemet lå i hvem som fikk opptre som hvem, ikke i isolasjonen mellom kjørende containere.