CVE-2026-56360: n8n unsigned Zendesk webhook

CISO Take

n8n's ZendeskTrigger node accepts incoming webhook POST requests without verifying the HMAC-SHA256 signature Zendesk normally attaches, so anyone who learns the webhook URL can inject fully arbitrary, unauthenticated data straight into a live workflow. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, and the CVSS attack complexity is rated high because the attacker first needs to discover the specific webhook URL — so this isn't a mass-scan threat today. The real exposure is n8n's role as an AI agent/workflow orchestrator: with 123 other CVEs already on record for this package and a mediocre OpenSSF Scorecard (6.6/10), teams running Zendesk-triggered automations that feed an LLM or agent node are effectively trusting unauthenticated input as if it were verified customer data. Patch to n8n 1.123.18 (1.x) or 2.6.2 (2.x) now; until then, treat every Zendesk webhook URL as a bearer secret — rotate it, front it with IP allowlisting to Zendesk's egress ranges, and add manual signature verification in a Function node — and audit workflow logs for ZendeskTrigger executions missing the expected signature header.

Sources: NVD GitHub Advisory vulncheck.com OpenSSF ATLAS

What is the risk?

Medium severity (CVSS 4.0, network vector, no privileges/UI required) but attack complexity is high because exploitation depends on the attacker first obtaining a specific, non-guessable webhook URL. Impact is scoped to integrity (I:L) with a changed scope (S:C), meaning a successful forgery can influence resources beyond the webhook endpoint itself — i.e., whatever the downstream workflow does with the (unverified) data. No confidentiality or availability impact directly, no active exploitation, no EPSS data, not in CISA KEV, and no public PoC or scanner signature exist yet, so near-term mass exploitation is unlikely. The risk is concentrated in orgs that have already deployed ZendeskTrigger-based automations and have let the webhook URL leak (logs, screenshots, git repos, error messages) or rely on URL obscurity as their only control.

How does the attack unfold?

Reconnaissance

Attacker discovers or guesses the organization's n8n Zendesk webhook URL via leaked logs, exposed repos, or misconfigurations.

AML.T0006

Exploitation

Attacker sends an unsigned POST request forging a Zendesk ticket event, which n8n accepts because it never verifies the HMAC-SHA256 signature.

AML.T0049

Impact

The forged data drives the triggered workflow, corrupting business logic and potentially injecting attacker-controlled content into downstream AI agent/LLM processing.

AML.T0080

Reconnaissance

Attacker discovers or guesses the organization's n8n Zendesk webhook URL via leaked logs, exposed repos, or misconfigurations.

AML.T0006

Exploitation

Attacker sends an unsigned POST request forging a Zendesk ticket event, which n8n accepts because it never verifies the HMAC-SHA256 signature.

AML.T0049

Impact

The forged data drives the triggered workflow, corrupting business logic and potentially injecting attacker-controlled content into downstream AI agent/LLM processing.

AML.T0080

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

4.0 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 8% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC High

PR None

UI None

S Changed

C None

I Low

A None

What should I do?

1 step

Upgrade n8n to 1.123.18 (1.x branch) or 2.6.2 (2.x branch), both of which restore HMAC-SHA256 signature verification for ZendeskTrigger. Until patched: rotate all existing Zendesk webhook URLs (treat them as secrets, not obscure endpoints), restrict inbound access to the webhook path via reverse-proxy IP allowlisting scoped to Zendesk's published egress ranges, and add a manual signature-verification step (Function/Code node validating the X-Zendesk-Webhook-Signature header) in front of any workflow logic. For detection, alert on ZendeskTrigger executions with a missing or mismatched signature header, and review workflow history for unexplained ticket-triggered runs. If the triggered workflow feeds an LLM/agent node, add output/action guardrails so ticket-derived text cannot directly authorize tool calls or be treated as trusted instructions.

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?

Auth Bypass Agent Plugin AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0080 - AI Agent Context Poisoning

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MANAGE-2.7 - AI system security and resilience

OWASP LLM Top 10

LLM01 - Prompt Injection

Frequently Asked Questions

What is CVE-2026-56360?

n8n's ZendeskTrigger node accepts incoming webhook POST requests without verifying the HMAC-SHA256 signature Zendesk normally attaches, so anyone who learns the webhook URL can inject fully arbitrary, unauthenticated data straight into a live workflow. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, and the CVSS attack complexity is rated high because the attacker first needs to discover the specific webhook URL — so this isn't a mass-scan threat today. The real exposure is n8n's role as an AI agent/workflow orchestrator: with 123 other CVEs already on record for this package and a mediocre OpenSSF Scorecard (6.6/10), teams running Zendesk-triggered automations that feed an LLM or agent node are effectively trusting unauthenticated input as if it were verified customer data. Patch to n8n 1.123.18 (1.x) or 2.6.2 (2.x) now; until then, treat every Zendesk webhook URL as a bearer secret — rotate it, front it with IP allowlisting to Zendesk's egress ranges, and add manual signature verification in a Function node — and audit workflow logs for ZendeskTrigger executions missing the expected signature header.

Is CVE-2026-56360 actively exploited?

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

How to fix CVE-2026-56360?

Upgrade n8n to 1.123.18 (1.x branch) or 2.6.2 (2.x branch), both of which restore HMAC-SHA256 signature verification for ZendeskTrigger. Until patched: rotate all existing Zendesk webhook URLs (treat them as secrets, not obscure endpoints), restrict inbound access to the webhook path via reverse-proxy IP allowlisting scoped to Zendesk's published egress ranges, and add a manual signature-verification step (Function/Code node validating the `X-Zendesk-Webhook-Signature` header) in front of any workflow logic. For detection, alert on ZendeskTrigger executions with a missing or mismatched signature header, and review workflow history for unexplained ticket-triggered runs. If the triggered workflow feeds an LLM/agent node, add output/action guardrails so ticket-derived text cannot directly authorize tool calls or be treated as trusted instructions.

What systems are affected by CVE-2026-56360?

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

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

CVE-2026-56360 has a CVSS v3.1 base score of 4.0 (MEDIUM). The EPSS exploitation probability is 0.19%.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation pipelines

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0080 AI Agent Context Poisoning

Compliance Controls Affected

NIST AI RMF: MANAGE-2.7

OWASP LLM Top 10: LLM01

What are the technical details?

Original Advisory

n8n before versions 1.123.18 and 2.6.2 fails to verify HMAC-SHA256 signatures on Zendesk webhooks in the ZendeskTrigger node. Attackers who know the webhook URL can send unsigned POST requests to trigger workflows with arbitrary malicious data.

Exploitation Scenario

An attacker finds an organization's n8n Zendesk webhook URL — leaked via a public GitHub repo, a misconfigured error page, or scraped logs — and crafts a POST request mimicking a legitimate 'ticket created' Zendesk event, with a fabricated ticket description containing either false business data or a prompt-injection payload. Because n8n doesn't validate the HMAC signature, it accepts the request as authentic and runs the associated workflow. If that workflow feeds ticket content into an AI agent (e.g., an auto-triage or auto-reply assistant), the injected text can steer the LLM's output or trigger unintended tool calls; even without an AI node, the forged ticket can pollute downstream systems (CRM, alerting, other integrations) with attacker-controlled data.

Weaknesses (CWE)

CWE-290 Authentication Bypass by Spoofing CWE-290 Authentication Bypass by Spoofing

CWE-290 — Authentication Bypass by Spoofing: This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

Source: MITRE CWE corpus.