CVE-2026-56359: n8n: XSS via malicious OAuth2 Authorization URL

MEDIUM
Published July 8, 2026
CISO Take

A stored cross-site scripting flaw in n8n's credential management lets any authenticated user embed a javascript: URL in the OAuth2 'Authorization URL' field of a crafted credential, so when another user clicks the OAuth 'Connect' button the script runs in that victim's authenticated session (CVSS 5.4, scope changed). There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so this isn't an active-exploitation emergency — but n8n carries a package risk score of 69/100 with 123 other known CVEs and an OpenSSF Scorecard of only 6.6/10, a track record worth weighing given n8n often sits at the center of AI agent workflows holding OAuth credentials for LLM and SaaS integrations. The attack only requires a low-privileged authenticated attacker plus one click from a higher-privileged user (e.g., an admin authorizing what looks like a legitimate AI service connector), making it a realistic insider or social-engineering vector rather than an internet drive-by. Upgrade to n8n 2.8.0 or later; in the interim, restrict who can create or edit credentials to trusted admins and audit existing OAuth2 credentials for Authorization URL fields containing 'javascript:' or other non-HTTP(S) schemes.

Sources: NVD GitHub Advisory VulnCheck ATLAS OpenSSF

What is the risk?

Medium severity (CVSS 5.4) reflects low confidentiality/integrity impact and no availability impact, but the changed scope (S:C) is the real driver of concern: successful exploitation lets the attacker act with the victim's privileges outside the vulnerable component itself, i.e. inside the victim's full n8n session. Exploitability is constrained by two gates — the attacker needs an authenticated account with credential-creation rights (PR:L), and a victim must be socially engineered into clicking an OAuth authorize button (UI:R) — so this is not remotely exploitable by an anonymous internet attacker. No EPSS score, no KEV listing, and no public PoC or scanner template currently exist, so near-term mass exploitation is unlikely; the realistic threat is a malicious insider, a compromised low-privileged account, or a supply-chain-style trick targeting an n8n admin. Exposure is elevated for organizations that grant broad credential-editing rights to non-admin users or that use n8n to orchestrate AI/LLM integrations, since a hijacked admin session can reach every OAuth2 credential configured in the instance.

How does the attack unfold?

Malicious credential creation
An authenticated low-privileged n8n user crafts an OAuth2 credential with a javascript: URL embedded in the Authorization URL field, disguised as a legitimate AI service connector.
AML.T0011.003
Social engineering of victim
The attacker persuades a higher-privileged user (e.g., an admin) to click the OAuth 'Connect'/authorize button for the crafted credential.
AML.T0052
Script execution in victim session
The javascript: URL executes in the victim's authenticated browser session, running with the victim's privileges due to the changed scope of the vulnerability.
Credential and session compromise
The attacker leverages the hijacked session to steal tokens, exfiltrate other stored AI-service OAuth2/API credentials, or modify workflows within n8n.
AML.T0055

What systems are affected?

Package Ecosystem Vulnerable Range Patched
n8n npm No patch
201.9K OpenSSF 6.7 Pushed today 51% patched ~6d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1
5.4 / 10
EPSS
0.1%
chance of exploitation in 30 days
Higher than 4% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI Required
S Changed
C Low
I Low
A None

What should I do?

1 step
  1. Upgrade all n8n instances to version 2.8.0 or later, where the OAuth2 Authorization URL field is properly sanitized against non-HTTP(S) URI schemes. Until patched, restrict credential creation and editing to trusted administrators only (least privilege), and disable self-service credential creation for standard users if your workflow allows it. Add or tighten Content-Security-Policy headers to block javascript: URI execution in the credential UI as defense in depth. Audit existing OAuth2 credentials for Authorization URL values containing 'javascript:', 'data:', or other unexpected schemes, and review admin audit logs for credential creation by unexpected or low-privileged accounts. Train users with credential-authorization rights not to click 'Connect'/authorize buttons on unfamiliar or unsolicited credential entries.

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Social Engineering Data Leakage Agent Framework AML.T0011.003 AML.T0052 AML.T0055

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.6 - AI system security
NIST AI RMF
MANAGE-4.1 - AI system incidents are monitored and responded to
OWASP LLM Top 10
LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-56359?

