CVE-2026-53988: Kritisk autentificeringsfejl i Dockhand
Kritisk fejl i Dockhand før 1.0.40 lader angribere uden login udløse genudrulninger og potentielt overtage serveren. Opdatér til 1.0.40 nu.
Hvad er det?
CVE-2026-53988 er en autentificeringsfejl i Dockhand, et værktøj til at styre og genudrulle containerstakke via git-webhooks. Fejlen skyldes CWE-306, manglende autentificering af en kritisk funktion: når et webhook-hemmelighed ikke er sat, springer Dockhand tjekket af afsenderens identitet helt over. En angriber kan gætte sig frem til stak-id’er, som ofte er fortløbende tal, og sende uskrevne webhook-kald direkte til systemet. Det udløser en git clone og en docker compose-genstart af den pågældende stak, uden at angriberen behøver kende adgangskoder eller tokens. Kombineret med skriveadgang til den git-gren, som stakken følger, kan en angriber også placere en manipuleret docker-compose.yml med privilegerede bind-mounts, hvilket kan give fuld adgang til værtsmaskinen.
Hvem rammer det?
Sårbarheden rammer alle installationer af Dockhand med version lavere end 1.0.40, hvor webhook-endpoints for git er aktiveret. Det gælder typisk mindre it-afdelinger og udviklingsteams, der bruger Dockhand til at automatisere udrulning af containere i test- eller produktionsmiljøer. Er systemet tilgængeligt fra internettet, eller kan det nås fra et andet netværkssegment uden ekstra beskyttelse, er risikoen størst.
Hvad kan ske?
En angriber kan udløse gentagne, uautoriserede genudrulninger af jeres containerstakke, hvilket i praksis er et denial of service: driften afbrydes, mens systemet konstant genstartes. Har angriberen samtidig skriveadgang til den overvågede git-gren, for eksempel via et kompromitteret udviklerkonto eller en sårbar CI-pipeline, kan vedkommende injicere en docker-compose-fil, der monterer værtsmaskinens filsystem ind i containeren. Det åbner for udbrud fra containeren og fuld kontrol over serveren, herunder adgang til andre systemer på netværket.
Hvor alvorligt er det?
CVSS-scoren er 10 ud af 10, den højeste mulige. Angrebet kræver hverken login, adgangskode eller nogen handling fra en bruger, og det kan udføres over netværket med lav teknisk kompleksitet. Konsekvensen rammer alle tre områder fuldt ud: fortrolighed, integritet og tilgængelighed. Der er ikke oplyst aktiv udnyttelse i naturen på offentliggørelsesdatoen, men den lave angrebskompleksitet og manglen på krav om autentificering gør, at et angreb kan automatiseres og udføres i stor skala.
Hvad gør jeg nu?
Opdatering lukker hullet. Følg punkterne i rækkefølge:
- Opdatér Dockhand til version 1.0.40 eller nyere på alle installationer.
- Sæt en webhook-hemmelighed på alle stakke, hvis I midlertidigt ikke kan opdatere, så det uautentificerede tilfælde undgås.
- Begræns adgang til Dockhand’s webhook-endpoints til kendte IP-adresser, for eksempel jeres git-udbyders serveradresser, via firewall eller reverse proxy.
- Gennemgå logs for uventede genudrulninger eller usædvanlige webhook-kald i perioden før opdateringen.
- Kontrollér, at ingen docker-compose.yml-filer i jeres git-grene indeholder uventede privilegerede bind-mounts.
- Kontakt en sikkerhedsrådgiver, hvis I finder tegn på misbrug, eller hvis I er usikre på, om jeres opsætning er sårbar.
Opdatér inden for 24 timer
Vi anbefaler, at I opdaterer Dockhand til 1.0.40 med det samme, da sårbarheden er kritisk og kræver hverken login eller brugerhandling. Kan opdateringen ikke ske straks, bør I som minimum sætte en webhook-hemmelighed og lukke adgangen til webhook-endpoints udefra. Det er ikke forsvarligt at vente til en planlagt vedligeholdelsesrunde, da angrebet er simpelt at automatisere.
Tidslinje
Konkrete eksempler
Genudrulningsangreb mod en dansk it-afdeling
Et mindre dansk IT-firma bruger Dockhand til at automatisere udrulning af interne testmiljøer og har ved en fejl gjort webhook-endpointet tilgængeligt fra internettet. En angriber gætter sig frem til stak-id’erne og sender gentagne uskrevne webhook-kald, som tvinger systemet til konstant at genklone og genstarte containerne. Testmiljøet bliver utilgængeligt i flere timer, og udviklerteamet kan ikke arbejde, før firewallreglerne strammes og systemet opdateres.
Ofte stillede spørgsmål
Hvordan ved vi, om vi bruger en sårbar version af Dockhand?
Tjek versionsnummeret i jeres Dockhand-installation. Er det lavere end 1.0.40, er systemet sårbart. Kontakt leverandøren eller den ansvarlige udvikler, hvis I er i tvivl om, hvordan I finder versionen.
Kan vi vente med opdateringen til weekenden?
Vi fraråder det. Sårbarheden kræver ingen adgangskode og kan udnyttes automatisk over internettet, så vinduet for et angreb er åbent hele tiden, indtil I opdaterer eller lukker adgangen til webhook-endpoints.
Er vi ramt, hvis Dockhand kun kører internt på vores netværk?
Risikoen er lavere, men ikke væk. Kan en medarbejder, en kompromitteret enhed eller en anden sårbarhed give adgang til det interne netværk, kan angrebet stadig udføres. Vi anbefaler at opdatere uanset placering.
Hvordan tjekker vi, om vi allerede er blevet angrebet?
Gennemgå logs for Dockhand’s webhook-endpoints for uventede eller gentagne kald, særligt uden gyldig signatur. Kig også efter uforklarede genudrulninger af stakke i den periode, hvor I kørte en sårbar version.
Skal vi anmelde hændelsen, hvis vi finder tegn på misbrug?
Hvis der er sket databrud eller kompromittering af persondata, kan I være forpligtet til at anmelde det til Datatilsynet inden for 72 timer. Vi anbefaler at kontakte en rådgiver hurtigt for at vurdere omfanget.
Er der en midlertidig løsning, hvis vi ikke kan opdatere med det samme?
Sæt en webhook-hemmelighed på alle stakke og begræns netværksadgang til Dockhand’s endpoints til kendte IP-adresser. Det lukker ikke fejlen fuldstændigt, men reducerer risikoen betydeligt.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Dockhand before 1.0.40 contains an authentication bypass vulnerability in its git webhook endpoints that allows unauthenticated remote attackers to trigger arbitrary stack redeployments by exploiting a null webhook secret guard condition. Attackers can enumerate sequential stack IDs and send unsigned webhook requests to force git clone and docker compose operations, enabling denial of service or, when combined with write access to the tracked git branch, container escape and full host compromise via attacker-controlled docker-compose.yml with privileged bind mounts.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.