Hacker Sidekick Achieves Remote Code Execution on n8n with CVE-2026-21858

Back to Blog

Prefer YouTube? Open the video in a new tab.

We gave Hacker Sidekick one prompt: build a proof-of-concept exploit for CVE-2026-21858. No guidance. No follow-up instructions. Just the CVE number and a description of what we needed.

It came back with a working exploit that reads any file off a remote n8n server, a documented path to full remote code execution, a validated lab environment, and a technical report covering every step of the chain. CVSS 10.0. The video shows the entire process, failures included.

Why this matters

n8n is one of the most popular open-source workflow automation platforms in the world. Thousands of organizations run it in production to automate everything from data pipelines to internal tooling. If your n8n instance has a Form Trigger workflow with a file upload field, and you're running any version between 1.65.0 and 1.120.x, an unauthenticated attacker can read any file on the server with a single HTTP request.

That alone is critical. But the attack doesn't stop at reading files. The report Hacker Sidekick produced maps the full escalation chain:

1. Read /etc/passwd to confirm the vulnerability works.
2. Read the n8n SQLite database to extract stored credentials.
3. Read the n8n config to get the JWT signing secret (the encryptionKey).
4. Forge a valid n8n-auth token.
5. Authenticate as admin.
6. Create a workflow with an Execute Command node.
7. Run arbitrary commands on the server.

That's the path from "I can read a file" to "I own the server." One confused HTTP request opens the door to complete compromise.

The vulnerability

CVE-2026-21858 is a Content-Type confusion in n8n's Form Trigger webhook handler. Here's how it works.

When a Form Trigger node includes a file upload field, the webhook handler calls a function called prepareFormReturnItem(). This function is supposed to process multipart/form-data uploads. It reads file paths from req.body.files and passes them to copyBinaryFile(), which copies the file data into the workflow's binary storage for downstream nodes to use.

The problem is that the handler never validates the Content-Type of the incoming request. If an attacker sends application/json instead of multipart/form-data, Express's JSON body parser processes the request body directly. The attacker's JSON payload lands in req.body, including a crafted files array where each entry has a filepath pointing to any file on the server.

The handler calls copyBinaryFile(filepath) without checking whether the file path is safe, because it was never designed to handle untrusted paths. In the normal flow, file paths come from the multipart parser and point to temporary upload directories. In the attack flow, they point wherever the attacker wants.

The fix in n8n 1.121.0 is straightforward. It adds a single assertion at the top of the webhook handler:

const req = context.getRequestObject();
a.ok(req.contentType === 'multipart/form-data', 'Expected multipart/form-data');

If the Content-Type isn't multipart/form-data, the request is rejected before any file processing happens. One line blocks the entire attack chain.

The prompt

We opened Hacker Sidekick, created a project folder called CVE-2026-21858, and typed one prompt asking it to develop a proof-of-concept exploit that we could use to validate the fix in our environment and test against our detection rules in a lab. We asked it to use Docker containers for the vulnerable and fixed targets rather than running anything against production systems.

We selected the Exploit dev persona and let it run.

Research and planning

Hacker Sidekick started by researching the CVE. It pulled advisory data from NVD and found a detailed technical write-up from Cyera Research Labs. From that research, it produced an exploit development plan covering the target surface, the vulnerability mechanics, the attack hypothesis, and the validation strategy.

The same plan.md stayed open as the single source of truth for milestones, approvals, and what “done” meant in the lab.

The plan laid out a clear approach: build a confused application/json request that overrides req.body.files to point the filepath field at /etc/passwd. Test it against vulnerable n8n 1.120.0 in Docker. Confirm that the patched 1.121.0 rejects the same request.

It asked for approval before proceeding. We approved and let it run.

Lab environment

It built two Docker containers using docker-compose: one running n8n 1.120.0 (vulnerable) on port 5678 and one running n8n 1.121.0 (fixed) on a second host port (see the compose file in the repo). Both were configured with basic auth disabled and webhooks enabled.

It hit a Docker permissions issue along the way (the current user lacked daemon access) and resolved it on its own by running sudo usermod -aG docker $USER && newgrp docker. A minor obstacle, but the kind of thing that interrupts flow when you're doing this manually. Hacker Sidekick just handled it and kept moving.

The exploit

The proof-of-concept is a Python script called poc.py. It automates the full attack chain:

