Fix n8n Wait Node Resume URL 401: Why the Signature Is Required and How to Pass It Through

Introduction

The n8n Wait node is the standard way to pause a workflow for a human decision: the workflow drafts something, sends an approval link, and resumes only when that link is called. After an upgrade, many self-hosters find that link suddenly returns 401 Unauthorized, and the approval step that worked for months stops dead. This tutorial explains why the 401 happens, how to fix it without weakening security, and which patch closes the related Send-and-Wait vulnerability. It is written for self-hosted n8n users who run approval workflows with the Wait node set to resume on a webhook call.

Quick answer

Always call the full resume URL exactly as $execution.resumeUrl generates it, including the ?signature= value. Stripping the signature returns 401 by design, and no supported setting disables it, so store and forward the complete URL.

Evidence

The behavior change is visible in the URL itself. In older n8n versions, a Wait node resume URL looked like /webhook-waiting/[Execution ID]. In current versions it looks like /webhook-waiting/[Execution ID]?signature=[HMAC hex], and calling the old bare form returns 401 Unauthorized. That report comes from an n8n community thread where users compared the two formats after upgrading, and the thread’s follow-up confirms the signature is now mandatory: there is no officially supported way to remove it, and the URL must be used complete, straight from $execution.resumeUrl.

The signature story has a second, sharper chapter. The official GitHub security advisory GHSA-728h-pmr2-7cgh documents a Send-and-Wait HMAC bypass in which the waiting-webhook endpoint accepted a Send-and-Wait node reference in two forms, decided which validation to apply before normalising the second form, and therefore accepted a request in that shape without the signature approvals require. The advisory states the impact directly: “A caller holding an execution’s resume token can release an approval intended for someone else; everything downstream then runs under the workflow owner’s credentials, which depending on the workflow can reach command execution.” The fix shipped in n8n versions 2.42.1 and 2.41.4. Two lessons follow. First, the signature is load-bearing security, not cosmetic friction, so stripping it is never the fix. Second, if you run approval workflows on an older build, patching matters as much as fixing your URLs.

Prerequisites

• A self-hosted n8n instance with at least one workflow that uses a Wait node set to resume On Webhook Call.
• Editor access to that workflow, so you can change how the resume URL is passed around.
• A way to call a URL from outside n8n, such as curl, an approval tool, or the external system that consumes the resume link.
• For the patching step, shell access to the host running n8n, or access to the deployment method you use (Docker Compose, Docker, or npm).
• The habit of treating the resume URL as a secret: it carries a token that can release a waiting execution, so it belongs in secure storage and in approval messages, never in public logs or chat transcripts.

Step-by-step guide

Step 1: Reproduce the 401 and confirm the cause

Before changing anything, prove the 401 comes from a missing signature rather than from authentication, a proxy, or a stopped workflow. Find a waiting execution in your workflow, take the resume URL your system actually called, and compare it against the URL n8n generated.

If the called URL looks like this, with no query string, you have found the cause:

curl -i "https://your-n8n.example.com/webhook-waiting/123"

A bare path like that returns 401 on current n8n versions, because the signature check runs before anything else. Now call the full URL exactly as $execution.resumeUrl produced it, keeping the entire ?signature= value:

curl -i "https://your-n8n.example.com/webhook-waiting/123?signature=0123456789abcdef..."

That call should resume the execution instead of returning 401. If the full signed URL also returns 401, the problem is elsewhere: the execution may have finished, timed out, or been replaced by a newer run (see Troubleshooting). If the full URL works and the bare URL does not, the diagnosis is settled.

Step 2: Send the resume URL from inside the same execution

The only reliable source of the resume URL is the execution that is about to wait. Add a step before the Wait node that sends $execution.resumeUrl to wherever the decision happens. A Set node works for inspection, an Email node works for human approvers, and an HTTP Request node works for an external approval system. The expression is the same in each case:

{{ $execution.resumeUrl }}

