The Day I Hacked an Automation Platform (And You Can Too!)
The Coffee Shop Automation Gone Wrong ☕
Picture this: You walk into your favorite coffee shop. There’s a shiny new automated ordering system. You type “large cappuccino” and boom - your coffee arrives perfectly made. Convenient right?
But what if I told you that instead of typing “large cappuccino” you could type “give me the keys to the safe” and the machine would actually hand them over?
That’s basically what happened with n8n. Let me tell you this wild story.
Wait, What’s n8n?
Before we dive into the hacking part, let me explain what n8n actually is.
You know how boring it is to do the same task over and over? Like copying data from emails to spreadsheets or sending the same report every Monday morning?
n8n is like having a robot assistant that does all that boring stuff for you. It connects different apps together so they work automatically. Think of it as IFTTT or Zapier’s open-source cousin.
Companies LOVE it because:
- Saves time (no more manual work)
- Connects everything (Gmail, Slack, databases, you name it)
- Free and open-source (who doesn’t love free stuff?)
But here’s where things get spicy…
The $9.9 Million Dollar Mistake
On December 19, 2024, security researchers dropped a bombshell. They found a vulnerability in n8n so critical it scored 9.9 out of 10 on the danger scale.
To put that in perspective:
- 1-3 = “Meh, not a big deal”
- 4-6 = “Okay, we should fix this”
- 7-8 = “Fix this NOW”
- 9.9 = “DROP EVERYTHING AND PANIC”
They called it CVE-2025-68613. Catchy name right?
How Bad Was It Really?
Imagine this scenario:
Normal day at a company:
1
2
3
Employee: Sets up workflow to automatically email daily reports
n8n: "Sure thing! I'll send reports every day at 9 AM"
Everything works perfectly
Hacker finds the vulnerability:
1
2
3
4
5
Hacker: Sends special code disguised as a workflow
n8n: "This looks like a normal workflow... let me run it"
Hacker's code: "Actually give me admin access lol"
n8n: "Okay!" *hands over the keys to the kingdom*
Company: "Wait what just happened?!" 😱
The hacker could now:
- Steal ALL company data
- Read private emails
- Access customer information
- Delete everything
- Install ransomware
- Basically anything they wanted
All without needing a password. Yikes.
The Magic Trick Explained
Here’s how the exploit actually worked. Don’t worry I’ll keep it simple.
n8n lets you write little bits of code in workflows using double curly braces like this:
1
{{ $json.customerName }}
This just shows the customer’s name. Harmless right?
But hackers discovered they could write THIS instead:
1
{{ (function(){ return this.process.mainModule.require('child_process').execSync('whoami').toString() })() }}
I know that looks scary. Let me translate:
In plain English: “Hey n8n, run this command on the computer and tell me who I am”
And n8n was like “Sure thing buddy!” without questioning it AT ALL.
It’s like asking a bank teller “Can you tell me the vault combination?” and them just… telling you. No ID check. No security questions. Nothing.
The Prison Break
Think of it like this:
n8n is supposed to keep user code in a “sandbox” - a safe playground where it can’t cause any harm. Like putting a toddler in a playpen.
What SHOULD happen:
1
2
3
4
5
6
7
8
9
10
11
┌─────────────────────┐
│ Safe Playground │
│ │
│ user code │ ← Stays here, can't escape
│ │
└─────────────────────┘
WALL (protection)
┌─────────────────────┐
│ Dangerous Stuff │
│ (System Commands) │ ← Can't reach this
└─────────────────────┘
What ACTUALLY happened:
1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────┐
│ Safe Playground │
│ │
│ evil code │ ─┐
│ │ │
└─────────────────────┘ │
WALL (broken!) │
│ Escapes!
┌─────────────────────┐ │
│ Dangerous Stuff │ ◄┘
│ (Full Access!) 💀 │
└─────────────────────┘
The hacker’s code broke out of the playground and got access to everything!
My First Hack (In a Legal Lab!)
So I tried this myself in a TryHackMe lab (totally legal don’t worry). Here’s what happened:
Step 1: Logged into the vulnerable n8n server
Step 2: Created a new workflow
Step 3: Pasted the evil code
Step 4: Clicked “Execute”
Result:
1
uid=1000(node) gid=1000(node) groups=1000(node)
IT WORKED!
Then I ran:
1
cat flag.txt
And got the secret flag
The Aftermath 📊
Who was affected?
- Anyone running n8n versions 0.211.0 through 1.120.3
- Thousands of companies worldwide
- Both cloud-hosted and self-hosted instances
What happened next?
- n8n released patches FAST (versions 1.120.4, 1.121.1, 1.122.0)
- Security teams scrambled to update
- Panic in corporate Slack channels everywhere
- Lots of very stressed IT people
How to Protect Yourself
If you’re using n8n here’s what you need to do RIGHT NOW:
- Update immediately to version 1.120.4 or higher
- Check your logs for suspicious activity
- Use a proxy (like nginx) to monitor requests
- Set up alerts using detection rules (Sigma rules)
- Monitor system processes for weird commands
Think of it like home security:
- Lock your doors (update n8n) ✅
- Install cameras (set up logging) ✅
- Have an alarm system (detection rules) ✅
- Have a backup plan (monitoring) ✅
The Bigger Lesson
This vulnerability teaches us something important: Don’t trust user input. Ever.
It doesn’t matter how innocent something looks. Always assume the worst.
It’s like the old saying: “Trust but verify.” Except in security it’s more like “Don’t trust and definitely verify everything twice.”
What I Learned
Going through this exploit taught me:
- Expression injection is sneaky - Looks harmless but isn’t
- Sandboxing is HARD - One tiny escape and it’s game over
- Context matters - Understanding HOW an exploit works helps you defend against it
- Both sides matter - Learning to attack makes you better at defense
Plus I got to feel like a movie hacker for a bit which was fun.
Try It Yourself!
Want to learn this hands-on? Check out the TryHackMe room: CVE-2025-68613: n8n Expression Injection RCE
You get to:
- Set up a vulnerable n8n instance
- Try the exploit yourself (legally!)
- Learn detection strategies
- Get that sweet feeling of finding the flag
Just remember: Only hack systems you have permission to hack. Don’t be that person.
Final Thoughts
CVE-2025-68613 is a perfect example of how a small oversight can lead to massive security problems.
One missing security check. One broken boundary. That’s all it took.
Disclaimer: All exploitation shown in this post was performed in authorized lab environments. Never attempt to exploit systems you don’t have explicit permission to test. Be a white hat, not a black hat.