It waits for the n8n instance to come up. It authenticates to the n8n REST API and extracts an auth token. It creates a Form Trigger workflow with a file upload field programmatically through the API. It sends the confused Content-Type: application/json request with a synthetic files object pointing filepath at the target file. Then it fetches the workflow execution data and extracts the base64-encoded file contents.

The script supports --target vulnerable|fixed to run against either container, --url to override the target endpoint, --cookie-file and --workflow-id for reusing existing sessions, and --file to specify which file to exfiltrate.

The debugging

This is the part that most AI demos don't show. The exploit did not work on the first try.

The first attempt failed because the Form Trigger workflow webhook wasn't registered. Hacker Sidekick discovered that n8n's webhook registration works differently depending on whether a workflow is active, whether it's been saved through the UI, and which version of the FormTrigger node is installed.

It read the n8n source code inside the Docker container to understand the webhook handler internals. It ran sqlite3 queries against the n8n database to inspect the webhook_entity table and understand how webhooks are stored and keyed. It examined the FormTrigger node's TypeScript source to trace how prepareFormReturnItem processes incoming requests.

After multiple iterations, adjusting how workflows were created, how they were activated, and how the exploit request was structured, the exploit landed.

This cycle of attempt, failure, investigation, adjustment is exactly what real exploit development looks like. The difference is that Hacker Sidekick handled it autonomously. Every decision, every dead end, every course correction is documented in the development log.

Exploit confirmed

The exploit runs against the vulnerable container. The confused request goes through. The workflow execution data comes back with the contents of /etc/passwd, base64-encoded in the binary data output. 739 bytes. The full file.

Then it runs the same exploit against the patched container. n8n 1.121.0 checks the Content-Type before processing file fields. The request is rejected with "Workflow Form Error: Workflow could not be started!" The fix works.

PASS on vulnerable. PASS on patched. The exploit is validated in both directions.

The full escalation chain

The report doesn't stop at reading /etc/passwd. It documents the complete path from initial file read to remote code execution.

Once you can read arbitrary files, you pull /home/node/.n8n/database.sqlite to extract every credential stored in n8n. You read /home/node/.n8n/config to get the encryptionKey, which is the JWT signing secret. With that, you forge a valid n8n-auth JWT token, authenticate as admin without knowing any password, create a workflow with an Execute Command node, and run arbitrary commands on the server.

The report documents each step with enough detail that a security team can understand the full blast radius, not just the initial entry point. That's the difference between "there's a file read vulnerability" and "an unauthenticated attacker can own this server."

The deliverables

The completed project folder contains everything—including the artifacts visible in the explorer and the wrap-up in Hacker Sidekick once the milestones went green.

• poc.py: The automated proof-of-concept exploit script with authentication, workflow creation, exploit execution, and data extraction.
• plan.md: The exploit development plan with target surface, hypothesis, approach, and validation strategy.
• dev-log.md: A step-by-step development log covering research, planning, every debugging decision, webhook registration discovery, and the final successful exploitation.
• report.md: The technical report with root cause analysis, reproduction steps, lab setup instructions, the full RCE escalation chain, and mitigation guidance.
• docker-compose.yml: Lab environment configuration for both vulnerable and patched targets.
• docker/: Container configurations, initialization scripts, and workflow definitions.

Seven milestones. All completed. One prompt.

What this means for security teams

Every time a critical CVE drops, your team needs to answer the same questions. Are we affected? Does the fix actually work? What's the real impact? Can we detect an attempt?

Answering those questions requires building a lab, understanding the vulnerability mechanics, writing a working exploit, validating the fix, and documenting the results. That's a day of skilled work at minimum, and it's work that most teams don't have time for when the CVE queue is twenty items deep.

Hacker Sidekick compresses that cycle. Not by cutting corners, but by doing the tedious parts autonomously: the API calls, the Docker setup, the script writing, the iteration, the debugging, the documentation. You describe what you need, approve the plan, and focus your expertise on the parts that require human judgment: scoping the risk, deciding the response, communicating to stakeholders.

And unlike every other AI tool on the market, Hacker Sidekick doesn't refuse to help with this work. It was built for it.

Try it yourself

Download Hacker Sidekick at hackersidekick.com and point it at the next critical CVE on your list.

If you're evaluating for a team, reach out at [email protected] or schedule a demo.

- The Hacker Sidekick Team