Two details matter here. First, the sending node must run in the same execution as the Wait node, because the official Wait node documentation warns that partial executions change the resume URL, so a URL captured from a test run or a different execution will not resume the execution you mean. Second, send the value as one opaque string. Do not split it into a base URL plus a token, do not URL-decode and re-encode it, and do not trim trailing characters that look like noise. The signature is hex text in a query parameter, and any transformation risks breaking it. Store the complete string on the receiving side and call it back verbatim.

Step 3: Fix every caller that rebuilds the URL by hand

The most common breakage is a caller that constructs the resume URL itself, typically by concatenating a base URL with an execution ID it stored earlier. That pattern worked on old n8n versions and fails on current ones, because the caller cannot mint a valid signature. Search your approval system, scripts, and workflow expressions for webhook-waiting and replace each hand-built URL with the stored full URL from Step 2.

If your approval system genuinely cannot receive a URL from n8n, use the proxy pattern instead of trying to forge a signature. Give your approval system a plain, stable URL owned by a regular Webhook node. When that webhook fires, a workflow step reads the stored signed resume URL for that approval and calls it with an HTTP Request node. The approval system never sees the signed URL, and the signature stays intact.

Step 4: Layer the Wait node’s own authentication on top

The signature proves the caller holds the issued URL. It does not prove who the caller is, and a forwarded approval email can leak. Open the Wait node, set Resume to On Webhook Call, and set Authentication to Basic Auth, Header Auth, or JWT Auth instead of None, choosing whichever credential type your approval system can send.

While you are in the node settings, turn on two more options. Enable Ignore Bots so link previewers and web crawlers that fetch the approval link to build a preview do not accidentally approve the draft. Enable Limit Wait Time and pick a deadline, so an approval nobody answers resumes into a branch you chose instead of waiting forever. If your approvers sit behind known addresses, add them to the IP(s) Whitelist option, noting that access from any other IP returns 403. None of these options replaces the signature, and none of them requires removing it.

Step 5: Patch the Send-and-Wait HMAC bypass

Fixing your URLs is only half the job if your n8n version predates the advisory fix. Check your running version first:

docker ps --format '{{.Names}} {{.Image}}'
n8n --version

If you are on a 2.x build older than 2.41.4, upgrade to 2.41.4 or later on your train, or to 2.42.1 or later if you already run 2.42.x. The advisory names 2.42.1 and 2.41.4 as the fixed versions. For a Docker Compose install, that means pinning the image tag, pulling, and recreating the container:

docker compose pull
docker compose up -d
docker compose logs -f n8n

Back up your database before upgrading, as our self-hosted n8n update guide describes, and verify the running version after restart. If you cannot upgrade immediately, the advisory’s temporary mitigations are to restrict instance access to fully trusted users, avoid Send-and-Wait nodes gating high-consequence actions in workflows where an earlier public trigger exposes a resume token, and restrict or disable public webhook and chat trigger endpoints that precede Send-and-Wait approval nodes. The advisory is explicit that these mitigations do not fully remediate the risk, so treat them as a short bridge to the upgrade, not as an alternative to it.

Step 6: Verify end to end with a fresh approval

Run the workflow from the start, not from a saved test execution, and watch one approval travel the whole path. Confirm the approver receives a link containing ?signature=, confirm calling it resumes the waiting execution, and confirm the downstream steps run exactly once. Then confirm the negative case: call the same URL with the signature removed and confirm it returns 401. That negative test proves your instance enforces the signature, and it doubles as a regression check after every future upgrade. For the broader picture of running n8n as a reliable platform, the complete n8n guide covers installation, scaling, and security practices that this approval pattern sits inside.

Troubleshooting

The full signed URL still returns 401

A valid signature does not help if the execution it belongs to is gone. Check whether the execution finished, timed out under Limit Wait Time, or was superseded by a newer run, and check whether you are calling a URL captured from a partial or test execution rather than from the live run. Re-run the workflow from the start, capture the fresh $execution.resumeUrl from the same execution, and call that. Also check that no proxy or redirect strips the query string: a redirect that drops ?signature= turns a valid URL into a bare one, and the 401 that follows looks identical to a stripped signature.

