CVE-2026-70558: Kritisk filskrivningsfejl i Dinky
Dinky har en kritisk fejl, hvor angribere uden login kan skrive filer og køre kode via en hardkodet standardnøgle. Skift nøglen i dag.
Hvad er det?
CVE-2026-70558 er en sårbarhed i Dinky, en platform til realtidsdatabehandling bygget oven på Apache Flink. Funktionen til filupload tager en sti direkte fra en netværksforespørgsel og skriver filen på serveren uden at kontrollere, om stien er tilladt. Det kaldes en usikker filupload, hvor angribere kan placere vilkårlige filer hvor som helst i applikationens mappe. Den eneste beskyttelse er en header, der skal matche en nøgle kaldet dinkyToken. Problemet er, at standardværdien af denne nøgle ligger direkte i Dinkys kildekode og følger med i alle installationer, medmindre den ændres manuelt.
Hvem rammer det?
Sårbarheden rammer Dinky version 1.2.5 og udviklingsgrenen, hvor koden er identisk. Det gælder især installationer, der kører standard Docker-opsætningen, hvor port 8888 er åben uden firewall eller adgangskontrol foran, og hvor mappen /opt/dinky har fri skriverettighed for alle. Danske virksomheder og kommuner, der bruger Dinky til at styre dataflows mellem systemer, er berørt, hvis serveren er tilgængelig fra internettet eller fra et internt netværk, angribere allerede har adgang til.
Hvad kan ske?
En angriber, der kan nå Dinkys HTTP-port og kender den hardkodede standardnøgle, kan overskrive applikationens egne filer. I den dokumenterede demonstration blev forsiden erstattet med skadelig JavaScript, der ramte administratorers browsere med det samme. En anden fil blev overskrevet, så angriberens kode blev kørt automatisk, næste gang Dinky-tjenesten startede op, med samme rettigheder som selve tjenesten. Angriberen kan ikke skrive til systemfiler som /etc eller /root, men kan fuldstændig overtage selve Dinky-applikationen og alt, hvad den har adgang til.
Hvor alvorligt er det?
CVSS-scoren er 9,8 ud af 10, kritisk. Angrebet kræver ikke login, ingen handling fra en bruger og kan udføres over netværket med lav kompleksitet. Der findes offentligt en dokumenteret metode til at udnytte fejlen, herunder hvordan den hardkodede nøgle bruges til at skrive og køre kode. Der er ikke rapporteret aktiv udnyttelse i drift, men fordi metoden er kendt og enkel, er risikoen for hurtig udnyttelse høj, hvis serveren er tilgængelig udefra.
Hvad gør jeg nu?
Følg punkterne i rækkefølge for at lukke hullet og begrænse skaden:
- Skift standardværdien af dinkyToken til en unik, hemmelig værdi i konfigurationen på alle installationer med det samme.
- Sørg for, at Dinkys port 8888 ikke er tilgængelig direkte fra internettet, placér den bag en firewall eller en reverse proxy med autentifikation.
- Ret filrettighederne på /opt/dinky, så den ikke længere er fuldt skrivbar for alle (chmod 777).
- Gennemgå logfiler og filtidsstempler for uventede ændringer i /opt/dinky/config/static og org/dinky/Dinky.class.
- Følg Dinkys projektside for en officiel rettelse, og opdater så snart en patchet version udgives.
- Kontakt ekstern sikkerhedshjælp, hvis I finder tegn på ændrede filer, eller hvis I ikke selv kan verificere, om systemet har været udsat for angrebet.
Skift standardnøgle og luk port 8888 i dag
Vi anbefaler, at I straks skifter standardværdien af dinkyToken og sikrer, at Dinkys port ikke er åben mod internettet, uanset om I planlægger at opdatere senere. Det er kun forsvarligt at vente, hvis Dinky-installationen kører isoleret på et netværk, hvor ingen uvedkommende har adgang, og selv da bør nøglen ændres som en simpel forholdsregel. Er serveren eksponeret direkte, bør I samtidig gennemgå logs for tegn på, at fejlen allerede er blevet udnyttet.
Tidslinje
Konkrete eksempler
Eksponeret Dinky-server i skyen
En dansk virksomhed kører Dinky i en sky-tjeneste til at styre datapipelines mellem forretningssystemer. Standard Docker-opsætningen bliver brugt uden ændringer, og port 8888 er tilgængelig direkte fra internettet. En angriber finder porten, bruger den hardkodede standardnøgle og overskriver forsiden med skadelig kode, der rammer administratorernes browsere, næste gang de logger ind.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger den sårbare version?
Tjek versionen af jeres Dinky-installation i administrationsgrænsefladen eller i konfigurationsfilerne. Version 1.2.5 og den nyeste udviklingsgren er berørt. Er I i tvivl, bør I antage, at I er ramt, og gennemføre tiltagene med det samme.
Er vi ramt, hvis Dinky kun kører internt på vores netværk?
Risikoen er lavere, men ikke væk. Alle med adgang til det interne netværk, herunder en kompromitteret medarbejdercomputer, kan udnytte fejlen. Vi anbefaler stadig at skifte standardnøglen og begrænse adgangen til porten.
Kan vi vente med at rette det til efter weekenden?
Selve nøgleskiftet tager få minutter og kræver ingen nedetid at tale om. Der er ingen grund til at vente, især hvis serveren er tilgængelig fra internettet.
Hvordan tjekker vi, om vi allerede er blevet ramt?
Se efter uventede ændringer i filerne /opt/dinky/config/static/index.html og org/dinky/Dinky.class. Uforklarede filtidsstempler eller ukendt JavaScript på forsiden er tegn på, at fejlen er blevet udnyttet.
Skal vi anmelde hændelsen, hvis vi finder spor af angreb?
Hvis I finder tegn på, at systemet er kompromitteret, og persondata kan være berørt, skal I vurdere anmeldelsespligt efter databeskyttelsesreglerne og kan med fordel kontakte en sikkerhedsrådgiver for hjælp til at afgrænse hændelsen.
Er der en officiel rettelse fra Dinky-projektet?
Der er på offentliggørelsestidspunktet ikke oplyst en patchet version. Indtil da er ændring af standardnøglen og netværksbegrænsning den eneste beskyttelse.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Dinky’s POST /download/uploadFromRsByLocal handler passes the caller-supplied path parameter directly to new File(path) and file.transferTo(dest) with no path validation. The route is marked @SaIgnore and /download/** is excluded from the Sa-Token interceptor, so the only guard is a header equality check against a dinkyToken value whose default (efda1551-7958-4e0f-80a8-dfd107df3e38) is hardcoded in source and shipped to every deployment. Anyone who can reach Dinky’s HTTP port (8888 by default) and supplies the hardcoded token can write arbitrary files as the Dinky service account. The default Docker image runs on 8888 with no proxy or authentication and chmod 777 on /opt/dinky, so the application’s own classpath, launch scripts, and static assets are writable. Demonstrated impact: overwriting /opt/dinky/config/static/index.html served attacker JavaScript to admin browsers immediately, and writing /opt/dinky/org/dinky/Dinky.class executed attacker code as the Dinky service account at the next JVM start via a classpath-shadow launched by script/bin/auto.sh. Writes are uid 9999 (flink), not root, so /etc, /root, /home, and /usr are refused. Affects Dinky v1.2.5 (the current release) and the development branch, where the code is byte-identical.
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.