AI Workflow Automation Security: n8n, Zapier, Make.com 2026

AI workflow automation platforms are the fastest-growing unmanaged attack surface in enterprise AI security. n8n, Zapier, and Make.com connect AI models to production databases, payment systems, HR platforms, and SaaS APIs, storing credentials for every system they touch. In 2026, ten CVEs were assigned to n8n alone, two with CVSS 10.0 scores. Cisco Talos documented a 686% surge in phishing attacks weaponizing n8n's legitimate infrastructure. A five-stage exploit chain against Zapier could have exposed every connected service credential of every enterprise customer.

This guide covers the active CVE landscape, the credential exposure architecture unique to workflow automation tools, the specific attack vectors security teams are missing, and the five controls that reduce risk without stopping automation.

---

Why AI Workflow Automation Is a Tier-1 Attack Surface

Security teams typically classify ChatGPT and Copilot integrations as AI risk. The harder-to-see risk is the automation layer underneath: the n8n instances, Zapier accounts, and Make.com workspaces that wire AI models to production systems.

A typical enterprise n8n deployment holds credentials for Google Workspace, Salesforce, an internal PostgreSQL database, Stripe, OpenAI, Slack, and a CI/CD pipeline. The automation platform is the connective tissue between all of them. In practice, we have seen enterprises where a single n8n instance holds more high-value credentials than their PAM solution, but receives none of the same governance oversight.

The attack surface has three distinct characteristics that make it more dangerous than individual SaaS integrations:

Credential concentration. Every integration credential flows through one platform. Compromise one n8n instance and you do not get access to one system. You get access to all of them simultaneously.

Automation invisibility. Workflows are created by marketing, finance, operations, and product teams, not the security team. In most organizations, there is no workflow inventory, no approval process for new integrations, and no monitoring of workflow execution behavior.

The webhook problem. Every AI workflow automation platform exposes HTTP endpoints (webhooks) that external systems call to trigger workflows. These endpoints are internet-accessible by default, often without authentication, and are directly exploitable. CVE-2026-21858, the most severe n8n vulnerability of 2026, requires nothing more than a malformed HTTP request to an exposed webhook URL.

---

n8n CVE Landscape: Ten Vulnerabilities in Six Months

The n8n CVE cluster of 2025-2026 is one of the most concentrated vulnerability disclosures against any enterprise AI infrastructure component. Understanding the specific exploitation chains matters, because several require different remediation steps.

CVE-2026-21858 "Ni8mare" — CVSS 10.0

Discovered by Cyera Research Labs. A content-type confusion flaw in n8n's webhook file-upload handler. When a file-handling function runs without verifying the Content-Type is multipart/form-data, an attacker can override req.body.files by sending an application/json request body instead.

The exploitation chain has three stages:

Arbitrary file read. The attacker forges the filepath parameter to read local filesystem files, including /etc/passwd and application configuration files.

Authentication bypass. The attacker reads the SQLite database at /home/node/.n8n/database.sqlite, extracting admin credentials and the N8N_ENCRYPTION_KEY. With the key, every stored credential is decryptable. A valid _n8n-auth_ session JWT is forged.

Remote code execution. An authenticated attacker creates a workflow containing n8n's built-in "Execute Command" node and runs arbitrary OS commands on the host.

No authentication is required at any stage. Estimated 100,000 internet-exposed n8n instances were at risk at time of disclosure. Patched in n8n v1.121.0 (November 18, 2025). CVE publicly disclosed January 7, 2026.

CISA added n8n RCE to its Known Exploited Vulnerabilities catalog in March 2026, requiring federal agencies to patch within three weeks.

CVE-2026-1470 — CVSS 10.0

An AST sandbox escape in n8n's expression evaluator. A standalone constructor identifier using JavaScript's with statement bypasses sanitization and resolves to Function, enabling arbitrary JavaScript execution on the main n8n process. Patched in v2.5.1.

CVE-2026-25049 — CVSS 9.4

Discovered by Pillar Security. A three-stage expression sandbox bypass:

Template literals bypassed the PrototypeSanitizer's property denylist.

The prepareStackTrace V8 hook returned unboxed global objects via getThis().

Arrow functions were not processed by the AST sanitizer, using a different node type than MemberExpression.

The researchers extracted the N8N_ENCRYPTION_KEY environment variable, decrypted all stored credentials, and demonstrated multi-tenant lateral movement on n8n Cloud. A second bypass using Object.defineProperty() was discovered three days after the initial patch. Full remediation is in v2.5.2.

The Full CVE Table

