GHSA-8342-988q-86cr: n8n — HIGH

Q: Is GHSA-8342-988q-86cr actively exploited?

No confirmed active exploitation of GHSA-8342-988q-86cr has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-8342-988q-86cr?

Update to patched version: n8n 2.32.1.

Q: What is the CVSS score for GHSA-8342-988q-86cr?

No CVSS score has been assigned yet.

## 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...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.32.0, < 2.32.1	`2.32.1`
197.0K OpenSSF 6.6 16 dependents Pushed 4d ago 61% patched ~6d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What should I do?

Patch available

Update n8n to version 2.32.1

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-8342-988q-86cr?

## 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.

Is GHSA-8342-988q-86cr actively exploited?

No confirmed active exploitation of GHSA-8342-988q-86cr has been reported, but organizations should still patch proactively.

How to fix GHSA-8342-988q-86cr?

Update to patched version: n8n 2.32.1.

What is the CVSS score for GHSA-8342-988q-86cr?

No CVSS score has been assigned yet.

What are the technical details?

Original Advisory

## 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.

Weaknesses (CWE)

CWE-345 Insufficient Verification of Data Authenticity Primary CWE-863 Incorrect Authorization Primary

CWE-345 — Insufficient Verification of Data Authenticity: The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

Source: MITRE CWE corpus.