Published: 2026-04-27
Categories: AI Infrastructure Security, Threat Intelligence
n8n Webhook Abuse: Weaponizing AI Workflow Automation for Malware Delivery
Key Takeaways
-
Cisco Talos reported on April 15, 2026 that phishing emails containing n8n-hosted webhook URLs rose roughly 686 percent between January 2025 and March 2026, with sustained abuse beginning in October 2025 [1][2]. The campaign represents a shift from exploiting n8n software vulnerabilities to weaponizing the platform’s legitimate cloud-hosted webhook feature as trusted delivery infrastructure.
-
Two parallel attack patterns dominate the campaign: malware delivery through fake CAPTCHA pages that trigger JavaScript-driven downloads of trojanized remote monitoring and management (RMM) tools, and device fingerprinting via invisible 1×1 tracking pixels embedded in HTML emails [1][3]. Because payloads originate from
*.app.n8n.cloudsubdomains — a TLS-protected SaaS namespace — they have been observed evading reputation-based email and URL filters. -
Observed payloads include a modified Datto RMM agent (“DownloadedOneDriveDocument.exe”) and a backdoored ITarian Endpoint Management installer protected by the Armadillo packer, both impersonating Microsoft OneDrive document workflows and beaconing to attacker-controlled infrastructure including
centrustage[.]net[3][4]. -
This activity coincides with a cluster of high-severity n8n vulnerabilities disclosed in the same window (CVE-2026-21858, CVE-2026-21893, CVE-2026-25049, CVE-2026-25051, CVE-2026-25052, CVE-2026-25053), including an unauthenticated CVSS 10.0 remote code execution flaw in the Form webhook node that uses the same surface attackers are now leveraging for delivery [5][6].
-
Defenders should treat
*.app.n8n.cloudas a partially trusted domain rather than a benign one, baseline expected automation traffic, and restrict outbound and inbound connections to webhook hosts that are not part of an inventoried business workflow.
Background
n8n is an open-source, fair-code workflow automation platform with more than 172,000 GitHub stars and an estimated installed base around 100,000 self-hosted servers in addition to a managed cloud tier [6][7][12]. The platform connects more than 400 third-party applications, exposes a visual builder for chaining nodes, and ships native integrations with large language model (LLM) providers, vector databases, and agent frameworks built on LangChain. Among its core primitives is the webhook node, which allocates a unique, publicly reachable URL on the operator’s account subdomain and invokes a downstream workflow whenever the URL is requested.
Webhooks are by design a “reverse API” intended to let arbitrary external systems push events into an automation pipeline. That same property — unauthenticated, content-flexible HTTP endpoints under a reputable cloud domain — is what makes them attractive to attackers. Cloud-hosted n8n accounts produce webhook URLs of the form <account-name>.app.n8n.cloud, which inherit the trust posture of the parent n8n.cloud zone in many email security and web filtering products. A free developer account is sufficient to mint such URLs, and the operator account behind a webhook is opaque to recipients of any link or pixel that resolves to it.
Cisco Talos’s April 15, 2026 publication, “The n8n n8mare,” is the most detailed open-source analysis of the resulting abuse pattern that we identified at the time of writing. The report documents a sustained campaign running since at least October 2025 in which phishing operators register low-cost or free n8n cloud accounts, build a small set of webhook-fronted workflows, and embed the resulting URLs in commodity phishing lures. By March 2026, Talos’s email telemetry showed message volume containing those URLs had grown to roughly 7.86× the January 2025 baseline [1][2]. Independent reporting from The Hacker News, Cybersecurity News, GBHackers, and Rescana corroborates the timeline, the OneDrive impersonation theme, and the use of trojanized RMM agents as the final-stage payload [2][4][8][13]. This note is based on open-source reporting and has not been independently corroborated by CSA telemetry.
This note builds on prior CSA research notes covering n8n vulnerabilities — CVE-2026-21858 (the unauthenticated “Ni8mare” Form webhook RCE) and the cluster of authenticated sandbox-escape and command-injection flaws disclosed on February 4–5, 2026 — by analyzing the distinct case of attackers using n8n’s intended functionality, not its bugs, as offensive infrastructure. The two threats are linked: both turn the webhook surface into a control point for unauthenticated external traffic, and an attacker who compromises a self-hosted n8n instance through the disclosed CVEs gains exactly the kind of platform identity that the phishing campaign currently has to register legitimately.
Security Analysis
Why the n8n Webhook Surface Is Attractive to Attackers
The campaign exploits four properties of n8n’s hosted webhook feature that, individually, are unremarkable, but combine to produce a high-utility delivery channel. First, every webhook URL resolves under *.app.n8n.cloud, a TLS-protected subdomain of an established SaaS vendor. Many email security gateways, secure web gateways, and browser anti-phishing models bias toward allowing such hosts based on domain reputation, registration age, and certificate transparency data [3][4]. Second, the workflow behind a webhook is fully programmable, so the same URL can serve different content to different visitors, return arbitrary HTML and JavaScript, redirect, or stream binary payloads — without the attacker registering or paying for any additional infrastructure. Third, webhooks accept rich request metadata, including headers, query parameters, and the full URL path, which the workflow can read to fingerprint visitors or vary behavior. Fourth, the relationship between the abused account and the visible domain is obscured: the recipient of a phishing email sees only the n8n subdomain, not the operator behind it.
The net effect is that n8n functions as a domain-laundering relay. Talos describes the pattern succinctly: “Webhooks obscure the source of delivered content,” so payloads “appear to originate from the trusted n8n.io domain” rather than the attacker’s own infrastructure [1][3]. This is structurally similar to historical abuse of services such as Pastebin, Discord CDN, GitHub raw content, and Google Drive, but with two important differences. The webhook is programmable rather than static, and the platform is purpose-built to integrate with AI agents, OAuth-bearing SaaS applications, and email systems — exactly the assets the attacker would later want to reach.
Attack Pattern One: CAPTCHA-Gated Malware Delivery
The malware delivery chain observed by Talos and corroborated by multiple security publications proceeds in five stages [1][3][4]. The lure is an email impersonating a Microsoft OneDrive shared-document notification, with a hyperlink whose visible target is an *.app.n8n.cloud URL. When the recipient clicks the link, the n8n workflow returns an HTML page that displays a CAPTCHA challenge styled to mimic a legitimate verification step. Solving the CAPTCHA causes inline JavaScript to fetch a binary from an attacker-controlled external host, save it under a plausible name such as DownloadedOneDriveDocument.exe, and trigger a download prompt that the browser attributes to the n8n domain. The recipient executes the file expecting a OneDrive document viewer; the binary instead installs a maliciously modified copy of a legitimate RMM tool that establishes persistence and reaches a command-and-control server. Talos identified two payload families in the wild: a modified Datto RMM self-extracting archive and a Microsoft Installer (MSI) wrapped with the Armadillo packer that drops a backdoored ITarian Endpoint Management agent and exfiltrates basic system data while displaying a fake installation progress dialog [1][3][4]. Talos has identified centrustage[.]net as one observed C2 endpoint [1][4].
The CAPTCHA stage is operationally significant. It serves three attacker objectives at once: filtering out automated URL scanners that do not solve interactive challenges, transferring user agency onto the victim so subsequent download prompts feel expected, and masking the JavaScript-driven fetch as part of a “verification” flow that browsers and endpoint controls are conditioned to permit. This pattern — a CAPTCHA layered in front of a fetch from a secondary domain — is reminiscent of the ClickFix and ClearFake patterns observed in 2024–2025, but here it is hosted entirely from a single cloud automation platform rather than from compromised WordPress sites or attacker-registered domains.
Attack Pattern Two: Webhook-Backed Device Fingerprinting
The second observed pattern requires no executable payload and no user click. The phishing operator embeds a 1×1 transparent image whose src attribute is an n8n webhook URL into the body of an HTML email. When the recipient opens the message in any email client that renders remote images, the client issues an automatic HTTP GET to the webhook, which the workflow logs along with request headers, IP address, user-agent string, and any tracking parameters baked into the URL such as a unique recipient identifier or hashed email address [1][3][4]. The operator now knows that a specific recipient opened a specific message at a specific time from a specific client environment — a building block for higher-quality follow-on social engineering, target validation prior to malware delivery, and reconnaissance against high-value mailing lists.
Tracking pixels are not new, but routing them through n8n changes the economics. A webhook reached by a tracking pixel can branch on the user agent or client IP and respond differently — for example, by redirecting traffic from sandboxed analyzers to a benign image while logging the same request under the original recipient’s profile, or by triggering a downstream workflow that automatically generates a follow-up phishing message tailored to the observed device. The same workflow surface that legitimate operators use to react to events makes phishing infrastructure adaptive in a way that static tracking domains are not.
Convergence with the n8n Vulnerability Landscape
The webhook-abuse campaign coincides with an unusual cluster of six high-severity n8n vulnerabilities disclosed within roughly ninety days in late 2025 and early 2026. Cyera Research Labs disclosed CVE-2026-21858, an unauthenticated remote code execution flaw in n8n’s Form webhook node that received a CVSS 3.1 score of 10.0; n8n patched the issue in version 1.121.0 on November 18, 2025 [5][12]. Five additional issues — CVE-2026-21893 (CVSS 9.4 administrator command injection during package installation), CVE-2026-25049 (CVSS 9.4 authenticated RCE via workflow expressions), CVE-2026-25051 (CVSS 8.5 stored XSS in webhook responses), CVE-2026-25052 (CVSS 9.4 arbitrary file read), and CVE-2026-25053 (CVSS 9.4 RCE in the Git node) — were disclosed in close succession by multiple independent researchers, with the cluster patched in 1.123.17 and additional fixes in 1.123.18 (along with 2.5.2 on the v2 line) [6].
The relevant point for defenders is that the vulnerability and abuse threats reinforce each other. CVE-2026-21858 lets an unauthenticated attacker turn a self-hosted n8n server into the same kind of programmable webhook delivery point that the phishing campaign currently rents legitimately on n8n.cloud, but on a victim’s own domain — and with access to whatever credentials, OAuth tokens, and AI workflows the n8n instance already manages. CVE-2026-25051 lets attacker-controlled webhook responses execute script in administrator browsers, which is precisely the surface the campaign already manipulates externally. Organizations that have not patched recent n8n releases must therefore consider not only the immediate compromise risk but the possibility that their own infrastructure could be conscripted into the next wave of trusted-domain phishing.
Mapping to MITRE ATT&CK
The observed activity touches a coherent slice of the MITRE ATT&CK matrix [9]. The lures map to T1566.002 (Phishing: Spearphishing Link) and, in the absence of a click, the tracking-pixel reconnaissance pattern maps to T1598.003 (Phishing for Information: Spearphishing Link), which feeds T1592 (Gather Victim Host Information). User execution of the downloaded RMM installer is T1204.002 (User Execution: Malicious File). Subsequent persistence through the trojanized RMM agent corresponds to T1547 boot-or-logon autostart entries created by the legitimate RMM product, and T1219 (Remote Access Software) describes the abuse of Datto RMM and ITarian as built-in remote control channels. C2 traffic over the RMM tunnel and to centrustage[.]net falls under T1071 (Application Layer Protocol). The use of *.app.n8n.cloud as the delivery host is best characterized as T1583.006 (Acquire Infrastructure: Web Services) when the attacker registers their own account, and T1584.006 (Compromise Infrastructure: Web Services) in any future variant where attackers leverage compromised tenant accounts.
Recommendations
Immediate Actions
Treat *.app.n8n.cloud as a partially trusted domain rather than an implicit allow-list entry. Email security gateways, secure web gateways, and DNS filters should log and inspect traffic to that namespace at the same fidelity applied to other freely registrable web services. Where n8n cloud is not a sanctioned business tool, block clicks to *.app.n8n.cloud outright and alert on rendered tracking pixels resolving to the namespace. Where n8n cloud is sanctioned, allow only the specific tenant subdomains your organization operates and treat all other tenant subdomains as untrusted by default.
Patch self-hosted n8n deployments to a version that contains all six remediated CVEs — defenders should target 1.123.18 / 2.5.2 or later, as 1.123.17 introduced patches for part of the cluster while 1.123.18 added follow-up fixes — and rotate every credential stored in the n8n credential store on any instance that ran a vulnerable version with externally reachable webhooks [5][6]. Hunt for unauthorized installations of Datto RMM, ITarian Endpoint Management, or other RMM agents that are not part of the IT inventory; a number of the binaries in this campaign are signed, packed copies of legitimate software and will not always trigger generic anti-malware signatures. Search SIEM and proxy logs for outbound connections to centrustage[.]net and to *.app.n8n.cloud URLs initiated by user-facing email clients or browsers in the October 2025 through April 2026 window.
Short-Term Mitigations
Inventory all approved n8n workflows, webhook endpoints, and tenant accounts, and configure egress controls so that automation-platform traffic from internal systems is permitted only to those endpoints. Enable strict image-loading defaults in mail clients for messages from external senders, which reduces the effectiveness of webhook-backed tracking pixels without requiring organization-wide blocking of n8n. Enforce phishing-resistant authentication on every system whose credentials are stored in n8n — particularly cloud, source-control, and identity providers — so that a future compromise of an n8n instance cannot be replayed as direct administrative access to those systems.
For organizations that operate n8n in production, restrict workflow creation and editing to a small administrative group, disable unused node types (notably the Git node implicated in CVE-2026-25053 and the Execute Command node), and require all webhook-fronted workflows to authenticate inbound requests with a shared secret or signed token rather than relying on the obscurity of the webhook URL. Configure the n8n instance to log webhook invocations centrally and review request volumes for the kind of automation patterns — large-volume, single-source, repeated-payload — that characterize abuse rather than legitimate integration.
Strategic Considerations
The n8n campaign is one instance of a broader pattern: low-cost, programmable cloud automation services produce trusted domains that double as on-demand attacker infrastructure. Similar properties exist on Cloudflare Workers, Microsoft Azure Logic Apps, Make.com, Zapier, and SaaS form-builders, suggesting a category-level pattern rather than an n8n-specific defect. Security programs should adopt a category-level posture rather than treating each platform as a one-off problem, including baseline visibility into traffic to no-code and low-code automation domains, formal sanctioning processes for tenants used by the business, and detection content tuned for phishing-via-trusted-relay patterns regardless of the specific provider.
Boards and CISOs should factor agent and automation platforms explicitly into vendor and tenant risk management. The security characteristics of these platforms — the ability of a single free tenant to publish content under a trusted parent domain, the breadth of integrations that funnel credentials into a single workflow store, and the centrality of the webhook surface in both legitimate and abusive use — warrant treatment commensurate with the risk that a compromise or abuse event imposes on customers and partners. Engagement with vendors on tenant identity verification, abuse reporting workflows, and per-tenant rate and content controls should be a procurement requirement for new automation platform deployments.
CSA Resource Alignment
The n8n abuse campaign sits at the intersection of several existing CSA frameworks and should be analyzed using them in combination. The AI Controls Matrix (AICM) v1.0 supplies controls relevant to both the platform operator and the customer; control families addressing AI supply chain integrity, agent identity, secure orchestration, and tenant isolation map directly to the conditions under which a single compromised or abused tenant produces enterprise-wide consequences [10]. CSA’s Cloud Controls Matrix (CCM), of which AICM is a superset, contributes long-standing guidance on identity and access management, change control, and threat and vulnerability management that organizations should apply to their n8n self-hosted and cloud deployments alike.
The MAESTRO threat-modeling framework for agentic AI systems is particularly applicable to the orchestration layer where webhooks meet AI agents [11]. MAESTRO’s emphasis on threat modeling at each layer of an agent stack — including memory, tools, orchestration, and identity — provides a structured way to reason about how a webhook-fronted workflow connected to an LLM, OAuth credentials, and downstream automations becomes a high-value target. The CSA STAR program and the emerging STAR for AI assurance work give customers a mechanism for asking automation platform vendors to evidence the controls implied by AICM and MAESTRO rather than relying on marketing assertions.
CSA’s Zero Trust guidance reinforces the operational recommendation to treat *.app.n8n.cloud as partially trusted: identity, device posture, and request context — not parent domain reputation — should determine whether a connection or download is allowed. CSA’s AI Organizational Responsibilities work clarifies that decisions about which automation platforms enter the enterprise environment, how their tenants are governed, and how their abuse patterns are monitored are not purely technical questions; they require ownership at the executive level and integration with broader third-party risk and acceptable-use programs.
References
[1] Cisco Talos Intelligence Group. “The n8n n8mare: How threat actors are misusing AI workflow automation.” Talos Blog, April 15, 2026.
[2] The Hacker News. “n8n Webhooks Abused Since October 2025 to Deliver Malware via Phishing Emails.” The Hacker News, April 2026.
[3] SC Media. “AI workflow platform n8n abused for phishing and device fingerprinting.” SC Media Brief, April 2026.
[4] Cybersecurity News. “Hackers Abuse n8n AI Workflow Automation to Deliver Malware Through Trusted Webhooks.” Cybersecurity News, April 2026.
[5] Cyera Research. “Ni8mare — Unauthenticated Remote Code Execution in n8n (CVE-2026-21858).” Cyera Research Labs, November 2025.
[6] Upwind. “Six n8n CVEs Disclosed in One Day Expose Workflow Security Risks.” Upwind Security Feed, 2026.
[7] Australian Cyber Security Centre. “Critical Unauthenticated Remote Code Execution vulnerability in n8n workflow automation platform.” cyber.gov.au, 2026.
[8] GBHackers. “Hackers Exploit n8n Webhooks to Spread Malware.” GBHackers Security News, April 2026.
[9] MITRE Corporation. “MITRE ATT&CK Matrix for Enterprise.” MITRE ATT&CK Knowledge Base, 2026.
[10] Cloud Security Alliance. “AICM Implementation and Auditing Guidelines.” CSA Research, 2025.
[11] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” CSA Blog, February 2025.
[12] Cybersecurity Dive. “Critical vulnerability found in n8n workflow automation platform.” Cybersecurity Dive, January 2026.
[13] Rescana. “Surge in Malware and Phishing Attacks via n8n Webhooks: Analysis of Cloud Workflow Automation Abuse (2025-2026).” Rescana, April 2026.