What Happened
n8n disclosed and patched a high-severity expression-sandbox escape on July 27, tracked as GHSA-gv7g-jm28-cr3m with a CVSS 4.0 score of 8.7. The vulnerability allows any authenticated user who holds permission to create or modify n8n workflows to execute operating-system commands at the privilege level of the n8n process itself.
Security Joes discovered the bypass while reviewing n8n’s February 2026 fix for CVE-2026-27577 — a 9.4-rated escape patched earlier this year. The new flaw takes a different route through the same identifier-rewriting layer the platform uses to sandbox JavaScript expressions inside workflow nodes. Researchers reported the issue on July 15; n8n shipped fixed releases on July 22 and publicly disclosed the vulnerability on July 27.
Affected versions are all n8n releases below 2.31.5, and all releases in the 2.32.x line below 2.32.1. Fixed versions are 2.31.5 and 2.32.1. No CVE number was assigned as of the disclosure date. Reporting from The Hacker News and SecurityWeek.
Why This Matters for Canadian Organizations
n8n has become a widely adopted workflow automation platform across Canadian development teams, marketing operations, financial services back offices, and managed service providers. Its open-source nature and self-hosting option mean many Canadian organizations run it on internal infrastructure with direct connectivity to databases, internal APIs, cloud credentials, and SaaS platforms integrated into core business processes.
This is the third significant sandbox escape disclosed for n8n since January 2026. The pattern matters: each bypass teaches attackers a new way past the same conceptual defence. Any user who holds workflow creation or modification rights — including contractors, junior developers, or accounts compromised through phishing — gains OS-level command execution on the server. In practice, this translates to access to environment variables storing cloud API keys, database connection strings, internal network services, and any platform the n8n process can reach.
Organizations using n8n to integrate Salesforce, HubSpot, internal ERP systems, or cloud storage providers are at particular risk if their instance remains unpatched. An attacker who exploits this flaw on a self-hosted n8n instance effectively owns the machine and every downstream system it touches.
Under OSFI B-13’s security operations and incident response guidance, organizations must treat this as a high-priority patch given active researcher interest and the established pattern of rapid weaponization of n8n vulnerabilities. Under PIPEDA, any unauthorized data access resulting from exploitation triggers breach notification obligations if real risk of significant harm exists.
What to Do
Update all n8n instances to version 2.31.5 or 2.32.1 immediately. Audit which accounts hold workflow creation or modification permissions and enforce least privilege — remove access from accounts that do not require it. Review workflow execution logs for unexpected OS command activity originating from expression nodes. If your n8n instance stores cloud provider credentials, database connection strings, or API keys in environment variables, rotate those credentials now and audit access logs for unauthorized use. As a defence-in-depth measure, consider network-segmenting your n8n instance from production systems and sensitive data stores, limiting the blast radius if future bypasses are discovered.
