GHSA-8342-988Q-86CR

Vulnerability from github – Published: 2026-07-22 22:04 – Updated: 2026-07-22 22:04
VLAI
Summary
n8n: Account Takeover via Unverified Email Claim in Token Exchange Embed Login
Details

Impact

In an n8n instance, when a validly-signed incoming token was matched to a local account by its email claim, the service did not check that the trusted key's permitted role ceiling covered that account, nor that the email claim was verified. As a result, anyone able to obtain a token accepted by one of the configured trusted keys, for example a trusted issuer that emitted unverified email addresses, could authenticate as any existing user, gaining full account control.

This issue only affects instances where the embed login feature is enabled and at least one trusted key source is configured.

Patches

The issue has been fixed in n8n version 2.32.1. Users should upgrade to this version or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Disable the embed login feature by setting N8N_TOKEN_EXCHANGE_ENABLED=false. - If embed login cannot be disabled, restrict network access to the n8n instance to fully trusted parties only, and audit all configured trusted keys and their allowedRoles assignments. - Review auth_identity records for unexpected token-exchange entries linked to high-privilege accounts.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.32.0"
            },
            {
              "fixed": "2.32.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.31.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T22:04:54Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\nIn an n8n instance, when a validly-signed incoming token was matched to a local account by its email claim, the service did not check that the trusted key\u0027s permitted role ceiling covered that account, nor that the email claim was verified. As a result, anyone able to obtain a token accepted by one of the configured trusted keys, for example a trusted issuer that emitted unverified email addresses, could authenticate as any existing user, gaining full account control.\n\nThis issue only affects instances where the embed login feature is enabled and at least one trusted key source is configured.\n\n## Patches\n\nThe issue has been fixed in n8n version 2.32.1. Users should upgrade to this version or later to remediate the vulnerability.\n\n## Workarounds\n\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Disable the embed login feature by setting `N8N_TOKEN_EXCHANGE_ENABLED=false`.\n- If embed login cannot be disabled, restrict network access to the n8n instance to fully trusted parties only, and audit all configured trusted keys and their `allowedRoles` assignments.\n- Review `auth_identity` records for unexpected `token-exchange` entries linked to high-privilege accounts.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
  "id": "GHSA-8342-988q-86cr",
  "modified": "2026-07-22T22:04:55Z",
  "published": "2026-07-22T22:04:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-8342-988q-86cr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/f69dfc6dd2178a14ea1624d2e1d403c2e755042f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.31.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.32.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n: Account Takeover via Unverified Email Claim in Token Exchange Embed Login"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…