CVE-2026-56348: Kritisk SSRF-fejl i n8n stjæler loginoplysninger
n8n før version 2.20.0 kan lokkes til at sende loginoplysninger til fremmede servere. Opdatér til 2.20.0.
Hvad er det?
Sårbarheden er en SSRF-fejl (Server-Side Request Forgery), hvor en server kan snydes til at sende netværkskald til mål, som angriberen bestemmer, i stedet for de tilladte mål. I n8n, et automatiseringsværktøj til at koble systemer og API’er sammen, ligger fejlen i endpointet POST /rest/dynamic-node-parameters/options. En bruger, der allerede er logget ind, kan omgå indstillingen Allowed HTTP Request Domains, som ellers begrænser hvilke domæner serveren må kontakte. Serveren kan derved narres til at sende gemte loginoplysninger til en server, angriberen kontrollerer.
Hvem rammer det?
Det rammer alle virksomheder og kommuner, der kører n8n selv, altså en egen installation frem for n8n Cloud, i en version ældre end 2.20.0. Det gælder især installationer, hvor flere brugere har adgang, og hvor n8n er sat op til at bruge gemte legitimationsoplysninger som API-nøgler, adgangskoder eller adgangstokens i workflows, for eksempel til CRM-systemer, betalingsløsninger eller interne API’er.
Hvad kan ske?
En bruger med lav adgang, for eksempel en medarbejder med begrænset rolle eller en kompromitteret konto, kan bruge fejlen til at få n8n-serveren til at sende gemte legitimationsoplysninger til en server, angriberen selv styrer. Dermed kan angriberen stjæle adgangsnøgler til andre systemer, som n8n er koblet til, og bruge dem til at logge ind andre steder, uden at det kræver, at nogen klikker på noget eller åbner en vedhæftet fil.
Hvor alvorligt er det?
CVSS-scoren er 9,1 ud af 10, kritisk. Angrebet kræver, at man er logget ind med en almindelig bruger, men kræver ingen handling fra andre og ingen adgang til det interne netværk ud over adgangen til n8n-serveren over nettet. Konsekvensen er høj, fordi følsomme legitimationsoplysninger kan lækkes, mens skaden på selve dataintegriteten og driften er begrænset. Der er ikke oplysninger om, at sårbarheden aktivt bliver udnyttet i angreb på offentliggørelsestidspunktet.
Hvad gør jeg nu?
Sådan lukker I hullet og begrænser skaden, hvis det allerede er udnyttet:
- Opdatér n8n til version 2.20.0 eller nyere. Det lukker selve sårbarheden i endpointet.
- Gennemgå, hvilke brugere der har adgang til jeres n8n-installation, og fjern konti, der ikke længere skal bruges.
- Skift de legitimationsoplysninger (API-nøgler, adgangskoder, tokens), der er gemt i n8n-workflows, hvis I ikke kan udelukke, at de har været udsat siden fejlen opstod.
- Gennemgå logfiler for usædvanlige udgående kald fra n8n-serveren til ukendte domæner i perioden før opdateringen.
- Stram jeres Allowed HTTP Request Domains-liste, så den kun tillader de domæner, der reelt bruges.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv kan afgøre, om jeres opsætning har været udsat, eller hvis I finder tegn på misbrug i logfilerne.
Opdatér inden for 7 dage
Vi anbefaler, at I opdaterer n8n til version 2.20.0 så hurtigt, det praktisk kan lade sig gøre, og samtidig skifter de legitimationsoplysninger, der ligger i jeres workflows. Det er kun forsvarligt at vente, hvis jeres n8n-installation ikke er tilgængelig fra internettet og kun har få, betroede brugere. I alle andre tilfælde bør opdateringen prioriteres foran almindeligt driftsarbejde, fordi fejlen kan udnyttes af enhver logget ind bruger uden yderligere handlinger.
Tidslinje
Konkrete eksempler
Lækket API-nøgle fra en dansk virksomheds n8n-opsætning
En mindre dansk virksomhed bruger n8n til at koble sit CRM-system sammen med økonomisystemet og har gemt en API-nøgle til begge systemer i n8n. En medarbejder med begrænset adgang, eller en konto der er blevet kompromitteret via en anden fejl, bruger den sårbare funktion til at få n8n-serveren til at sende API-nøglen til en server, medarbejderen selv styrer. Med nøglen kan angriberen efterfølgende logge ind i CRM-systemet direkte og trække kundedata ud, uden at det kræver adgang til virksomhedens øvrige netværk.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er berørt, hvis I selv driver en n8n-installation i en version ældre end 2.20.0. Tjek versionsnummeret i jeres n8n-administration eller i deployment-konfigurationen.
Hvordan tjekker vi vores version?
Log ind i n8n og se versionsnummeret i brugerfladen, eller tjek Docker-image-taggen eller pakkeversionen, hvis I kører n8n via npm eller container. Er versionen under 2.20.0, er I sårbare.
Kan vi vente til weekenden med at opdatere?
Det afhænger af, om jeres n8n er tilgængelig for flere brugere eller fra internettet. Har I flere brugere med adgang, bør opdateringen ske hurtigst muligt, da fejlen kun kræver en almindelig login, ingen særlige rettigheder.
Skal vi anmelde hændelsen, hvis vi finder tegn på misbrug?
Hvis I finder konkrete tegn på, at legitimationsoplysninger er blevet lækket og misbrugt, skal I vurdere, om det udløser anmeldepligt efter databeskyttelsesreglerne. Vi anbefaler at inddrage jeres databeskyttelsesrådgiver eller en sikkerhedsrådgiver til den vurdering.
Rammer det også n8n Cloud?
Sårbarheden er beskrevet for selvhostede n8n-installationer. Bruger I n8n Cloud, bør I kontrollere med leverandøren, om og hvornår opdateringen er rullet ud på deres side.
Hvad gør vi, hvis vi ikke selv kan opdatere med det samme?
Begræns i mellemtiden, hvem der har adgang til n8n, og stram listen over tilladte domæner i Allowed HTTP Request Domains, så den kun indeholder domæner, I reelt bruger. Det reducerer, men fjerner ikke, risikoen.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
n8n before 2.20.0 contains a credential exfiltration vulnerability in the POST /rest/dynamic-node-parameters/options endpoint that allows authenticated users to bypass Allowed HTTP Request Domains restrictions. Attackers with credential access can cause the n8n server to issue HTTP requests with credentials to unauthorized hosts, exfiltrating sensitive authentication data.
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.