The n8n Send-and-Wait Vulnerability: What the Advisory Says
What the n8n send-and-wait vulnerability advisory (GHSA-728h-pmr2-7cgh) says: affected versions, the official fix, and workarounds.
Checked against the cited sources on .
What the n8n Send-and-wait Vulnerability Is
A GitHub security advisory published on September 30, 2026 describes an n8n send-and-wait vulnerability affecting the waiting-webhook endpoint that approval workflows rely on. According to the advisory, identified as GHSA-728h-pmr2-7cgh, the endpoint accepted a second Send-and-Wait node-reference format without the signature checks that approvals normally require, because the system chose which validation to apply before normalising that format.
The advisory describes this specifically as a flaw in how Send-and-Wait resume requests are validated. We refer to it here as an n8n waiting execution approval bypass as a descriptive shorthand of our own, not a phrase the advisory itself uses, and the advisory frames the issue narrowly rather than as a broader category of authentication problem.
Which n8n Versions Are Affected
The advisory lists affected versions as n8n releases below 2.42.1 and below 2.41.4 — in other words, 2.41.x builds before 2.41.4 and 2.42.x builds before 2.42.1. If your instance runs on either of those lines without the later patch, the advisory's description applies to you.
| Version line | Status per the advisory |
|---|---|
| 2.41.x before 2.41.4 | Affected |
| 2.42.x before 2.42.1 | Affected |
| 2.41.4 or later | Fixed |
| 2.42.1 or later | Fixed |
n8n states the issue was fixed in versions 2.42.1 and 2.41.4, and its own instruction is to upgrade to one of these versions or later. The advisory does not state whether earlier major or minor lines share the same flaw, so that question stays outside what is confirmed here.
Severity and the n8n HMAC Bypass Risk
The advisory treats this as an authorization bypass on the waiting-webhook endpoint, where someone other than the intended approver can resolve a pending Send-and-Wait step. It also states that once that happens, everything downstream runs under the workflow owner's credentials, which depending on the workflow can reach command execution. That combination means this n8n send-and-wait vulnerability can carry consequences well beyond the approval step itself.
We think that reach matters for triage: this n8n HMAC bypass is most consequential in workflows where the approval gate protects something costly, like releasing a payment or granting access, and less urgent in a low-stakes internal notification.
n8n's own blog post on its vulnerability disclosure practice offers general context on why timing matters once a fix is public, though it predates this specific advisory and isn't written about this case.
n8n's Send-and-wait Security Fix and Workarounds
n8n's primary remediation is the version upgrade already named: 2.42.1, 2.41.4, or later. In our view, that upgrade is the only step that actually closes this n8n send-and-wait security fix gap, and it's worth treating as the first item on the list rather than folding it into routine maintenance.
The advisory also names three temporary measures for teams that cannot upgrade right away, but it is explicit that they are short-term only and do not fully remediate the underlying risk, so they function as a bridge rather than a substitute for patching.
What the Advisory Doesn't Say
The advisory does not break down impact by n8n edition or hosting plan — it gives only package version cutoffs, not separate statements about Cloud, Enterprise, or Community instances. If your team needs to know whether your specific plan required separate action for this n8n send-and-wait vulnerability, that question sits outside what the announcement states, and n8n support or your account team is the right place to ask.
The advisory also assigns no CVE identifier, listing GHSA-728h-pmr2-7cgh as its only reference, and it does not describe an upgrade procedure, expected downtime, or confirm whether Cloud instances update automatically.
Sources: Send-and-Wait HMAC Bypass Allows Unauthenticated Approval of Waiting Executions · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
Background: How Send-and-Wait Resume Tokens and Approvals Work
n8n's Wait node documentation explains that the node provides a resumeUrl variable, so a workflow can hand out a unique link that continues the execution later when someone clicks it or submits a response. Send-and-Wait nodes across channels such as Slack, Telegram, and Discord build approval steps on top of that mechanism, pairing the resume link with a signature meant to confirm the response came from the intended approver.
A changelog entry from n8n's July 2026 release, version 2.30, notes that every Send-and-Wait node across these channels gained a timestamp recording when an approval response arrived — a feature unrelated to this advisory. It's mentioned here only as background on how actively this node family is maintained, not as something that touches the HMAC bypass itself.
Sources: Wait | Nodes | n8n Docs, Changelog | n8n Docs
Editorial Next Steps for Teams Running n8n
Beyond the advisory's own instructions, here are steps we'd suggest for a team running n8n in production — editorial advice, not something the advisory itself tells you to do.
- Inventory every workflow that places a Send-and-Wait approval node after a public Webhook, Form, or Chat trigger
- Ask n8n support whether action is needed for your specific deployment
- Consider subscribing to n8n's security advisory notifications so future fixes aren't missed
We're optimistic that teams who already treat Send-and-Wait as a production-grade approval mechanism, rather than a demo convenience, will find this upgrade straightforward to prioritize once it's on their radar.
