T05 · Unauthorized Access and Privilege Escalation
- Location
workflows/01-new-order-webhook.json:5- Finding
Unauthenticated Webhooks Trigger Privileged and Billable Operations
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill matches its eCommerce automation purpose, but it exposes unauthenticated workflows that can send messages/calls and change order records using the operator's credentials.
Review before installing. Only deploy these workflows behind authenticated, signed, and rate-limited webhooks; remove request-controlled confirmation URLs; validate order IDs, phone numbers, statuses, and state transitions server-side; and use least-privilege provider credentials. Also document customer consent, privacy notices, transcript retention, spreadsheet access, and telecom rules before enabling outbound calls or messages.
workflows/01-new-order-webhook.json:5Unauthenticated Webhooks Trigger Privileged and Billable Operations
workflows/08-order-status-updater.json:5Unauthenticated Arbitrary Commerce Order Status Modification
workflows/04-call-result-handler.json:5Forged Vapi Callback Can Confirm or Cancel Arbitrary Orders
workflows/06-whatsapp-sms-fallback.json:5Attacker-Controlled Phishing Links Sent Through Trusted WhatsApp and SMS Accounts
workflows/02-cod-confirmation-call.json:21Untrusted Order Data Is Interpolated into an AI System Prompt
The workflow sends customer phone number, name, order details, and order metadata to an external Vapi endpoint to place an outbound call. In this file there is no warning, confirmation, or disclosure comment indicating that personal/order data will be shared with a third-party service.
This node sends customer phone, name, email, order, and platform metadata to HubSpot, but the file gives no indication that operators or end users are warned that a third-party SaaS will receive the data. In combination with the unauthenticated webhook, this increases the risk of unauthorized PII export and unexpected cross-system propagation.
The skill describes workflows that collect and transmit customer phone numbers, emails, order details, call transcripts, and CRM data across Vapi, Twilio, Google Sheets, HubSpot, Shopify/WooCommerce, and WhatsApp, but it does not warn users about privacy, consent, data retention, or jurisdictional compliance obligations. In this context, the omission is security-relevant because operators may deploy the system without understanding that sensitive customer data is being shared with multiple third parties and logged in broadly accessible systems like spreadsheets.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
TWILIO_ACCOUNT_SID=your-sid
TWILIO_PHONE_NUMBER=+1234567890
TWILIO_AUTH_HEADER=Basic base64encoded
TWILIO_API_URL=https://api.twilio.com/2010-04-01
# Inter-workflow routing
N8N_WEBHOOK_BASE=https://your-n8n-instance.com/webhook
The workflow exposes a publicly reachable POST webhook at a predictable path and does not perform any authentication, signature verification, IP allowlisting, or other invocation constraints before processing order data. In this eCommerce context, an attacker could submit forged orders, pollute Google Sheets with attacker-controlled PII/content, and trigger downstream COD/prepaid confirmation workflows, making the lack of request validation materially risky.
The workflow exposes a POST webhook at a predictable path and the file shows no authentication, signature verification, shared secret, IP allowlist, or payload validation before triggering an outbound customer call. An attacker who can reach the endpoint could submit arbitrary order/customer data, causing unauthorized calls, spam, and pollution of downstream order logs.
The workflow appends customer phone number, customer name, order identifiers, and call metadata to a Google Sheet. This persists personal data, but the file contains no warning, notice, or explanatory comment about that storage behavior.
The workflow updates the Orders sheet to mark the order status as "call_initiated" and stores call metadata. This is a persistent state change affecting business records, but the file provides no user-facing warning or explanatory comment about the update.
The SMS template is hard-coded in English, and the workflow contains no indication that language is selected based on user preference or limited to an English-only context. This is a natural-language policy issue because it imposes a specific language on end users without opt-in or justification.
The outbound call's firstMessage is explicitly written in English and there is no evidence in the workflow that customers can choose another language or that the workflow is restricted to an English-speaking audience. This violates the language/locale policy criteria for natural-language content.
This workflow exposes a POST webhook that appears to accept end-of-call callbacks and then directly updates Google Sheets records, retry queues, and downstream order-status workflows based entirely on request body fields. There is no visible authentication, signature verification, shared secret validation, or source allowlisting, so an attacker who can reach the endpoint could forge callbacks to mark orders confirmed/declined, enqueue retries, or trigger SMS fallback actions.
This workflow automatically sends customer_phone, customer_name, and order metadata to external endpoints via the WhatsApp/SMS fallback and Vapi call nodes. The file contains no user-facing warning, confirmation step, or explanatory comment/docstring disclosing that personal data is transmitted to third-party services.
The workflow exposes a POST webhook that can trigger outbound WhatsApp/SMS sending using attacker-supplied order_id, customer_name, and customer_phone, but there is no visible authentication, signature verification, allowlist, or other trigger constraint. In this context, that creates a message-relay/abuse endpoint that could be used to spam arbitrary numbers, generate telecom/API charges, and poison the call log with fraudulent entries.
The generated WhatsApp and SMS messages force English-language communication to end users. Under the policy, locale or language must not be forced without user opt-in or a clearly documented, justified region-specific constraint.
The workflow tells users it will check refund status, but the node returns a hard-coded status message without querying any order, refund, or payment system. This can mislead customers into believing sensitive account-specific actions were performed, causing incorrect support outcomes and potentially masking operational failures.
The workflow claims it will look up order or shipping status, but it only generates a canned response and performs no retrieval from Shopify, WooCommerce, carrier APIs, or internal systems. In a customer-support context, this creates deceptive behavior that can misinform customers and delay resolution of real order issues.
This workflow transmits externally supplied customer inquiry content to a third-party API endpoint at OpenAI. While external API use is common, in this context it is security-relevant because potentially sensitive support data leaves the primary environment and is processed by another service.
{
"parameters": {
"method": "POST",
"url": "https://api.openai.com/v1/chat/completions",
"sendBody": true,
"specifyBody": "json",
"jsonBody": "={{ JSON.stringify({\n model: 'gpt-4o-mini',\n messages: [\n { role: 'system', content: 'You are an eCommerce customer support assistant. Answer the customer\\'s question helpfully and concisely. If you cannot answer, say you will connect them to a human agent.' },\n { role: 'user', content: $json.message || 'General inquiry about order #' + $json.order_id }\n ],\n max_tokens: 300\n}) }}",
Customer inquiry text, which may contain personal or order-related information, is sent to OpenAI for FAQ generation with no evidence in this file of notice, consent, minimization, or filtering. This creates privacy and compliance risk because externally processing customer support content may violate policy, customer expectations, or applicable data-handling requirements.
The workflow sends customer phone numbers and message content to Twilio without any visible disclosure or consent handling in the workflow. In an eCommerce support setting, this can create privacy and telecom-compliance issues, especially if users did not explicitly agree to receive SMS messages or if sensitive order details are included.
The workflow appends customer order identifiers, phone numbers, response summaries, and timestamps to Google Sheets without any visible notice, retention policy, or access-control safeguards in this file. Storing support interactions in a spreadsheet increases the risk of overexposure, mishandling, and unauthorized access to customer data.
This workflow performs external HTTP PUT requests that modify live order records in Shopify and WooCommerce, but the file contains no visible confirmation step, no user-facing disclosure, and no descriptive warning comment around these operations. Because this is a manifest/config file rather than a README or markdown description, there is no accompanying in-file warning that the webhook can change production order state.
The workflow reads environment-based credentials such as SHOPIFY_ACCESS_TOKEN and WOOCOMMERCE_AUTH_HEADER and sends them in HTTP headers, but there is no warning, comment, or user-facing notice explaining that sensitive credentials are used for outbound authenticated requests. This qualifies as credential access/network transmission lacking disclosure under the rule.
The auto-detect branch claims to determine the target platform, but it only relabels the payload and then proceeds directly to logging and responding without performing any Shopify or WooCommerce update. In an order-management workflow, this creates a silent integrity failure where callers receive a success response even though no external order status was changed, which can mislead operators and downstream automations.
The code comment and workflow behavior imply that auto-detection will support updating unknown-platform orders, but the implementation only sets a platform field and skips the actual update request. This discrepancy is dangerous because it can cause false assurance, audit inaccuracies, and inconsistent order states while returning an 'ok' response to the caller.
The webhook accepts POST requests on a generic path without any visible authentication, signature verification, IP allowlisting, or request validation. An attacker who discovers the endpoint could submit arbitrary records, pollute CRM data, trigger external syncs, and exfiltrate or poison downstream business systems.
No suspicious patterns detected.