CVE-2026-86080 in n8n
Summary
by MITRE • 09/09/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within n8n workflow automation platforms prior to versions 1.123.76, 2.37.7, and 2.38.2 represents a critical failure in cryptographic verification logic associated with the GitHub Trigger node. This flaw specifically impacts the mechanism by which webhooks are registered and subsequently validated upon receiving events from GitHub. The core of the issue lies in the handling of webhook secrets during the lifecycle management of existing webhooks, particularly when GitHub returns an HTTP 422 Unprocessable Entity response indicating that a webhook with identical configuration already exists. In such scenarios, rather than generating or retrieving a new secret, the system discards any newly generated webhook secret and proceeds to reuse the existing webhook identifier without ensuring the corresponding secret is retained in the node's static data storage.
This architectural oversight results in a state where the workflow retains the webhookId but lacks the necessary webhookSecret required for signature verification. Consequently, when GitHub subsequently sends event payloads to this endpoint, it includes an X-Hub-Signature-256 header calculated using its own private secret key. However, because n8n has discarded or failed to store the corresponding shared secret used during registration, the validation logic cannot perform a valid comparison. Instead of rejecting requests with invalid signatures due to missing cryptographic material, the verification process effectively accepts deliveries without verifying them against a stored secret. This creates a scenario where any actor capable of sending HTTP POST requests to the webhook endpoint can trigger workflow executions regardless of whether they possess the legitimate GitHub private key or not.
From an industry standard perspective, this vulnerability is classified under CWE-347 Improper Verification of Cryptographic Signature and CWE-209 Generation of Error Message Containing Sensitive Information if error handling exposes internal states that aid in exploitation. The lack of proper authentication for incoming webhook events aligns with the MITRE ATT&CK technique T1505.003 Server Software Component, specifically relating to Webhooks where an attacker can abuse a misconfigured component to execute arbitrary code or trigger unintended automation workflows. By bypassing signature verification, an adversary gains the ability to inject malicious payloads into the workflow execution pipeline, potentially leading to remote code execution if the subsequent nodes in the n8n workflow process untrusted input without adequate sanitization.
The operational impact of this vulnerability is severe for organizations relying on n8n for automated business processes connected to GitHub repositories. Attackers can exploit this flaw to trigger workflows repeatedly, causing denial-of-service conditions through resource exhaustion or initiating unauthorized actions such as deploying code, modifying repository settings, or exfiltrating data if the workflow integrates with other sensitive systems like databases or cloud storage services. Since n8n is often deployed in environments handling critical CI/CD pipelines and integration logic, this bypass undermines the integrity of automated operations and can serve as an initial access vector for deeper infrastructure compromise.
To mitigate this risk, organizations must immediately upgrade to patched versions 1.123.76, 2.37.7, or 2.38.2 where the GitHub Trigger logic has been corrected to properly retain webhook secrets even when reusing existing webhooks after receiving HTTP 422 responses. Until an upgrade is feasible, administrators should consider isolating n8n instances from untrusted networks and implementing network-level access controls such as IP whitelisting for incoming webhook traffic if possible. Additionally, reviewing workflow configurations to ensure that nodes processing webhook data implement strict input validation can provide a layer of defense in depth against potential exploitation attempts leveraging this signature verification bypass.