n8n CVE-2026-59208 : une faille JWT token exchange qui vous connecte sous l'identité d'un autre

> En bref : CVE-2026-59208 est une faille de liaison d'identité JWT dans le flux Enterprise de token exchange de n8n. Sur les instances configurées pour faire confiance à plus d'un émetteur externe, un token valide de l'émetteur A portant un sub appartenant à un utilisateur de l'émetteur B vous connectait sous son identité. Aucun mot de passe en jeu. Correctif : n8n 2.27.4 et 2.28.1 (livrés le 24 juin 2026).

Pourquoi ça vous concerne

n8n est la plateforme d'automatisation de workflows open-source que beaucoup d'équipes SaaS embarquent pour l'automatisation interne, les intégrations clients ou des fonctionnalités OEM. Nous avons déjà écrit sur la sécurité des webhooks n8n — cette CVE est sur une autre surface, mais le même produit, et elle vise la chose la plus sensible que n8n détient : sous quelle identité vous êtes connecté.

Plus largement, c'est un bug JWT, et les bugs JWT voyagent. L'erreur de liaison d'identité exacte se retrouve dans les implémentations SSO maison, les produits embarqués OEM, et tout flux de token exchange fait main. Si vous construisez de l'identité fédérée, lisez la suite.

La faille en deux phrases

Le token exchange (RFC 8693) est la voie Enterprise de n8n pour les partenaires OEM qui embarquent le produit. Le partenaire signe un JWT court terme avec sa propre clé, n8n le vérifie contre une clé publique configurée (N8N_TOKEN_EXCHANGE_TRUSTED_KEYS), rapproche les claims d'un compte local, et l'utilisateur est connecté.

Le token lui-même était valide. Le rapprochement était le bug. n8n indexait uniquement sur sub et ignorait iss. Une valeur de sub n'est garantie unique qu'au sein de l'émetteur qui l'a émise — selon la RFC 7519, l'identité, c'est la *paire* iss + sub. n8n n'en gardait que la moitié. Rien n'empêche deux émetteurs d'émettre le même sujet, et quand c'est le cas, les deux atterrissent sur un seul compte n8n.

La leçon : l'identité est une paire, pas un claim

C'est la partie à mémoriser, parce qu'elle n'est pas spécifique à n8n. Chaque fois que votre backend résout un JWT vers un utilisateur local, la clé de recherche doit être (iss, sub), jamais sub seul. Dès que vous faites confiance à deux émetteurs — deux IdP, un partenaire OEM et votre propre IdP, un tenant de staging et un tenant de prod — les collisions de sub deviennent possibles, et le premier à enregistrer un nom d'utilisateur gagne toutes les collisions.

Variantes classiques de ce bug :

Toujours le même bug, habillé différemment.

Quelle est l'exposition

Le périmètre de n8n est étroit et ils le disent. Le token exchange est réservé à l'Enterprise, toujours marqué preview, et la faille ne se déclenche que sur les instances qui font confiance à au moins deux émetteurs externes. C'est un ensemble petit et spécifique — essentiellement des déploiements OEM. Le CVSS tombe à 7.6 en 4.0 (high) et 6.8 en 3.1 (medium), CWE-287 (authentification impropre) et CWE-346 (erreur de validation d'origine).

Ce que l'advisory ne précise pas, c'est comment l'attaquant obtient le token. À la mi-juillet, l'évaluation SSVC de la CISA ne recense aucune exploitation et il n'y a pas de proof-of-concept publique. La question réaliste — un utilisateur ordinaire d'un émetteur de confiance peut-il influencer le sub qu'il reçoit ? — n'est pas tranchée dans le dossier public.

Ce qu'il faut faire

Pour un éditeur SaaS, la leçon tient à la paire, pas à la plateforme : à chaque fois que l'identité traverse une frontière de confiance, iss + sub ensemble, jamais l'un sans l'autre.