Hopp til hovedinnhold
PULSEN_
ESC Tilbake til strømmen
The Hacker News · 1T SIDEN · sikkerhet

n8n-feil kunne logge deg inn som feil bruker på tvers av token-issuere

SYNOPSIS_GENERERT

En autentiseringsfeil i n8ns Enterprise-funksjon token exchange (CVE-2026-59208) kunne logge deg inn som en annen bruker fra en annen issuer. Oppgrader til minst 2.27.4 eller 2.28.1.

n8n delte ut feil kontoer ved innlogging, melder The Hacker News. På Enterprise-instanser satt opp til å stole på mer enn én ekstern token-issuer matchet plattformen en innkommende JWT mot en lokal bruker kun på sub-claimet, og ignorerte iss. Et gyldig token fra issuer A, med en sub som tilhørte noen under issuer B, logget deg inn som den personen. Passordet deres kom aldri inn i bildet.

Feilen ligger i identitetsbindingen. En sub-verdi er bare garantert unik innenfor issueren som utstedte den, slik RFC 7519 beskriver, så den reelle identifikatoren for en bruker er paret iss pluss sub. n8n nøklet på halvparten, og ingenting hindrer to issuere i å sende ut samme subject-streng. Når de gjør det, havner begge på én n8n-konto.

Token exchange er n8ns Enterprise-rute for OEM-partnere som bygger produktet inn i sitt eget (en RFC 8693-implementasjon), og funksjonen er fortsatt merket som «preview» i dokumentasjonen. Partneren signerer et kortlevd JWT med sin egen nøkkel, n8n verifiserer det mot en konfigurert offentlig nøkkel og matcher claimene mot en lokal konto. Selve tokenet er gyldig. Det er matchingen som svikter.

«Ingen av korttidstiltakene fjerner risikoen fullstendig.» — n8ns sikkerhetsråd for CVE-2026-59208

The Hacker News påpeker at denne formuleringen er standardtekst, identisk i minst tre andre n8n-råd. Etter n8ns egen avgrensning er en instans med token exchange avslått ikke berørt i det hele tatt. Rekkevidden er dermed liten og spesifikk: bare instanser der token exchange er på og konfigurasjonen stoler på minst to eksterne issuere, altså OEM-oppsett.

Alvorlighetsgraden spriker mellom kildene. GitHub, som CNA, setter CVE-2026-59208 til 7.6 på CVSS 4.0 (høy), mens NVD gir samme feil 6.8 på CVSS 3.1 (medium) og har ikke levert en 4.0-vurdering. NVD registrerer svakhetene som CWE-287 og CWE-346. CISAs SSVC-vurdering fra 13. juli fører utnyttelse som «ingen», og The Hacker News fant ingen offentlig proof-of-concept i søk 16. juli. Feilen ble rettet 24. juni, mens CVE-en først ble offentlig 9. juli. Rapporten krediteres GitHub-kontoen bearsyankees, knyttet til Strix, som lager en KI-basert penetrasjonstest-agent.

Et poeng som er lett å gå glipp av: verken 2.27.4- eller 2.28.1-changelogen nevner rettelsen. Ifølge The Hacker News dekker de to endringsloggene en Python-import, en Google Ads-node, en KI-arbeidsflytsjekk og en node-endring, men ingenting om identitet. Fiksen lever i sikkerhetsrådet. Kjører oppgraderingsbeslutningene dine på changelogs, glipper denne typen rettelse forbi.

Hva bør du gjøre?

  1. Oppgrader til nyeste stabile bygg du kan kjøre. Feilen rammer alle n8n-utgivelser under 2.27.4 pluss versjon 2.28.0, og rettelsen kom i 2.27.4 og 2.28.1. npm-pakken lå på 2.30.6 den 16. juli.
  2. Må du vente med patching, kutt N8N_TOKEN_EXCHANGE_TRUSTED_KEYS tilbake til én enkelt issuer, eller slå av token exchange helt.
  3. Sjekk sikkerhetsrådet, ikke changelogen, for n8n-sårbarheter framover. To uker før denne feilen rettet vedlikeholderne CVE-2026-54305, en annen Enterprise-feil på samme angrepsflate.

KI-KURATERT — INNHOLD GENERERT AV KI-AGENTER BASERT PÅ ORIGINALKILDEN