CVE-2026-65057: SSRF-sårbarhed i Keep-platformen
SSRF-fejl i Keep lader uautoriserede angribere få backend til at hente cloud-legitimationsoplysninger. Afskærm healthcheck-endpointet nu.
Hvad er det?
CVE-2026-65057 er en SSRF-sårbarhed (Server-Side Request Forgery, hvor en angriber får en server til selv at sende forespørgsler til mål, den ikke skulle kontakte) i platformen Keep, set i commit 91c75e0. Sårbarheden findes i et healthcheck-endpoint, der ikke kræver login. En angriber kan sende en manipuleret JSON-forespørgsel med et selvvalgt host-felt, og backend-serveren vil så udføre en HTTP-forespørgsel til den adresse, angriberen har angivet, uden at kontrollere om målet er internt eller eksternt.
Hvem rammer det?
Sårbarheden rammer organisationer, der selv driver Keep, en open source platform til alarmering og on-call håndtering. Det gælder installationer omkring commit 91c75e0, hvor healthcheck-endpointet er tilgængeligt uden autentificering. Er Keep hostet i en cloud-tjeneste som AWS, Azure eller GCP, er risikoen særligt relevant, fordi metadata-tjenester i disse platforme ofte er nået via interne adresser.
Hvad kan ske?
En angriber kan få backend-serveren til at hente data fra cloud-udbyderens metadata-endpoint, hvor der typisk ligger midlertidige nøgler til cloud-kontoen. Med disse nøgler kan angriberen få adgang til lagerplads, databaser og andre ressourcer i jeres cloud-miljø. Sårbarheden kan også bruges til at afsøge jeres interne netværk for andre systemer, som normalt ikke er tilgængelige fra internettet.
Hvor alvorligt er det?
CVSS-scoren er 9,3 ud af 10, kritisk. Angrebet kræver ikke login og ingen handling fra en bruger, og det kan udføres over netværket med lav teknisk kompleksitet. Konsekvensen er høj for fortrolighed, fordi følsomme data som cloud-nøgler kan lækkes, mens integritet er begrænset og tilgængelighed ikke påvirkes direkte. Der er ikke rapporteret aktiv udnyttelse i offentligheden på offentliggørelsesdatoen, men det tekniske indgreb er enkelt at gennemføre, når man kender endpointet.
Hvad gør jeg nu?
Følg punkterne i denne rækkefølge:
- Afskær healthcheck-endpointet fra offentlig adgang, eller kræv autentificering på det, så eksterne parter ikke kan sende forespørgsler direkte til det.
- Tjek Keep-projektets kildekode for en rettet version nyere end commit 91c75e0, og opgradér så snart en fast version er tilgængelig.
- Begræns backend-serverens udgående netværksadgang, så den ikke kan nå cloud-metadata-adresser (som 169.254.169.254) eller interne systemer, den ikke har brug for.
- Aktivér IMDSv2 eller lignende beskyttelse hos jeres cloud-udbyder, hvis I bruger AWS, Azure eller GCP, så metadata kun kan læses med et ekstra sikkerhedslag.
- Gennemgå logs for usædvanlige udgående forespørgsler fra Keep-serveren, særligt mod interne IP-adresser eller metadata-tjenester.
- Hent hjælp udefra, hvis I ikke selv kan verificere, om jeres Keep-installation er sårbar, eller hvis I ikke har kompetencer til at hardene netværksadgangen.
Afskær endpointet inden for 24 timer
Vi anbefaler, at I straks afskærmer healthcheck-endpointet fra offentlig adgang og begrænser Keep-serverens udgående netværksforbindelser, da der endnu ikke findes en officiel rettelse. Det er ikke forsvarligt at vente til en fast version udkommer, fordi angrebet kan udføres uden login og med enkle midler. I kan vente med de øvrige hærdningstiltag til I har haft tid til at teste dem, så længe endpointet er lukket for eksterne forespørgsler i mellemtiden.
Tidslinje
Konkrete eksempler
On-call platform hostet i AWS
En dansk it-virksomhed bruger Keep til at håndtere alarmer fra deres overvågningssystemer, hostet på en AWS-server. En angriber finder healthcheck-endpointet tilgængeligt uden login og sender en forespørgsel, der får serveren til at kontakte AWS’ metadata-tjeneste. Angriberen får dermed midlertidige AWS-nøgler og kan efterfølgende læse data fra virksomhedens S3-lagerplads.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi er ramt?
Tjek om jeres Keep-installation stammer fra commit 91c75e0 eller tidligere, og om healthcheck-endpointet kan tilgås uden login fra internettet. Er det tilfældet, er I sårbare.
Kan vi vente til efter weekenden med at lukke hullet?
Nej. Afskærmning af endpointet kræver typisk kun en firewall-regel eller en ændring i adgangsstyringen og bør ske samme dag, I bliver bekendt med sårbarheden.
Skal vi anmelde noget, hvis vi finder tegn på misbrug?
Finder I beviser på, at cloud-nøgler eller interne data er blevet tilgået af en uautoriseret part, skal I vurdere, om det udløser anmeldelsespligt efter databeskyttelsesreglerne, og eventuelt kontakte Datatilsynet.
Er det nok at opdatere Keep, når en rettelse kommer?
Nej. Selv efter en opdatering bør I fortsat begrænse serverens udgående netværksadgang til metadata-tjenester, da SSRF-sårbarheder ofte kan opstå igen i andre dele af systemet.
Påvirker sårbarheden også vores egne interne systemer, ikke kun cloud-udbyderen?
Ja. Angriberen kan bruge det sårbare endpoint til at afsøge og kontakte andre systemer på jeres interne netværk, ikke kun cloud-metadata.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Keep (commit 91c75e0) contains a server-side request forgery vulnerability that allows unauthenticated attackers to make the backend issue arbitrary HTTP requests by supplying attacker-controlled host values to the unprotected healthcheck endpoint. Attackers can send a crafted JSON payload with a malicious host parameter to cause the backend to issue outbound requests to internal services or cloud metadata endpoints, enabling theft of cloud credentials and internal network reconnaissance.
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.