CVE-2026-86080: n8n GitHub webhook signature bypass

Q: Is CVE-2026-86080 actively exploited?

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

Q: How to fix CVE-2026-86080?

1) Patch n8n to 1.123.76, 2.37.7, or 2.38.2 immediately — this is the only complete fix. 2) Before patching, inventory all GitHub Trigger nodes and inspect workflow static data for entries with webhookId set but no webhookSecret (accessible via n8n's internal workflow data or API). 3) For any affected workflow, deactivate and reactivate (or delete/recreate) the GitHub Trigger node to force a fresh webhook + secret pair. 4) After patching, verify GitHub webhook deliveries show a validated signature in n8n execution logs and that no executions succeeded without one during the exposure window. 5) As defense-in-depth, restrict inbound access to n8n webhook endpoints via IP allowlisting or a reverse-proxy WAF rule matching GitHub's published webhook IP ranges. 6) Review execution history for any GitHub-triggered workflow for anomalous trigger timestamps or payloads inconsistent with actual repo activity.

Q: What systems are affected by CVE-2026-86080?

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

Q: What is the CVSS score for CVE-2026-86080?

No CVSS score has been assigned yet.

CISO Take

When n8n's GitHub Trigger node hits an HTTP 422 during webhook setup and falls back to reusing an existing GitHub webhook, it discards the newly generated secret while keeping the webhook active — so the stored workflow state ends up with a webhookId but no webhookSecret. Because the X-Hub-Signature-256 verification code accepts deliveries when no secret is stored, anyone who can reach the exposed webhook URL can forge GitHub webhook payloads and trigger the downstream n8n workflow without any valid signature. There's no CVSS score, no EPSS data, and no CISA KEV listing yet, so exploitation likelihood is unquantified, but the trigger condition (an existing webhook plus a 422 response) is realistic in normal operation, not an edge case requiring attacker setup. n8n is widely used to wire AI agents and automation pipelines to external triggers, so a forged GitHub event could kick off an agentic workflow with attacker-controlled payload data feeding into it. Upgrade immediately to n8n 1.123.76, 2.37.7, or 2.38.2, and in the interim audit existing GitHub Trigger nodes for workflows whose static data shows a webhookId without a corresponding secret, then delete and recreate the webhook to force secret regeneration.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Moderate-to-high exposure despite the absence of a CVSS score: the flaw is an authentication/integrity bypass (CWE-347, improper signature verification) on a network-reachable webhook endpoint, requiring no user interaction and no credentials from the attacker — only knowledge of the webhook URL, which is often discoverable or guessable given predictable n8n URL patterns. There is no public exploit or Nuclei template yet, which lowers near-term mass-exploitation risk, but the bug is now publicly documented with the vulnerable code path named (`GithubTriggerHelpers.ts`), which shortens the time to a working PoC. The real severity driver is what the triggered workflow does downstream — in n8n's common use as an AI agent orchestrator, an unauthenticated trigger can cascade into unauthorized tool invocations, data writes, or notifications.

How does the attack unfold?

Discovery

Attacker locates an internet-facing n8n instance and its GitHub Trigger webhook URL, a commonly predictable path.

AML.T0006

Signature bypass

Attacker sends a forged GitHub event payload without a valid X-Hub-Signature-256 header; n8n accepts it because no webhook secret was stored after the 422 reuse path.

AML.T0049

Workflow execution

The forged event triggers the n8n workflow, which may pass attacker-controlled commit/PR content into an LLM or agent step as if it were trusted GitHub data.

AML.T0053

Impact

The AI agent acts on the injected content, potentially invoking tools, posting comments, or triggering downstream automation under attacker influence.

Discovery

Attacker locates an internet-facing n8n instance and its GitHub Trigger webhook URL, a commonly predictable path.

AML.T0006

Signature bypass

Attacker sends a forged GitHub event payload without a valid X-Hub-Signature-256 header; n8n accepts it because no webhook secret was stored after the 422 reuse path.

AML.T0049

Workflow execution

The forged event triggers the n8n workflow, which may pass attacker-controlled commit/PR content into an LLM or agent step as if it were trusted GitHub data.

AML.T0053

Impact

The AI agent acts on the injected content, potentially invoking tools, posting comments, or triggering downstream automation under attacker influence.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.76	`1.123.76`
204.1K OpenSSF 6.6 16 dependents Pushed 7d 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

0.2%

chance of exploitation in 30 days