| CVE | Component | CVSS | Minimum Patch | |---|---|---|---| | CVE-2026-21858 (Ni8mare) | Webhook file upload | 10.0 | v1.121.0 | | CVE-2026-1470 | JS with statement | 10.0 | v2.5.1 | | CVE-2026-21877 | Authenticated execution | 9.9 | v1.121.3 | | CVE-2025-68668 (N8scape) | Python/Pyodide | 9.9 | v2.0.0 | | CVE-2026-25049 | Template literal bypass | 9.4 | v2.5.2 | | CVE-2026-25056 | Merge Node | 9.4 | v2.4.0 | | CVE-2026-25053 | Git Node | 9.4 | v2.5.0 | | CVE-2026-25052 | File Access | 9.4 | v2.5.0 | | CVE-2026-25115 | Python Code | 9.4 | v2.4.8 | | CVE-2026-25055 | SSH Node | 7.1 | v2.4.0 |

No single version below v2.5.2 covers the full vulnerability set. Enterprises running self-hosted n8n on any version prior to v2.5.2 should treat it as an active incident risk, not a planned patch cycle item.

---

Cisco Talos: How Attackers Weaponized n8n Infrastructure

The CVE cluster is one threat vector. The Cisco Talos n8mare report documents a second, structurally different risk: attackers using legitimate n8n infrastructure for phishing campaigns, without exploiting any vulnerability at all.

Cisco Talos researchers Sean Gallagher and Omid Mirzaei tracked threat actor abuse of n8n webhooks from October 2025 through March 2026. The volume of emails containing n8n webhook URLs in March 2026 was 686% higher than in January 2025.

The attack works because n8n is legitimate software. The *.app.n8n.cloud domain passes domain-reputation filters at most corporate email gateways. Security teams allow it the same way they allow Google Drive or Dropbox URLs in email.

Two Documented Attack Chains

Chain 1: Datto RMM Backdoor. A phishing email impersonates a Microsoft OneDrive file notification. The victim clicks an n8n-hosted webhook URL. A CAPTCHA page appears, preventing automated sandbox analysis from observing what happens next. The payload, a self-extracting archive disguised as DownloadedOneDriveDocument.exe, installs a modified Datto Remote Monitoring and Management tool via PowerShell. A scheduled task establishes persistence, and a C2 connection is made to centrastage[.]net. The installer self-deletes.

Chain 2: ITarian RMM Backdoor. A similar lure delivers an MSI installer for ITarian Endpoint Management. The payload is protected by an Armadillo packer. A fake installer GUI is displayed while Python modules silently exfiltrate device data.

Device fingerprinting without user interaction. Both campaigns embed invisible tags in HTML email bodies using display: none and opacity: 0. These make silent HTTP GET requests to n8n webhook URLs when the email is opened in a mail client that renders HTML. The request carries the recipient's IP address, email client, and OS fingerprint to the attacker, enabling pre-attack profiling of high-value targets before any user action.

The Talos report confirms IOCs including webhook domains pagepoinnc[.]app[.]n8n[.]cloud and monicasue[.]app[.]n8n[.]cloud. Blocking all n8n.cloud traffic is not a practical defense for organizations that use n8n legitimately. Behavioral detection based on anomalous communication volume and unexpected endpoint-to-automation-platform traffic patterns is more effective.

---

Zapier: The Five-Stage Exploit Chain

In May 2026, Token Security disclosed a five-stage vulnerability chain against Zapier that could have resulted in full authenticated account takeover for every enterprise customer and exposure of every connected service credential.

Stage 1: Lambda memory disclosure. Zapier's "Code by Zapier" feature runs Python and JavaScript in AWS Lambda. The credential scrubbing used del os.environ[k], which removes dictionary references but does not zero heap memory. Researchers recovered live AWS STS session tokens by reading /proc/self/mem and applying regex patterns.

Stage 2: IAM role enumeration. The compromised role had ECR permissions (ecr:DescribeRepositories, ecr:ListImages, ecr:BatchGetImage, ecr:GetDownloadUrlForLayer), enabling the researchers to pull 1,111 production container images without Docker registry authentication.

Stage 3: Container image analysis. An NPM publish token was stored in Dockerfile build history via an ARG instruction, a known anti-pattern. The token had action: write permission and bypass_2fa: true.

Stage 4: Package supply chain compromise. The affected packages included zapier-platform-core, zapier-platform-cli, and zapier-design-system. The design system package loads in every authenticated zapier.com browser session.