The approval fires before anyone reads it

An email client or chat tool fetched the link to build a preview, and the fetch itself resumed the workflow. Turn on Ignore Bots in the Wait node’s On Webhook Call options, which tells n8n to ignore requests from bots like link previewers and web crawlers. If previews still trigger the resume, add Authentication to the Wait node so a bare GET from a previewer cannot satisfy the call.

The approval link works once, then stops working after an edit

Editing a workflow and running a partial execution changes the resume URL, as the official documentation warns. A link sent from an earlier run belongs to that earlier run and cannot resume the new one. Always send the resume URL from a node in the same execution as the Wait node, after your final edit, and re-send the link whenever the workflow is re-run. If your approval system caches links across runs, key the cache by execution so a stale link is never presented as current.

An approval was released by the wrong person

On unpatched builds, this is the GHSA-728h-pmr2-7cgh scenario: a caller holding an execution’s resume token could release an approval intended for someone else, because one request shape skipped the signature check. Upgrade to 2.41.4 or 2.42.1 or later immediately, rotate any approval links issued while unpatched, and review the executions that resumed during the exposure window for downstream actions taken under the workflow owner’s credentials. Going forward, combine the signature with Wait node Authentication and treat every resume URL as a secret.

Callers outside a known network get 403 instead of 401

That is the IP(s) Whitelist option doing its job: access from IPs outside the list returns 403. If legitimate approvers travel or sit behind a changing egress address, either widen the whitelist to their current range or remove the whitelist and rely on the signature plus Authentication instead. A 403 means the request reached n8n and was blocked by your own rule, while a 401 means the signature check failed, so the two codes point at different fixes.

FAQ

Why does my n8n Wait node resume URL return 401?

Because the resume URL is missing its signature. Current n8n versions append a ?signature= HMAC token to every Wait node resume URL, and the bare /webhook-waiting/[execution ID] path without it is rejected with 401. Call the complete URL exactly as $execution.resumeUrl generates it.

Can I turn off the Wait node resume URL signature?

No, there is no supported setting that disables it. The signature is part of the mandatory security mechanism for the Wait node. The supported fix is to forward the full signed URL, not to remove the signature.

Where do I get the correct resume URL for a Wait node?

Use the $execution.resumeUrl variable in a node that runs in the same execution before the Wait node, such as a Set node, an Email node, or an HTTP Request node. The URL is generated at runtime and is unique to each execution, so never hardcode it or copy it from an earlier run.

Does the signature replace the Wait node’s Authentication setting?

No, the two controls are independent. The signature proves the caller holds the exact URL n8n issued for that execution, while Authentication (Basic Auth, Header Auth, or JWT Auth) adds caller-side credentials on top. Use both when the resume call crosses an untrusted channel.

Which n8n versions fix the Send-and-Wait HMAC bypass?

Versions 2.42.1 and 2.41.4, according to advisory GHSA-728h-pmr2-7cgh. If you run an older 2.x build, upgrade to one of those versions or later. The advisory’s temporary mitigations, such as restricting instance access to fully trusted users, do not fully remediate the issue.

My approval system builds the resume URL itself. What should I change?

Stop building it. Have n8n send the full $execution.resumeUrl to your approval system and store that exact string, or put a regular Webhook node in front: your system calls the plain webhook, and a workflow step calls the stored signed resume URL internally.

Conclusion

The 401 on a Wait node resume URL is not a bug to work around, it is the signature check working as designed after n8n closed a real hole in predictable execution IDs. Keep the full $execution.resumeUrl intact from the execution that generates it to the caller that resumes it, layer the Wait node’s own authentication and bot protection on top, and patch to 2.41.4 or 2.42.1 or later to close the Send-and-Wait HMAC bypass.

Frequently asked questions