Topic starter
02/08/2026 12:02 pm
TL;DR: n8n’s StripeTrigger node lets anyone who knows the webhook URL forge Stripe events without the signing secret, because the handler checks only the JSON type field and never verifies the Stripe-Signature header, according to Gecko Security. That turns public webhook endpoints into business-logic abuse paths, not mere transport endpoints.
Editorial analysis by NHI Mgmt Group, based on content published by Gecko Security: “CVE-2026-21894: n8n Missing Stripe-Signature Verification Allows Forged Webhooks”.
Key questions
Q: What breaks when a webhook accepts events without verifying the sender?
A: The application loses the ability to distinguish legitimate provider events from attacker-generated input.
Q: Why do unauthenticated webhook endpoints create business-logic risk?
A: Because the workflow treats the event as trusted input before proving who sent it.
Q: What are the signs that webhook authenticity checks are failing?
A: Common signs include successful executions from unexpected sources, accepted requests with missing or forged signature headers, and workflows that process events even when the provider secret was never used.
Practitioner guidance
- Enforce cryptographic webhook verification Require provider signature or HMAC checks on the raw request body before any workflow logic runs, and reject requests that lack a valid signature.
- Inventory public automation endpoints List every externally reachable webhook, the event types it accepts, and the state-changing actions it can trigger so that trust boundaries are explicit.
- Remove trust from payload fields Treat JSON fields such as type as routing hints only, never as proof of origin, and block workflows that rely on payload shape to establish authenticity.
Bottom line: Webhook authenticity failures are governance failures, because they let untrusted requests act as though they came from a legitimate provider.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:08 pm
Webhook authenticity is an access-control problem, not a transport problem. Once a public automation endpoint accepts unverified event data, the workflow has already crossed the trust boundary. That means the real control question is whether the sender is cryptographically bound to the event, not whether the request arrived over HTTPS. Practitioners should treat webhook verification as part of access governance, especially where the event can trigger financial or account-state changes.
A question worth separating out:
Q: Should teams verify webhook authenticity before or after workflow routing?
A: Before routing, if the workflow can change state or trigger external actions. Routing may use the event type to decide where a message goes, but it should never be used to decide whether the sender is legitimate. Authenticity must be established first, otherwise every downstream step inherits false trust.
👉 Read our full editorial: n8n StripeTrigger bypass shows webhook trust is the real risk