Stage 5: Authenticated session takeover. With attacker-controlled JavaScript executing in every authenticated Zapier session, an attacker could create Zaps, access connected service OAuth tokens and API keys, and pivot to any connected enterprise system.

Token Security researcher note: "The vulnerability was the composition, and composition is exactly what falls between teams." Each stage crossed a different system ownership boundary. No single team owned the full chain.

Zapier patched the chain by February 16, 2026 (NPM token revocation). No confirmed exploitation occurred. The structural risk persists: all connected service credentials must be stored in Zapier's cloud. For enterprises connecting HIPAA-covered data, PCI-scoped payment systems, or ITAR-controlled technical data through Zapier, evaluate whether that centralized credential custody model is consistent with your data classification requirements.

---

Make.com: The Security Controls Enterprises Are Missing

Make.com (formerly Integromat) holds SOC 2 Type II and ISO 27001 certifications and supports SAML2-based SSO on Enterprise plans. The security architecture is sound at the infrastructure level. The gaps are in workflow-level controls that most organizations do not configure.

Unauthenticated Webhooks

Make.com's Custom Webhook module creates a publicly accessible URL without authentication by default. Any system that knows the webhook URL can trigger the workflow and pass arbitrary data into it. In practice, we have seen this lead to two categories of incidents: workflow flooding (sending high volumes of requests to exhaust execution capacity or trigger downstream systems repeatedly) and data injection (sending malicious payloads to influence the AI or SaaS operations downstream).

Mitigation: add a gatekeeper module to every inbound webhook that verifies a specific header token or HMAC signature before processing proceeds.

Execution Log Data Retention

Make.com stores full execution logs by default, including the complete input and output data for every module in the workflow. This means password reset tokens, credit card numbers passed through payment workflows, and PII from HR automation are stored in execution history visible to any team member with workflow access.

Make.com provides a Data Confidentiality toggle that disables input/output logging for specific modules. Enterprises handling regulated data must audit which workflows have this disabled and enable it wherever sensitive data flows.

Blueprint Export Credential Exposure

When developers build HTTP request modules and paste API keys directly into the configuration rather than using Make.com's Connections tab, those keys are embedded in the workflow blueprint. Exporting a scenario or sharing it with a collaborator exports the embedded credential.

All credentials should be stored in Make.com's Connections tab, which stores them separately from workflow blueprints and allows for centralized rotation.

Shadow Automation Sprawl

The most common governance failure in Make.com deployments is not a technical misconfiguration. It is that scenarios are created by marketing, finance, and operations teams without security review. These scenarios connect AI models to customer databases, CRMs, and payment processors without the security team knowing they exist. The Enterprise tier is required to enforce RBAC and SSO; Core and Pro plans lack these controls. For regulated industries, the Enterprise tier is the only plan that provides security-adequate governance.

---

The Five Security Controls That Matter Most

These controls apply across n8n, Zapier, Make.com, and Tray.io. They are ordered by risk reduction per effort.

1. Authenticate Every Webhook

Unauthenticated webhooks are the primary active exploitation vector. For n8n: set webhook authentication to Header Auth and require a specific token in all requests. Audit all deployed workflows for unauthenticated webhook nodes. Treat any internet-accessible unauthenticated webhook as a critical finding. For Make.com: add a gatekeeper module to every inbound webhook. For Zapier: use Zapier's built-in webhook authentication options and validate incoming payloads.

A BeyondScale AI security assessment covers webhook exposure as a primary finding category, including automated discovery of unauthenticated endpoints in self-hosted automation deployments.

2. Isolate Credentials in a Secrets Manager

For n8n: set a static, externally managed N8N_ENCRYPTION_KEY stored in AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Never use the auto-generated key in production. Migrate self-hosted instances from SQLite to PostgreSQL, as the SQLite database at /home/node/.n8n/database.sqlite is the direct file read target of CVE-2026-21858. For Make.com: require all credentials to be stored in the Connections tab, never inline in module configuration. Establish a rotation schedule for all connection credentials and enforce it through access reviews.

3. Enforce Network Egress Allowlists

n8n and Make.com instances should only be able to initiate outbound connections to explicitly approved destinations. This limits the blast radius of a compromised workflow. A workflow that can only call your CRM, your internal database, and one approved AI API cannot be used to exfiltrate data to an arbitrary attacker-controlled endpoint, even if prompt injection compromises the workflow logic. See OWASP's guidance on SSRF prevention for the technical controls that apply to automation platforms as well as web applications.

4. Enable Audit Logging and Alert on Anomalies