A stored cross-site scripting flaw in n8n's credential management lets any authenticated user embed a javascript: URL in the OAuth2 'Authorization URL' field of a crafted credential, so when another user clicks the OAuth 'Connect' button the script runs in that victim's authenticated session (CVSS 5.4, scope changed). There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so this isn't an active-exploitation emergency — but n8n carries a package risk score of 69/100 with 123 other known CVEs and an OpenSSF Scorecard of only 6.6/10, a track record worth weighing given n8n often sits at the center of AI agent workflows holding OAuth credentials for LLM and SaaS integrations. The attack only requires a low-privileged authenticated attacker plus one click from a higher-privileged user (e.g., an admin authorizing what looks like a legitimate AI service connector), making it a realistic insider or social-engineering vector rather than an internet drive-by. Upgrade to n8n 2.8.0 or later; in the interim, restrict who can create or edit credentials to trusted admins and audit existing OAuth2 credentials for Authorization URL fields containing 'javascript:' or other non-HTTP(S) schemes.

Is CVE-2026-56359 actively exploited?

No confirmed active exploitation of CVE-2026-56359 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-56359?

Upgrade all n8n instances to version 2.8.0 or later, where the OAuth2 Authorization URL field is properly sanitized against non-HTTP(S) URI schemes. Until patched, restrict credential creation and editing to trusted administrators only (least privilege), and disable self-service credential creation for standard users if your workflow allows it. Add or tighten Content-Security-Policy headers to block javascript: URI execution in the credential UI as defense in depth. Audit existing OAuth2 credentials for Authorization URL values containing 'javascript:', 'data:', or other unexpected schemes, and review admin audit logs for credential creation by unexpected or low-privileged accounts. Train users with credential-authorization rights not to click 'Connect'/authorize buttons on unfamiliar or unsolicited credential entries.

What systems are affected by CVE-2026-56359?

This vulnerability affects the following AI/ML architecture patterns: agent orchestration platforms, agent frameworks, OAuth2-based AI service integrations, credential management systems.

What is the CVSS score for CVE-2026-56359?

CVE-2026-56359 has a CVSS v3.1 base score of 5.4 (MEDIUM). The EPSS exploitation probability is 0.14%.

What is the AI security impact?

Affected AI Architectures

agent orchestration platformsagent frameworksOAuth2-based AI service integrationscredential management systems

MITRE ATLAS Techniques

AML.T0011.003 Malicious Link
AML.T0052 Phishing
AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.6
NIST AI RMF: MANAGE-4.1
OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

n8n before 2.8.0 contains a cross-site scripting vulnerability in the credential management flow where authenticated users can inject malicious JavaScript URLs into OAuth2 credential Authorization URL fields. Attackers can craft malicious credentials and trick victims into clicking the OAuth authorization button, executing arbitrary scripts in their browser session with the victim's privileges.

Exploitation Scenario

A low-privileged n8n user — a contractor, a compromised account, or a malicious insider with credential-creation rights — creates an OAuth2 credential labeled to look like a legitimate AI service integration (e.g., 'OpenAI Connector — Finance Team') but sets its Authorization URL field to a javascript: URI containing malicious script instead of a real OAuth endpoint. They then prompt a higher-privileged user, such as a workflow admin, to authorize the new integration — for example via a chat message or ticket asking them to 'approve the new AI connector.' When the admin clicks the OAuth 'Connect' button, the injected script executes inside their authenticated n8n session (scope changed, S:C), letting the attacker steal session tokens, enumerate and exfiltrate other stored OAuth2/API credentials for connected AI services, or silently modify workflows to redirect agent actions or leak data.

Weaknesses (CWE)

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
  • [Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

Timeline

Published
July 8, 2026
Last Modified
July 9, 2026
First Seen
July 8, 2026

Related Vulnerabilities