The n8n API Token Leak That Put Live Instances at Risk

Michael Miller · 2026-08-05

It's easy to assume that the biggest security threats come from sophisticated exploits or zero-day vulnerabilities. But sometimes, the real danger is much simpler—and much more embarrassing. A recent investigation by GitGuardian uncovered something that should make every developer pause: hundreds of live n8n instances were left wide open because API tokens were sitting in public GitHub commits. No fancy hacking tricks required. We're talking about real, running systems that were exposed to anyone who knew where to look. The researchers found 321 n8n instances that were actively accepting API tokens that had been leaked into public repositories. That's not a hypothetical risk. That's a live, ongoing problem. ### What the Scan Found GitGuardian's team scanned public GitHub commits specifically looking for n8n API tokens. The results were staggering. They identified 4,576 unique credentials tied to 1,255 different hostnames. Out of those, 896 were confirmed as valid and actively usable. That means attackers could potentially walk right into these systems without breaking a single lock. Here's a quick breakdown of what was exposed: - **321 live instances** accepting leaked API tokens - **4,576 unique credentials** found in public commits - **1,255 hostnames** associated with those credentials - **896 credentials** confirmed as valid and usable Those numbers aren't just statistics. Each one represents a system that could be holding sensitive customer data, internal workflows, or downstream credentials that lead to even bigger problems. ### Four Ways Attackers Could Exploit This The researchers didn't just stop at finding the leaks. They also demonstrated four distinct ways an attacker could use these exposed tokens to cause real damage. None of these methods require exploiting a software vulnerability. They just require a token that shouldn't have been public in the first place. First, attackers could use the tokens to read sensitive data directly from the n8n workflow. That includes any data that flows through your automations—customer records, payment details, internal notes, you name it. If it passes through n8n, it's potentially exposed. Second, the tokens could be used to modify or delete existing workflows. Imagine an attacker silently changing a workflow that sends invoices or handles user onboarding. The damage wouldn't be immediate, but it would be devastating over time. Third, attackers could create new workflows or execute actions on behalf of the legitimate user. This opens the door to all sorts of malicious activity, from sending phishing emails from your own infrastructure to exfiltrating data in the background. Fourth, and perhaps most concerning, the tokens could provide a path to downstream credentials. n8n often connects to other services—databases, email providers, payment gateways, and more. If those connections store credentials, an attacker could potentially pivot from the n8n instance to those other systems. ### Why This Matters for Your Team If you're using n8n in your organization, this isn't just a news story. It's a wake-up call. The reality is that API tokens get leaked all the time, often without anyone noticing until it's too late. A developer might accidentally commit a `.env` file to a public repo, or a token might end up in a test script that gets pushed to GitHub. It happens more often than you'd think. The good news is that this is entirely preventable. The first step is to scan your own repositories for any leaked credentials. There are tools available that can help you do this automatically. The second step is to rotate your tokens regularly and revoke any that you suspect might have been exposed. ### Practical Steps to Protect Yourself Here are a few things you can do right now to reduce your risk: - **Run a secret scanner** on all your public and private repositories to catch any exposed tokens - **Rotate your n8n API tokens** immediately if you find any in public commits - **Use environment variables** instead of hardcoding credentials into your workflows - **Set up alerts** for any new commits that might contain secrets - **Limit token permissions** to only what each workflow actually needs Taking these steps won't just protect your n8n instances. It will protect everything downstream that your workflows connect to. And in a world where one leaked token can lead to a full-blown breach, that kind of protection is priceless. ### The Bottom Line This research is a reminder that security isn't just about patching software or building firewalls. Sometimes it's about the simple things—like making sure you don't accidentally share your keys with the entire internet. The fact that hundreds of live instances were exposed through public GitHub commits should be a wake-up call for every team using n8n or any other automation tool. Take a few minutes today to check your own repositories. Look for any tokens, keys, or credentials that shouldn't be there. If you find something, rotate it immediately. It might feel like a hassle, but it's a lot less painful than explaining to your boss why an attacker had full access to your production workflows for months. Stay safe out there.