n8n GitHub Trigger Webhook Signature Fail-Open via 422 Hook Reuse
First seen Sep 13, 2026 · Updated Sep 13, 2026
A logic flaw in n8n's GitHub Trigger node causes webhook signature verification to silently fail-open when a workflow reuses an existing GitHub webhook (triggered by a 422 'already exists' response). Instead of discarding the signing secret, the node should have re-fetched and reapplied it, but it kept only the hook id and events, leaving the endpoint able to accept unsigned or forged requests from anyone. This affects automation workflows that use GitHub events to trigger downstream agentic or automated actions, allowing unauthenticated actors to inject fake events into the pipeline.
Technical Analysis
The GitHub Trigger node normally generates an HMAC signing secret and validates the `X-Hub-Signature-256` header on every webhook delivery. When registering the hook returns HTTP 422 (webhook already exists for that URL), the node adopts the existing remote hook's id and event list but does not retrieve or reapply the associated secret, leaving the workflow's stored secret empty. Because verification logic does not fail closed when no secret is present, any HTTP request to the webhook URL is accepted regardless of signature, effectively disabling authentication on that trigger. This creates an entry point for attackers to submit spoofed GitHub event payloads directly into an n8n workflow, potentially triggering downstream agent actions, code execution steps, or data exfiltration paths that assume GitHub-authenticated input. The flaw crosses a trust boundary between the external webhook source and the internal workflow engine, since the workflow logic implicitly trusts any accepted payload as genuine GitHub-originated data.
Affected Systems
n8n
Detection Signatures
- Workflow static data containing a webhookId field with no corresponding webhookSecret value
- Webhook endpoint accepting requests without X-Hub-Signature-256 header or with invalid/missing signature yet still processing
- Logs showing 422 response from GitHub webhook creation API followed by workflow activation without secret re-fetch
- Unexpected or high-volume unauthenticated POSTs to n8n GitHub Trigger webhook URLs from non-GitHub IP ranges
Remediation Steps
- 1
Upgrade n8n
Update to n8n 1.123.76, 2.37.7, 2.38.2, or later where the signature verification fail-closed fix is applied.
- 2
Delete and reactivate affected webhooks
Delete the existing GitHub webhook remotely first, then deactivate/reactivate the GitHub Trigger workflow so n8n registers a fresh hook with a new secret rather than hitting the 422 reuse path.
- 3
Audit workflow static data
Scan stored workflow data for entries with a webhookId but no webhookSecret and treat them as unprotected until confirmed remediated.
- 4
Restrict network access
Limit inbound access to n8n webhook endpoints to GitHub's published IP address ranges as a compensating control.
- 5
Monitor webhook traffic
Add logging/alerting for webhook deliveries lacking valid signatures to detect exploitation attempts even after patching.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.