Higher than 5% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Patch n8n to 1.123.76, 2.37.7, or 2.38.2 immediately — this is the only complete fix. 2) Before patching, inventory all GitHub Trigger nodes and inspect workflow static data for entries with webhookId set but no webhookSecret (accessible via n8n's internal workflow data or API). 3) For any affected workflow, deactivate and reactivate (or delete/recreate) the GitHub Trigger node to force a fresh webhook + secret pair. 4) After patching, verify GitHub webhook deliveries show a validated signature in n8n execution logs and that no executions succeeded without one during the exposure window. 5) As defense-in-depth, restrict inbound access to n8n webhook endpoints via IP allowlisting or a reverse-proxy WAF rule matching GitHub's published webhook IP ranges. 6) Review execution history for any GitHub-triggered workflow for anomalous trigger timestamps or payloads inconsistent with actual repo activity.

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 Code Execution Agent Plugin AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.2 - Data acquisition and quality for AI systems

NIST AI RMF

GOVERN-1.5 / MANAGE-4.1 - Third-party and integration risk management

OWASP LLM Top 10

LLM01 - Prompt Injection

Frequently Asked Questions

What is CVE-2026-86080?

When n8n's GitHub Trigger node hits an HTTP 422 during webhook setup and falls back to reusing an existing GitHub webhook, it discards the newly generated secret while keeping the webhook active — so the stored workflow state ends up with a webhookId but no webhookSecret. Because the X-Hub-Signature-256 verification code accepts deliveries when no secret is stored, anyone who can reach the exposed webhook URL can forge GitHub webhook payloads and trigger the downstream n8n workflow without any valid signature. There's no CVSS score, no EPSS data, and no CISA KEV listing yet, so exploitation likelihood is unquantified, but the trigger condition (an existing webhook plus a 422 response) is realistic in normal operation, not an edge case requiring attacker setup. n8n is widely used to wire AI agents and automation pipelines to external triggers, so a forged GitHub event could kick off an agentic workflow with attacker-controlled payload data feeding into it. Upgrade immediately to n8n 1.123.76, 2.37.7, or 2.38.2, and in the interim audit existing GitHub Trigger nodes for workflows whose static data shows a webhookId without a corresponding secret, then delete and recreate the webhook to force secret regeneration.

Is CVE-2026-86080 actively exploited?

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

How to fix CVE-2026-86080?

1) Patch n8n to 1.123.76, 2.37.7, or 2.38.2 immediately — this is the only complete fix. 2) Before patching, inventory all GitHub Trigger nodes and inspect workflow static data for entries with webhookId set but no webhookSecret (accessible via n8n's internal workflow data or API). 3) For any affected workflow, deactivate and reactivate (or delete/recreate) the GitHub Trigger node to force a fresh webhook + secret pair. 4) After patching, verify GitHub webhook deliveries show a validated signature in n8n execution logs and that no executions succeeded without one during the exposure window. 5) As defense-in-depth, restrict inbound access to n8n webhook endpoints via IP allowlisting or a reverse-proxy WAF rule matching GitHub's published webhook IP ranges. 6) Review execution history for any GitHub-triggered workflow for anomalous trigger timestamps or payloads inconsistent with actual repo activity.

What systems are affected by CVE-2026-86080?

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

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration pipelines

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

ISO 42001: A.6.2.2

NIST AI RMF: GOVERN-1.5 / MANAGE-4.1

OWASP LLM Top 10: LLM01

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to 1.123.76, 2.37.7, and 2.38.2, the GitHub Trigger generated a webhook secret but discarded it when GitHub returned HTTP 422 and the node reused an existing webhook. Workflow static data then retained webhookId without webhookSecret, and X-Hub-Signature-256 verification accepted deliveries without a stored secret. The affected logic includes packages/nodes-base/nodes/Github/GithubTriggerHelpers.ts and the 422 webhook reuse path. This issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2.

Exploitation Scenario

An attacker identifies an n8n instance (many are internet-facing on default ports/paths) running a GitHub Trigger workflow that previously hit the 422-reuse condition — detectable by scanning for the predictable n8n webhook URL pattern and probing whether forged payloads without a valid HMAC signature are accepted. The attacker crafts a fake GitHub 'push' or 'pull_request' JSON payload naming a file or commit message containing malicious instructions, and POSTs it to the webhook URL with no or an arbitrary X-Hub-Signature-256 header. Because the stored secret is missing, n8n's verification logic accepts the delivery as legitimate and executes the workflow. If the workflow feeds commit/PR content into an LLM node (e.g., 'summarize this PR' or 'auto-triage this issue'), the attacker's forged text becomes untrusted input treated as trusted context — enabling indirect prompt injection that can steer the agent into unintended tool calls, data exfiltration, or unauthorized actions if the agent has write-access tools (e.g., posting comments, triggering deploys, sending Slack/email).

Weaknesses (CWE)

CWE-347 Improper Verification of Cryptographic Signature Primary CWE-347 Improper Verification of Cryptographic Signature Primary CWE-347 Improper Verification of Cryptographic Signature

CWE-347 — Improper Verification of Cryptographic Signature: The product does not verify, or incorrectly verifies, the cryptographic signature for data.

Source: MITRE CWE corpus.