n8n Enterprise audit logging records workflow.updated, credential.used, and execution events with timestamps and user IDs. Enable it. Alert when: credentials are accessed by a workflow that has never accessed them before; workflow execution volume spikes significantly outside business hours; new webhook endpoints are created; any workflow is modified to include an "Execute Command" or shell node.

For Zapier and Make.com cloud, export activity logs to your SIEM. Establish baselines and alert on deviations. Workflow automation platforms are rarely targets in SIEM detection rules, which means attacker actions in these systems go undetected far longer than equivalent activity in a monitored application.

5. Require Security Review for Regulated Data Workflows

New automation workflows connecting to systems that hold PII, PHI, financial data, or security-relevant credentials should require AppSec sign-off before going to production. This is the same governance discipline applied to code changes in application development. A one-page security review checklist covering: what data flows through the workflow, what credentials it uses, whether webhooks are authenticated, whether execution logging is disabled for sensitive modules, and who owns the workflow going forward. This does not require building a new process; it requires applying the existing AppSec process to a new artifact type.

For a structured review of your current AI workflow automation security posture, including discovery of unauthenticated webhooks, credential exposure paths, and governance gaps, see BeyondScale's AI security assessment services.

---

Self-Hosted vs. Cloud: The Security Trade-Off

Many enterprises deploy n8n self-hosted to keep credentials on their own infrastructure rather than in n8n GmbH's cloud. This is a reasonable position for data sovereignty reasons. The security trade-off: self-hosted puts the patching burden on you.

The n8n CVE cluster of 2025-2026 demonstrates that this burden is significant. Multiple critical vulnerabilities requiring patches to different version minimums (some requiring v2.5.0, others v2.5.2) mean that an organization not actively tracking n8n's CVE feed could be running an exploitable version for months after a patch is available. CISA's KEV catalog addition in March 2026 is a signal that exploitation was observed against federal systems.

For self-hosted n8n, the operational requirements to justify that deployment model include:

• n8n tracked in your vulnerability management program with a patching SLA matching its criticality tier
• The .n8n data directory not accessible via the internet under any circumstances
• The n8n UI restricted to VPN-only access
• A separate PostgreSQL database rather than the default SQLite
• Network egress controls preventing the n8n container from communicating with arbitrary external endpoints

For most organizations, n8n Cloud's automatic patching, SOC 2 Type II certification, and EU/US data residency options make it the lower-risk option unless the business has specific data sovereignty requirements that cloud cannot meet.

---

Incident Response: What to Do When a Workflow Platform Is Compromised

If you suspect a workflow automation platform has been compromised, the immediate priorities are:

Isolate. Shut down the affected n8n instance or revoke the compromised Zapier/Make.com credentials immediately. The goal is to stop ongoing credential use before you confirm the scope of the breach.

Rotate all stored credentials. Assume every API key, OAuth token, and database password stored in the platform has been exfiltrated. Rotate them all, starting with credentials for systems that hold the most sensitive data or have the broadest blast radius.

Review workflow execution logs. Look for: execution of "Execute Command" nodes; HTTP requests to unexpected external destinations; data exports at unusual volumes; workflow modifications you did not authorize; new webhook endpoints created recently.

Check connected systems. Each system whose credentials were stored in the platform should be audited for unauthorized access in the period since the platform was deployed. This is a cross-system investigation, not a single-platform investigation.

Assess downstream AI impact. If the platform connected AI models (OpenAI, Anthropic, Azure OpenAI) and those API keys were exposed, check for: unusual API usage patterns; model fine-tuning jobs you did not initiate; data submitted to the AI API that was not part of authorized workflows.

NIST's incident handling guide SP 800-61 provides the baseline framework. For AI-specific incident response that accounts for autonomous workflow execution, see BeyondScale's AI incident response approach.

---

Conclusion

AI workflow automation platforms sit at the intersection of every enterprise system that matters: databases, SaaS, payment processors, AI models, and identity providers. They were designed for connectivity, not security. The n8n CVE cluster, the Cisco Talos phishing campaigns, and the Zapier exploit chain are three different expressions of the same underlying problem: these platforms are trusted by every system they touch and governed by none of the teams responsible for those systems.

The controls that close most of this risk are not complex: authenticated webhooks, secrets manager integration, network egress allowlists, audit logging, and a workflow review process. What makes them difficult is the organizational reality that workflow automation is owned by operations and marketing teams, not security teams.

The first step is visibility. You cannot secure workflows you do not know exist. A BeyondScale AI security assessment includes discovery and review of AI workflow automation deployments as a standard component of AI infrastructure review. If you are managing automation at scale, that discovery exercise is where the real risk picture becomes clear.