Critical n8n RCE via expression injection: why your workflows are a targeted attack surface

n8n expression injection: a single workflow misstep that can hand an attacker full server control

What happened (short and sharp)

A critical Remote Code Execution (RCE) vulnerability has been disclosed in n8n, the popular open-source workflow automation platform. The issue lies in the platform’s expression evaluation: under certain conditions, expressions supplied during workflow configuration can be evaluated in a context that is not sufficiently isolated from the runtime, allowing an authenticated user to execute arbitrary code with the privileges of the n8n process.

The vulnerability affects versions starting with 0.211.0 and prior to the patched releases 1.120.4, 1.121.1 and 1.122.0. Successful exploitation can lead to full compromise of the affected instance, including unauthorised access to sensitive data, modification of workflows and execution of system-level operations. The vulnerability has been rated 9.9 (CRITICAL). The vendor’s guidance includes upgrading to a patched version and, where immediate upgrade is not possible, short-term mitigations such as limiting who can create and edit workflows and running n8n in a hardened, restricted environment.

Why this matters to your business

Workflow automation platforms like n8n sit at a sweet spot for attackers: they connect to systems, hold credentials, move data and run actions automatically. Think of them as digital autopilots for business processes — very handy until someone takes the controls.

If an attacker can run code as the n8n process, they can quietly steal credentials, alter automations to exfiltrate data, inject malicious steps into business processes, or pivot to other systems. The business consequences are obvious and unpleasant: data loss, operational disruption, cancelled supplier contracts, regulatory exposure and reputational damage. This is the sort of incident that turns routine Monday stand-ups into emergency boardroom calls.

How ignoring this kind of weakness plays out

Leave a vulnerable automation platform unattended and you risk scenarios such as:

• Silent data exfiltration: workflows modified to copy data to attacker-controlled destinations over time.

• Lateral movement: the compromised service is used as a beachhead to access other systems and credentials.

• Operational disruption: production automations altered or deleted, creating outages and recovery costs.

• Long-term compromise: attackers persist by creating hidden workflows or backdoors in scripts, delaying detection for months.

In short: an unauthorised change in a workflow can be more damaging than a single misconfigured server, because the workflow is designed to do useful things across your environment.

How recognised standards and good practice reduce the risk

This is precisely the sort of risk an ISO 27001 information security management system helps you manage. ISO 27001 forces you to: know what assets you have (do you even know every n8n instance?), control who can configure them, and require secure change and patch processes so a critical patch doesn’t sit in someone’s ‘to do’ list for weeks.

Likewise, an ISO 22301 business continuity approach will make sure your organisation can keep essential processes running (or fail over safely) if an automation platform is taken offline or abused. Baseline technical controls — think minimum patch levels, least privilege and separation of duties — can be aligned with Cyber Essentials and IASME to raise the floor on risk across the estate.

Human factors matter too: restrict who may create and edit workflows, and ensure those people receive appropriate training so they don’t treat expression inputs as harmless free text. Practical, role-focused training such as usecure security awareness reduces the chance that an overly permissive setting or careless user will hand an attacker the keys.

Immediate and medium-term actions you can take (practical checklist)

• Inventory: identify every n8n instance and catalogue its version and integrations.

• Patch: upgrade to the fixed releases (1.120.4, 1.121.1 or 1.122.0) where possible.

• Mitigate: if you cannot upgrade immediately, limit who can create or edit workflows to a small, trusted group (as the vendor recommends) and run n8n with restricted OS privileges and network access.

• Harden: apply segmentation so automation platforms cannot directly reach critical systems or secrets stores without explicit, audited channels.

• Secrets management: remove long-lived credentials from workflows and use short-lived, auditable credentialing where possible.

• Monitoring and logging: ensure workflow changes, expression edits and administrative actions are logged and reviewed; wire critical alerts into your security monitoring tools.

• Incident readiness: update your incident response runbooks to include automation-platform compromise scenarios and verify backups and recovery paths as part of business continuity planning.

These steps map neatly to ISO 27001 controls: asset management, access control, secure development/change control and supplier/third-party management. If you want help turning that checklist into a plan that actually gets done (not just ticked on a spreadsheet), consider an ongoing package such as Synergos support packages or targeted improvement via ISO 20000 where service management integration is needed.

A final nudge (don’t let automations automate your breach)

Automations save time and reduce human error — until an attacker uses them to multiply the impact of a single exploit. Treat automation platforms like any other critical service: inventory, patch, limit permissions, and practice your response. If you haven’t reviewed who can change workflows since you installed the platform, consider this your prompt to stop putting it off.