Defekti në Docker Hub lejoi tokens të vepronin si përdorues të tjerë
Një defekt në Docker Hub lejoi personal access tokens të vepronin si një përdorues tjetër në container registry, duke i dhënë mbajtësit të token mundësinë të bënte push, pull ose delete images brenda lejeve të account të prekur. Docker e rregulloi çështjen më 30 shtator dhe tha se nuk gjeti prova që vulnerability ishte shfrytëzuar.
Docker Hub është registry që përdoret për të publikuar dhe shkarkuar container images, të cilat janë përbërës software të paketuar që përdoren zakonisht nga ekipet e zhvillimit, ofruesit e hosting dhe cloud services. Docker tha se çështja ishte në procesin që konverton një personal account në një organization. Gjatë atij konvertimi, personal access tokens, shpesh të shkurtuar si PATs, u transferuan te account i emëruar si pronari i ri i organization. Një PAT është një sekret që përdoret në vend të një password kur software lidhet me registry, dhe Docker tha se personi që kishte krijuar fillimisht secilin token mund ta përdorte ende atë.
Problemi ishte i kufizuar te registry access. Docker tha se nuk jepte access te Docker Hub web interface dhe nuk mund të përdorej për të ndryshuar një account password, email address ose two-factor authentication settings. Ai gjithashtu nuk mund të përdorej për të marrë kontrollin e një account përmes atyre web settings. Ndikimi ishte gjithsesi serioz sepse një token i transferuar mund të funksiononte si pronari i emëruar në registry, në varësi të permission level të token.
Docker e ndjek vulnerability si CVE-2026-105445 dhe e vlerësoi si kritike. CVE record i publikuar më 13 tetor i cakton asaj një CVSS 4.0 score prej 9.4. Docker tha se defekti ekzistonte nga 26 gushti 2024 deri te rregullimi, një periudhë pak më shumë se dy vjet. Rregullimi u aplikua drejtpërdrejt në Docker Hub, kështu që përdoruesit nuk kanë nevojë të instalojnë një software update për të marrë korrigjimin në anën e platformës.
Mekanika ka rëndësi për çdo ekip që mbështetet te container images në build ose deployment pipelines. Docker Hub nuk e zhvendos një repository nga një account te një tjetër. Në vend të kësaj, një përdorues mund të konvertojë një personal account në një organization që mban të njëjtin emër, ndërsa emëron një account ekzistues si owner. Ndërsa defekti ishte i pranishëm, ai konvertim ndryshonte owner të regjistruar për secilin PAT, por e linte secret të pandryshuar. Në terma praktikë, një token i krijuar nga një person mund të pranohej nga registry sikur t’i përkiste owner të sapoemëruar.
Docker dhe researchers që raportuan defektin thanë se owner i emëruar nuk u pyet për të miratuar ndryshimin dhe nuk u njoftua. Conversion page e Docker kishte përfshirë formulim që të paktën nga gushti 2024 duke thënë se owner i ri merr një notification email. Researchers, nga mptrdev.com, e quajtën çështjen GhostPat dhe thanë në technical write-up të tyre se e riprodhuan dy herë duke përdorur test accounts me pëlqim. Ata thanë se arritën të log in në registry si target account, të krijonin dhe të bënin push në një repository në atë namespace, të bënin push në një organization ku bënte pjesë target, dhe të bënin pull private repositories.
Veprimet e mundshme vareshin nga permissions të token të transferuar. Brenda atyre kufijve, ai mund të bënte pull images, push images ose delete images në repositories të zotëruara nga named user dhe në organizations ku ai user kishte access. Docker tha se e konsideroi defektin kritik sepse access mund të përfshinte publikimin e images nën një emër legjitim. Ky risk është domethënës për ekipet e website dhe infrastructure sepse container images shpesh ushqejnë automated deployment systems, dhe një trusted repository name mund të ketë peshë operacionale.
Docker gjithashtu vuri në dukje incidente të veçanta në mars dhe prill, ku sulmuesit përdorën stolen publisher credentials për të bërë push malicious Trivy images dhe malicious KICS images në Docker Hub repositories të vetë publishers. Ato incidente nuk përshkruhen si shfrytëzim i kësaj vulnerability, por tregojnë pse registry credentials dhe trusted image names janë security assets të ndjeshme.
Docker tha se rishikoi çdo account conversion të bërë gjatë periudhës së prekur dhe i krahasoi konvertimet me registry logs dhe token records. Kompania kërkoi tokens të përdorur nën më shumë se një identity dhe ekzaminoi çdo push të bërë me një token të transferuar, rreth 304,000 pushes gjithsej. Docker tha se nuk gjeti prova që vulnerability ishte shfrytëzuar.
Sipas Docker, çdo push i rishikuar shkoi te një repository që i përkiste ose organization të konvertuar, ose owner të emëruar të tij. Në shumicën e rasteve, Docker tha se të dy accounts dukeshin se i përkisnin të njëjtit person ose ekip. Aty ku Docker nuk mund të konfirmonte se një person kontrollonte të dy accounts, ai analizoi public images me risk më të lartë pa i ekzekutuar ato dhe tha se nuk gjeti malware ose tampering.
Ka një kufi të rëndësishëm në atë rishikim. Docker tha se registry logs tregojnë kur një token përdoret, jo thjesht që ai ekziston. Një token i transferuar që nuk është përdorur kurrë nuk do të shfaqej në ato logs. Për këtë arsye, Docker e trajtoi çdo token të transferuar nga një conversion gjatë periudhës së prekur si potencialisht të prekur, pavarësisht nëse ishte përdorur apo jo. Advisory i Docker raporton gjetjet e tij për pushes, por nuk thotë çfarë gjeti kompania për pulls ose deletions të bëra me transferred tokens, përfshirë pulls nga private repositories.
Më 2 tetor, Docker u dërgoi email përdoruesve accounts e të cilëve kishin marrë transferred tokens dhe veçmas u dërgoi email owners të organizations të përfshira. Email-et listonin tokens përkatës sipas description dhe creation date. Docker nuk deklaroi sa përdorues ose tokens u përfshinë, duke e përshkruar grupin e prekur vetëm si një numër të kufizuar përdoruesish. Docker tha se kushdo që nuk e mori email-in nuk ishte i ekspozuar dhe nuk ka asgjë për të bërë.
Docker çaktivizoi transferred tokens që kishte identifikuar më 8 tetor. Tokens që owners kishin kërkuar t’i mbanin nuk u çaktivizuan. Një publisher i Docker Compose linter compose-lint shkroi se mori dy email-e më 2 tetor, një si organization owner dhe një për user account e tij. Ai tha se rotated dy continuous integration tokens dhe kontrolloi signatures në 42 published images, duke gjurmuar secilin image te build run që e krijoi.
Docker këshillon përdoruesit të rishikojnë personal access tokens të tyre, të revoke çdo token që nuk e njohin ose nuk e përdorin më, dhe të përdorin organization access tokens për automation që i përket një organization në vend të PAT të një personi. Në Docker Hub, përdoruesit mund të hapin Account settings dhe pastaj Personal access tokens për të parë kur u krijua secili token dhe kur u përdor për herë të fundit. Researchers sugjeruan gjithashtu të vëzhgohet për një token që user nuk e krijoi, pavarësisht description të tij, dhe për një organization të panjohur që shfaqet në account switcher.
Organization access tokens kërkojnë një Docker Team ose Docker Business subscription. Docker thotë se ato menaxhohen nga një organization owner, një company owner ose një custom role me atë permission, dhe se ato nuk funksionojnë me Docker Desktop ose Image Access Management.