n8n, het workflowautomatiseringsplatform, deelde bij het inloggen de verkeerde accounts uit. Op Enterprise-instanties die zijn geconfigureerd om meer dan één externe tokenuitgever te vertrouwen, koppelde het een binnenkomende JWT aan een lokale gebruiker op de sub claim alleen en genegeerd iss.
Een geldig token van uitgever A met a sub die toebehoort aan iemand onder uitgever B, waarbij u als deze heeft ingelogd. Hun wachtwoord kwam er nooit in voor. n8n heeft de oplossing op 24 juni verzonden.
De fout wordt bijgehouden als CVE-2026-59208. Het CVE-record werd pas op 9 juli openbaar. n8n schrijft het rapport toe aan het GitHub-account bearsyankees, wiens profiel Strix vermeldt, een AI-penetratietestagent.
Strix zegt dat het erop heeft gewezen dat de agent bij de token-uitwisselingsstroom was en daar de identiteitsbindende bug heeft gevonden.
Twee emittenten, één rekening
Tokenuitwisseling is de Enterprise-route van n8n voor OEM-partners die het product insluiten, een RFC 8693-implementatie die hun gebruikers een tweede inlogscherm bespaart.
De partner ondertekent een kortstondige JWT met zijn eigen sleutel, n8n verifieert deze aan de hand van een geconfigureerde openbare sleutel, koppelt de claims aan een lokaal account en de gebruiker doet mee. Vertrouwde sleutels gaan erin N8N_TOKEN_EXCHANGE_TRUSTED_KEYSen de implementatiedocumentatie tagt de functie nog steeds als preview.
Het token zelf wordt uitgecheckt. Het matchen is de bug. A sub de waarde is alleen gegarandeerd uniek binnen de uitgever die deze heeft uitgegeven. RFC 7519 vraagt dat het “zo moet worden ingesteld dat het lokaal uniek is in de context van de uitgevende instelling” of anders globaal uniek. De identificatie voor een gebruiker is daarom het paar, iss plus sub.
n8n toetste de helft ervan in. Niets houdt twee emittenten tegen om dezelfde onderwerpreeks uit te zenden, en als ze dat doen, komen ze allebei op één n8n-account terecht.
Hoe groot is dit?
De fout bereikt alleen een exemplaar als de tokenuitwisseling is ingeschakeld en de configuratie ten minste twee externe uitgevers vertrouwt. n8n zegt dat er niets anders wordt beïnvloed. Tokenuitwisseling is alleen voor Enterprise en wordt nog steeds gemarkeerd als preview, dus de blootgestelde set is klein en specifiek: OEM-implementaties, waarbij het vertrouwen op een tweede uitgever een ondersteunde configuratie is.
Wat het advies niet vastlegt, is hoe een aanvaller het token krijgt. Er staat alleen dat ze er een kunnen krijgen. De praktische vraag is of een gewone gebruiker bij een vertrouwde uitgevende instelling invloed kan uitoefenen op de sub zij ontvangen. Het openbare register geeft er geen antwoord op. De CVSS 4.0-vector van GitHub markeert aanvalsvereisten als aanwezig en stopt daar.
GitHub heeft die vector toegewezen. Zoals de CNA hier stelt CVE-2026-59208 met 7,6 op CVSS 4.0, hoog. NVD zet dezelfde bug op 6.8 op CVSS 3.1, medium, en heeft helemaal geen 4.0-beoordeling uitgegeven; zijn record draagt CWE-287 En CWE-346. CISA’s SSVC-beoordeling van 13 juli registreert uitbuiting als geen, en The Hacker News vond geen openbare proof-of-concept in zoekopdrachten op 16 juli.
Twee weken voor de oplossing van 24 juni hebben de beheerders een patch uitgevoerd CVE-2026-54305nog een fout die alleen in Enterprise voorkomt. Hiermee kan elke geverifieerde gebruiker de opgeslagen OAuth-tokens van een andere gebruiker overschrijven of intrekken via de Dynamic Credentials-eindpunten. Dat was een ontbrekende eigendomscontrole, geen identiteitsbewijs. Andere bug, hetzelfde oppervlak.
The Hacker News heeft contact opgenomen met n8n voor bevestiging over de reikwijdte en impact van CVE-2026-59208 en zal dit verhaal bijwerken bij elke reactie.
Patch of knip de lijst met uitgevers
CVE-2026-59208 is van invloed op elke n8n-release onder 2.27.4 en versie 2.28.0. De oplossing kwam voor het eerst terecht in 2.27.4 en 2.28.1. Dat zijn de vloeren. Op 16 juli bevatte het npm-pakket van n8n 2.30.6 op beide latest En stable labels. Het verzendt de meeste weken een nieuwe minor via zijn eigen account, dus controleer de tag en neem de nieuwste stabiele build die uw implementatie ondersteunt.
Als het patchen moet wachten, zoek dan uit wat u gebruikt: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS bevat de vertrouwde ondertekeningssleutels en een afzonderlijke voorbeeldvlag bepaalt of de tokenuitwisseling überhaupt is ingeschakeld. Beperk u tot één vertrouwde uitgever of schakel de functie uit.
Het advies noemt beide maatregelen op de korte termijn, maar zegt dat geen van beide het risico volledig herstelt. Dat is de standaardtekst, identiek in ten minste drie andere n8n-adviezen, waaronder die van 10 juni. Door de eigen scope-instructie van n8n wordt een instantie waarbij tokenuitwisseling is uitgeschakeld niet beïnvloed.
Geen van beide releasenotes vermeldt de oplossing. The Hacker News heeft beide gecontroleerd: de changelogs 2.27.4 en 2.28.1 hebben betrekking op een Python-importfix, een Google Ads-knooppuntupgrade, een AI-workflowcontrole en een wijziging in het bouwen van knooppunten, en niets over identiteit.
Het advies is waar deze woont. Als uw upgradebeslissingen gebaseerd zijn op changelogs, is dit het soort oplossing dat voorbijglipt.
