GHSA-xwx6-jjhv-84p8: n8n prototype pollution causes

Q: Is GHSA-xwx6-jjhv-84p8 actively exploited?

No confirmed active exploitation of GHSA-xwx6-jjhv-84p8 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-xwx6-jjhv-84p8?

Patch: upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 or later — this is the only full remediation. Interim workaround if patching isn't immediate: restrict instance access to fully trusted users only, and disable or tightly scope workflow creation/execution permissions for any user who isn't fully trusted, since the exploit requires the ability to define a workflow's Edit Fields (Set) node output field name. Detection: monitor for a sudden, instance-wide spike in HTTP 500 errors on the n8n process (a signature of the shared global corruption) and restart the process promptly to restore availability — treat repeated or clustered 500-error spikes as a possible active-exploitation indicator warranting a workflow audit. Longer term: review who has workflow-authoring rights in n8n and apply least-privilege to workflow creation/editing, especially in instances that expose n8n to less-trusted internal users or partners.

Q: What systems are affected by GHSA-xwx6-jjhv-84p8?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration pipelines.

Q: What is the CVSS score for GHSA-xwx6-jjhv-84p8?

No CVSS score has been assigned yet.

CISO Take

A vulnerability in n8n's Edit Fields (Set) node lets any authenticated user assign an output field name matching an inherited built-in method path, corrupting a global object shared across the entire Node.js process and used on the authentication code path — the result is an instance-wide denial of service that locks out every user until an operator manually restarts the process. There's no CVSS score or EPSS data published yet, it isn't in CISA KEV, and no public exploit code or Nuclei template exists, but the bug requires only workflow-creation privileges (no admin access) to trigger, and n8n's own package risk profile is already elevated — an OpenSSF Scorecard of 6.6/10 and 166 other CVEs recorded against the package. Because n8n sits at the center of many AI agent automation pipelines with 16 tracked downstream dependents, a single malicious or careless workflow author can take down authentication for an entire self-hosted instance, disrupting every automated agent workflow that depends on it. Upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 immediately; until then, restrict workflow creation/execution to fully trusted users and monitor for a sudden spike in process-wide HTTP 500s as an indicator of exploitation, restarting the process promptly if it occurs.

Sources: GitHub Advisory OpenSSF ATLAS

What is the risk?

High severity given the vendor rating, though exploitability is bounded by the need for an authenticated account with workflow creation/execution rights — this is not an unauthenticated, internet-facing bug. Impact is severe: because the corrupted global sits on the authentication path, exploitation denies service to ALL users of the instance, not just the attacker's own session, and requires a manual process restart to recover (no automatic self-healing). No EPSS score, CISA KEV listing, public exploit, or Nuclei template exists, so opportunistic mass-exploitation risk is currently low — but the underlying flaw (CWE-1321 prototype pollution via an unrestricted dot-notation field setter) is a well-understood JS vulnerability class that's trivial to weaponize once workflow access is obtained, and n8n's high CVE count (166 other CVEs in-package) and mediocre OpenSSF Scorecard (6.6/10) suggest a broader pattern of insufficient input hardening. Overall: high-impact, low-to-moderate likelihood today, with likelihood rising sharply for any multi-tenant or low-trust n8n deployment (shared instances, contractor/partner access, self-service automation platforms).

How does the attack unfold?

Initial Access

Attacker holds or obtains an authenticated n8n account with workflow creation/execution privileges (e.g., a contractor or low-trust internal user).

AML.T0012

Exploitation

Attacker builds a workflow using the Edit Fields (Set) node and names an output field after a dot-notation path that resolves to an inherited built-in method, triggering prototype pollution on a shared global.

AML.T0053

Impact

The corrupted global is used on the request-authentication path, so every subsequent authenticated request fails instance-wide until an operator manually restarts the n8n process.

AML.T0029

Initial Access

Attacker holds or obtains an authenticated n8n account with workflow creation/execution privileges (e.g., a contractor or low-trust internal user).

AML.T0012

Exploitation

Attacker builds a workflow using the Edit Fields (Set) node and names an output field after a dot-notation path that resolves to an inherited built-in method, triggering prototype pollution on a shared global.

AML.T0053

Impact

The corrupted global is used on the request-authentication path, so every subsequent authenticated request fails instance-wide until an operator manually restarts the n8n process.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.67	`1.123.67`
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d 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

Moderate

What should I do?

1 step

Patch: upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 or later — this is the only full remediation. Interim workaround if patching isn't immediate: restrict instance access to fully trusted users only, and disable or tightly scope workflow creation/execution permissions for any user who isn't fully trusted, since the exploit requires the ability to define a workflow's Edit Fields (Set) node output field name. Detection: monitor for a sudden, instance-wide spike in HTTP 500 errors on the n8n process (a signature of the shared global corruption) and restart the process promptly to restore availability — treat repeated or clustered 500-error spikes as a possible active-exploitation indicator warranting a workflow audit. Longer term: review who has workflow-authoring rights in n8n and apply least-privilege to workflow creation/editing, especially in instances that expose n8n to less-trusted internal users or partners.

