If you’ve been following our blog, you’ll know we’re fans of n8n as an automation platform. It’s powerful, self-hostable, and incredibly flexible. But that flexibility has now caught the attention of threat actors — and the consequences are serious.
In April 2026, researchers at Cisco Talos and multiple security firms revealed that n8n webhooks have been systematically weaponised for phishing campaigns since late 2025. The volume of malicious emails containing n8n-hosted webhook URLs surged by 686% between January 2025 and March 2026. This isn’t a vulnerability in n8n itself — it’s a masterclass in abusing legitimate infrastructure.
TL;DR
- Threat actors are weaponising n8n webhooks to deliver malware via phishing emails, with a 686% surge in malicious email volume since early 2025
- Attackers exploit n8n’s workflow automation to fingerprint victims (OS, browser) and tailor payloads dynamically — a technique that bypasses traditional email security
- The attack chain uses CAPTCHAs and trusted domains to evade detection, ultimately deploying modified RMM tools for persistent command-and-control access
- Self-hosted n8n instances are particularly at risk if webhook endpoints are publicly exposed without authentication
- This is part of a broader trend of legitimate developer tools being turned against their users — your automation stack needs the same security scrutiny as your application code
How the Attack Works
The attack is elegant in its simplicity, which is precisely what makes it dangerous. Here’s the chain:
1. The Lure. Victims receive emails claiming to contain a shared document — a Google Doc, an invoice, a contract. The link points to an n8n-hosted webhook URL. Because n8n instances often sit on legitimate cloud infrastructure, the URLs pass domain reputation checks that would flag a known malicious domain.
2. The Fingerprint. When the victim clicks, n8n’s workflow reads the request headers — user-agent, IP, referrer — and automatically profiles the target. Is this a Windows machine? macOS? iOS? The workflow branches accordingly, serving a tailored payload for each platform. This is automation doing exactly what it was designed to do, just for the wrong reasons.
3. The CAPTCHA Gate. Before delivering the payload, victims are shown a CAPTCHA. This serves two purposes: it filters out automated security scanners (which can’t solve CAPTCHAs), and it gives the interaction a veneer of legitimacy. Users are conditioned to trust CAPTCHA challenges.
4. The Payload. Once past the CAPTCHA, the workflow triggers a download from an external host. The payload is typically an executable or MSI installer that deploys modified versions of legitimate Remote Monitoring and Management (RMM) tools — Datto, ITarian Endpoint Management — which then establish persistent command-and-control connections.
The genius of this approach is that every individual component is legitimate. n8n is legitimate. CAPTCHAs are legitimate. RMM tools are legitimate. It’s only the orchestration that’s malicious.
Why This Matters for Development Teams
This isn’t just a phishing story — it’s a supply chain trust story. If your organisation uses n8n (and many do, especially since self-hosting became the default for teams wanting data sovereignty), you need to consider several implications.
Your Webhooks Are Public Endpoints
Every n8n webhook is, by default, a publicly accessible HTTP endpoint. If you’ve deployed n8n without restricting webhook access, you’ve effectively created an open API that anyone can trigger. Attackers don’t even need to compromise your instance — they spin up their own.
But if your instance is exposed, it could be co-opted. Talos reported instances where attackers gained access to poorly secured n8n deployments and created their own workflows, turning legitimate business infrastructure into a malware distribution network.
Automation Tools Need Security Audits
We routinely audit application code, infrastructure configurations, and CI/CD pipelines. But how often does your team audit the workflows running in your automation platforms? n8n workflows can make HTTP requests, execute code, access databases, and interact with dozens of third-party services. A compromised or malicious workflow has the same blast radius as a compromised microservice.
Domain Reputation Is No Longer Sufficient
Traditional email security relies heavily on domain reputation. When phishing links point to cloud-hosted services on reputable infrastructure — whether that’s n8n on AWS, a Cloudflare Worker, or a Vercel deployment — domain-based filtering fails. Security teams need to move beyond reputation and towards behavioural analysis.
What You Should Do Right Now
If your team uses n8n or similar workflow automation platforms, here’s a practical checklist:
Audit your webhook exposure. List every active webhook in your n8n instance. Which ones are public? Which ones actually need to be? Lock down anything that doesn’t require external access.
Add authentication to webhooks. n8n supports webhook authentication via headers and query parameters. Use it. Every public webhook should require a token or API key at minimum.
Network-level restrictions. If your n8n instance only needs to receive webhooks from specific services (GitHub, Stripe, your own applications), restrict inbound traffic at the firewall or reverse proxy level.
Monitor workflow changes. Treat your n8n workflows like code. Version them, review changes, and alert on new webhook creation. If someone creates an unexpected workflow on your instance, you want to know immediately.
Review RMM tool policies. If your organisation uses Datto, ITarian, or similar RMM tools, ensure you have application allowlisting in place. Legitimate RMM tools should only run from approved installation paths.
Update your phishing training. Your team needs to know that phishing links don’t just come from dodgy domains anymore. Trusted infrastructure is the new attack surface. If a “shared document” link points to an unfamiliar subdomain — even on AWS or a known platform — verify it before clicking.
The Bigger Picture: Legitimate Tools as Attack Vectors
This n8n campaign is part of a broader, deeply concerning trend. We’ve seen it with Trivy being targeted in supply chain attacks, with IDE extensions being used as malware delivery mechanisms, and with developer workstations becoming primary attack surfaces.
The common thread? Attackers are no longer building bespoke infrastructure. They’re co-opting the tools developers and operations teams already trust. The implication for security strategy is clear: every tool in your stack is a potential attack vector, and “it’s a trusted tool” is no longer a valid reason to skip security review.
At REPTILEHAUS, we see this firsthand in our DevOps and security work with clients. The teams that fare best are the ones treating their automation layer — n8n, Zapier, GitHub Actions, CI/CD pipelines — with the same rigour they apply to production application code. That means access controls, audit logging, change management, and regular security review.
Moving Forward
n8n remains an excellent automation platform. This attack doesn’t change that — if anything, it’s a testament to how powerful and flexible the tool is. But power demands responsibility. The same webhook flexibility that lets you build sophisticated integrations in minutes also creates attack surface if left unsecured.
The lesson isn’t “stop using n8n.” It’s “start securing n8n like it matters.” Because it does.
If your team needs help auditing your automation infrastructure, locking down webhook endpoints, or building security into your DevOps workflows, get in touch. This is exactly the kind of work we do.
📷 Photo by Zulfugar Karimov on Unsplash
