A contact form shouldn't give an attacker root access to your automation server. But in n8n versions prior to 2.10.1, that's exactly what could happen. Let's walk through how CVE-2026-27577 and CVE-2026-27493 turned workflow automation into a credential exposure and remote code execution vector.
What Happened
Pillar Security discovered two critical vulnerabilities in n8n, the open-source workflow automation platform. CVE-2026-27577 (CVSS 9.4) allowed attackers to escape n8n's JavaScript sandbox and execute arbitrary code on the host system. CVE-2026-27493 enabled unauthenticated expression evaluation through public-facing Form nodes, letting anyone inject malicious code without credentials.
The attack chain: an attacker submits crafted input through an n8n Form node → the platform evaluates the expression without proper sandboxing → attacker gains code execution → stored credentials and sensitive workflow data become accessible.
Timeline
Discovery: Pillar Security identified both vulnerabilities during a security assessment of n8n's expression evaluation engine and Form node implementation.
Disclosure: Pillar Security reported the findings to n8n's security team through responsible disclosure channels.
Patch Release: n8n released versions 2.10.1, 2.9.3, and 1.123.22 to address both vulnerabilities.
Public Disclosure: The vulnerabilities were publicly disclosed after patches became available.
The timeline demonstrates coordinated disclosure working as intended, but here's the problem: every organization running n8n now faces a race between their patch deployment and attackers reverse-engineering the fixes.
Which Controls Failed or Were Missing
Input validation at the application boundary: The Form nodes accepted user-supplied expressions without sufficient sanitization. Any public-facing form became an injection point. This isn't just missing validation — it's exposing an evaluation engine to untrusted input.
Sandbox containment: The JavaScript sandbox that should have isolated expression evaluation failed under specific conditions. When your security model depends on "the sandbox will hold," you need defense in depth. n8n didn't have it.
Authentication enforcement on sensitive operations: CVE-2026-27493 allowed unauthenticated users to trigger expression evaluation. If your workflow automation accepts public input, every node that processes that input must assume hostile intent.
Least privilege for workflow execution: Workflows ran with sufficient privileges to access stored credentials and execute system commands. When a sandbox escape occurs, the blast radius depends on what the escaped process can reach.
Credential encryption at rest: While n8n encrypts stored credentials, the running process needs access to decrypt them. Once an attacker achieves code execution in that context, encryption at rest provides no protection.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.4.3 mandates that all web applications be protected against common attacks, specifically including injection flaws. If your n8n instance processes payment data or connects to cardholder data environments, these vulnerabilities constitute a direct compliance failure. The requirement doesn't care whether you built the application or deployed it — you own the security of software in your environment.
OWASP Top 10 (2021) A03:2021 – Injection identifies injection flaws as a critical risk category. Expression evaluation without proper input validation is textbook injection. The OWASP ASVS v4.0.3 section 5.2 requires that all user input used in dynamic code evaluation be validated against a strict allowlist. Public-facing forms that feed into expression engines violate this requirement by design unless you implement additional controls.
ISO/IEC 27001:2022 Annex A.8.8 requires that technical vulnerabilities be identified and managed. Once n8n published patches, you had a defined technical vulnerability in your environment. Your vulnerability management process should have flagged every n8n instance and prioritized patching based on exposure (public-facing forms = critical).
NIST 800-53 Rev 5 SI-10 (Information Input Validation) requires that information systems check the validity of input. For workflow automation platforms, this means validating not just the data format but the semantic meaning — does this input contain expressions or code that shouldn't be evaluated?
The broader control failure: NIST CSF v2.0 PR.IP-12 calls for a vulnerability management plan that addresses both detection and remediation. If you're running self-hosted software like n8n, your plan must include monitoring vendor security advisories and testing patches in non-production before deploying to production.
Lessons and Action Items for Your Team
Audit your workflow automation attack surface right now: List every n8n workflow that accepts external input — Form nodes, webhooks, API endpoints. Assume each one is a potential injection point. If you're running versions older than 2.10.1, 2.9.3, or 1.123.22, you have a known remote code execution vulnerability in production.
Implement network segmentation for automation platforms: Your workflow automation server shouldn't have direct access to credential stores, production databases, or sensitive internal APIs. Run n8n in a segmented environment where a compromise limits what an attacker can reach. This won't prevent the sandbox escape, but it reduces the blast radius.
Require authentication for all nodes that process external input: Even if your forms are "public," the workflow processing that input should run with minimal privileges. Consider adding an authentication layer between form submission and workflow execution, or route public submissions to a queue that a separate, privileged process consumes after validation.
Build expression evaluation into your code review process: If your team builds custom nodes or workflows that evaluate user-supplied expressions, treat that code like you would SQL query construction. Review it for injection risks. Test it with malicious input. Don't assume the platform's sandbox will save you.
Establish a patch deployment SLA for critical infrastructure: When a CVSS 9.4 vulnerability drops for software you run in production, how fast can you patch? If the answer is "we'll get to it in the next sprint," you need a faster process. Critical vulnerabilities in automation platforms demand emergency change procedures.
Monitor for exploitation attempts: Even after patching, review your n8n logs for suspicious form submissions or expression evaluation patterns from the period when you were vulnerable. Look for unusual characters in form input, attempts to access system resources, or unexpected workflow executions.
Question the security model of your automation tools: n8n's vulnerabilities highlight a fundamental tension in workflow automation: these platforms need power (file system access, API calls, credential management) but also need to be safe when handling untrusted input. Ask your vendors: How do you isolate untrusted code? What happens when the sandbox breaks? What can an attacker reach after escaping?
The contact form that leads to remote code execution isn't a theoretical attack. It's CVE-2026-27577. Patch it, segment it, and build your controls assuming the next sandbox escape is already in your environment.