How is it classified?

DoS Agent Framework AML.T0029 - Denial of AI Service AML.T0053 - AI Agent Tool Invocation

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 operation and monitoring

NIST AI RMF

MEASURE 2.6 - AI system security and resilience is evaluated and documented

OWASP LLM Top 10

LLM04 - Model Denial of Service

Frequently Asked Questions

What is GHSA-xwx6-jjhv-84p8?

A vulnerability in n8n's Edit Fields (Set) node lets any authenticated user assign an output field name matching an inherited built-in method path, corrupting a global object shared across the entire Node.js process and used on the authentication code path — the result is an instance-wide denial of service that locks out every user until an operator manually restarts the process. There's no CVSS score or EPSS data published yet, it isn't in CISA KEV, and no public exploit code or Nuclei template exists, but the bug requires only workflow-creation privileges (no admin access) to trigger, and n8n's own package risk profile is already elevated — an OpenSSF Scorecard of 6.6/10 and 166 other CVEs recorded against the package. Because n8n sits at the center of many AI agent automation pipelines with 16 tracked downstream dependents, a single malicious or careless workflow author can take down authentication for an entire self-hosted instance, disrupting every automated agent workflow that depends on it. Upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 immediately; until then, restrict workflow creation/execution to fully trusted users and monitor for a sudden spike in process-wide HTTP 500s as an indicator of exploitation, restarting the process promptly if it occurs.

Is GHSA-xwx6-jjhv-84p8 actively exploited?

No confirmed active exploitation of GHSA-xwx6-jjhv-84p8 has been reported, but organizations should still patch proactively.

How to fix GHSA-xwx6-jjhv-84p8?

Patch: upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 or later — this is the only full remediation. Interim workaround if patching isn't immediate: restrict instance access to fully trusted users only, and disable or tightly scope workflow creation/execution permissions for any user who isn't fully trusted, since the exploit requires the ability to define a workflow's Edit Fields (Set) node output field name. Detection: monitor for a sudden, instance-wide spike in HTTP 500 errors on the n8n process (a signature of the shared global corruption) and restart the process promptly to restore availability — treat repeated or clustered 500-error spikes as a possible active-exploitation indicator warranting a workflow audit. Longer term: review who has workflow-authoring rights in n8n and apply least-privilege to workflow creation/editing, especially in instances that expose n8n to less-trusted internal users or partners.

What systems are affected by GHSA-xwx6-jjhv-84p8?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration pipelines.

What is the CVSS score for GHSA-xwx6-jjhv-84p8?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration pipelines

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.6

OWASP LLM Top 10: LLM04

What are the technical details?

Original Advisory

## Impact The Edit Fields (Set) node assigned output fields through a dot-notation path setter without restricting the field name, so an authenticated user could name a field after an inherited built-in method path and corrupt a shared global in the main Node.js process. Because that global was used on the request-authentication path, the instance then failed every authenticated request, causing a instance-wide denial of service for all users until the process was restarted. ## Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. ## Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict n8n instance access to fully trusted users only. - Disable or restrict workflow creation and execution permissions for untrusted users. - Monitor for unexpected process-wide HTTP 500 errors and restart the process promptly if they occur. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Exploitation Scenario

An organization runs a shared, self-hosted n8n instance where several teams — including less-trusted contractors — are allowed to build their own automation workflows that call internal APIs and LLM services. A malicious or simply careless contractor builds a workflow using the Edit Fields (Set) node and names an output field after a path that resolves to an inherited built-in method on the shared global object (a classic JS prototype-pollution vector), then runs or saves the workflow. The corrupted global — which n8n's authentication middleware relies on — now breaks for every subsequent request, so every user's authenticated call (including admins, other teams' scheduled agent workflows, and webhook-triggered automations) starts failing with HTTP 500 errors platform-wide. The instance stays down until an operator notices the failure pattern and manually restarts the n8n process, during which time all AI-agent automations dependent on that instance are unavailable — a low-effort, high-blast-radius denial of service that doesn't require any special AI/ML knowledge, just the ability to author a workflow.

Weaknesses (CWE)

CWE-1321 Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') Primary

CWE-1321 — Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'): The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.

[Implementation] By freezing the object prototype first (for example, Object.freeze(Object.prototype)), modification of the prototype becomes impossible.
[Architecture and Design] By blocking modifications of attributes that resolve to object prototype, such as proto or prototype, this weakness can be mitigated.

Source: MITRE CWE corpus.