n8n StripeTrigger bypass shows webhook trust is the real risk

At a glance

What this is: Gecko Security says n8n’s StripeTrigger webhook can be forged by any client that knows the URL, because signature verification is missing and matching event types are enough to trigger execution.

Why it matters: This matters because webhook authenticity is a governance control, and unauthenticated event ingestion can drive payment fraud, subscription abuse, and downstream business-logic compromise.

Context

A webhook is a public HTTP endpoint that accepts event data and passes it into automation. If the endpoint does not verify the sender’s signature or HMAC, the workflow is trusting attacker-controlled input, not the provider that was supposed to sign it. In this case, the security problem is not transport exposure alone, but broken event authenticity at the point where business logic begins.

For IAM and NHI teams, this is the same governance pattern seen when machine-to-machine trust is assumed from possession of an address or token handle rather than from cryptographic verification. The identity question is not who can reach the endpoint, but whether the incoming event is actually bound to the claimed source. That is why webhook verification belongs in access governance, not only in application code review.

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. That lets forged payloads trigger the same downstream actions as genuine events, which can distort payments, entitlements, notifications, and records. The result is not just bad data. It is unauthorised business logic execution through a trusted automation path.

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. If the endpoint can trigger billing, provisioning, or notifications, an attacker can abuse that trust to force legitimate systems to carry out unauthorized actions. The risk is not just bad data, but bad data with authority.

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. If the platform accepts the message after parsing only the JSON shape, authenticity is not being enforced.

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.

Technical breakdown

Why matching event types are not enough

StripeTrigger accepts the incoming JSON, checks whether the type field matches a configured event type, and then forwards the whole body into the workflow. That is a weak authenticity test because event type is data, not proof of origin. An attacker can copy a legitimate schema, set the same type, and still control every other field. In secure webhook handling, the application must validate the message source before any business decision is made, because the payload itself is not trustworthy until the signature is checked.

Practical implication: Treat event type filtering as routing, not authentication, and require cryptographic sender verification before the workflow executes.

How webhook signature verification works

A secure webhook flow stores the provider secret, computes or verifies an HMAC over the raw request body, and compares it with the signature header before accepting the event. The raw body matters because even a small serialization change can invalidate the signature. n8n’s StripeTrigger, as described in the advisory, stores the secret but never uses it during webhook processing. That means the control exists administratively but not operationally, which is a classic governance failure: a credential is present, but the trust check is absent.

Practical implication: Verify that every webhook trigger uses the raw body plus a provider signature header, not a post-parse JSON check.

Why public automation endpoints become business-logic attack surfaces

Once an unverified event reaches the workflow, the downstream steps inherit false authority. In automation platforms, those steps often include database writes, outbound requests, notifications, or account-state changes. That is why webhook abuse is not limited to one node or one integration. It creates a trust boundary collapse, where the endpoint is public but the workflow behaves as though the input were authenticated. In identity terms, the event has been granted implicit machine identity without proof, which is exactly the control gap attackers exploit.

Practical implication: Map each public webhook to the privileged actions it can trigger, and block any workflow that acts on unauthenticated event data.

Threat narrative

Attacker objective: The attacker’s objective is to make n8n execute privileged automation as if a legitimate Stripe event had occurred.

1. Entry occurs when an attacker discovers or guesses the public n8n StripeTrigger webhook URL and sends an HTTP POST to the exposed endpoint.
2. Credential abuse is unnecessary because the node never validates the Stripe-Signature header or the stored webhook secret, so forged JSON is accepted as legitimate.
3. Impact follows when the workflow executes on attacker-controlled event data, enabling payment forgery, subscription manipulation, or other downstream business-logic abuse.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Unverified webhooks create a machine-identity trust gap. The receiving system is effectively assigning authority to an event source it has not authenticated. In NHI terms, that is equivalent to accepting a service account or API call without validating the credential that should establish its identity. The governance failure is not just missing code, but a broken assumption that public reachability implies legitimate origin. Teams should align webhook handling with the same discipline they apply to service-to-service trust.

Signature checks must be present at the point of decision, not deferred to downstream logic. Parsing the JSON and matching an event type only proves that the payload is shaped correctly, not that it came from the provider. This is a concrete example of control drift, where a security design exists in documentation but not in the execution path. Practitioners should assume any workflow that acts before signature validation can be coerced into business-logic abuse.

Named concept: webhook trust collapse. This pattern occurs when a public endpoint converts unverified inbound data into trusted automation output. It is especially dangerous in platforms that fan out to payments, customer account changes, and notifications. The practical conclusion is simple: if a webhook can change state, its authenticity check must be mandatory, testable, and tied to the exact raw request that arrived.

What this signals

Webhook trust collapse: public automation endpoints become dangerous when they transform unauthenticated requests into trusted business actions. The control has to sit at the point of ingestion, because every downstream node inherits the origin claim made by the webhook handler.

For identity and security teams, this is a useful reminder that service-to-service trust is not just about secrets being stored, but about whether those secrets are actually checked in the request path. If the application stores a webhook secret and never uses it, the governance model is present on paper and absent in execution.

For practitioners

• 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.
• Test webhook rejection paths Send forged requests, missing signatures, and invalid HMACs to confirm the platform rejects them before execution and logs the denial consistently.
• Limit webhook-triggered blast radius Segregate payment, subscription, and notification workflows so that a single forged event cannot create broad account or billing impact.

Key takeaways

• Webhook authenticity failures are governance failures, because they let untrusted requests act as though they came from a legitimate provider.
• The advisory shows that a public webhook URL plus a matching event type is not enough when signature verification is missing.
• The right control is cryptographic sender verification on the raw request before any workflow executes, especially when the workflow can alter payments or subscriptions.

Key terms

• Webhook Authenticity: Webhook authenticity is the assurance that an inbound event really came from the system that claims to have sent it. Identity teams verify signatures and timestamps before acting, because a fake revocation event can wrongly remove access or a missed validation step can leave stale access in place.
• Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.
• XML Signature Verification: XML signature verification is the process of checking that an XML document was signed by the expected party and has not been altered. In secure implementations, the verifier must bind the signature to the exact signed content and reject ambiguity in parsing, references, or digest handling.
• Mobile Identity Trust Boundary: The point at which a mobile device stops being a passive endpoint and starts acting as part of the identity assurance process. When apps can read approvals, automate dialogs, or steal codes, the phone itself becomes part of authentication and must be governed as such.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and IAM practitioners translate identity controls into operational decisions across modern automation and service-to-service trust.