JFrog Security Research disclosed two sandbox escape vulnerabilities in n8n that allow authenticated users to achieve remote code execution on the underlying server. The flaws demonstrate the difficulty of safely sandboxing dynamic languages like JavaScript and Python.

Vulnerability overview

CVECVSSComponentRoot Cause
CVE-2026-14709.9 (Critical)Expression evaluation engineJavaScript with statement bypass
CVE-2026-08638.5 (High)Python Code NodeAttributeError.obj + format strings

Both require authentication (ability to create/modify workflows), but non-admin users can exploit them to gain infrastructure-level control.

Why n8n vulnerabilities are dangerous

n8n is a workflow automation platform that connects to critical business systems:

Connected systemRisk if n8n compromised
LLM APIsAI system access, prompt injection
Sales dataCustomer information exposure
Internal IAMIdentity compromise
CI/CD pipelinesSupply chain attacks
DatabasesData theft, manipulation
Cloud servicesAWS/Azure/GCP access

“Compromising n8n doesn’t just give attackers one server, it potentially gives them access to everything n8n connects to.”

CVE-2026-1470: JavaScript sandbox escape

Severity: CVSS 9.9 Critical

n8n’s expression engine evaluates user-provided JavaScript in a sandboxed environment. The sandbox uses AST (Abstract Syntax Tree) parsing to block dangerous constructs.

The bypass mechanism

StepAction
1Attacker creates workflow with malicious expression
2Expression uses deprecated JavaScript with statement
3AST parser still supports with (deprecated but valid)
4Standalone constructor identifier bypasses sanitization
5Identifier resolves to Function constructor
6Arbitrary JavaScript executes on n8n’s main node
7Attacker gains full Node.js runtime access
8System commands execute on host

Technical details

AspectDetails
Vulnerability typeEval injection
Bypass techniquewith statement AST handling
TargetExpression sandbox
ResultFull Node.js runtime access
ImpactArbitrary code execution on host

The deprecated with statement

The JavaScript with statement was deprecated in ES5 strict mode (2009) but remains valid syntax that AST parsers must handle. The n8n sandbox validates expressions using AST parsing, but the with statement creates a scope chain that allows identifier resolution to bypass sanitization:

ProblemImpact
with still parsed by ASTDeprecated ≠ removed
Standalone identifier allowedResolves through scope chain
Identifier reaches FunctionConstructor access achieved
Arbitrary code executionFull Node.js runtime control

This is a classic example of deprecated language features creating security gaps—the feature is “discouraged” but still functional, and security tools must account for it.

Why it’s rated Critical despite requiring authentication

n8n deployments typically grant workflow creation permissions to multiple users. The vulnerability allows any user with basic access to escalate to infrastructure-level control—a significant privilege boundary violation.

User roleExpected accessActual access with CVE-2026-1470
Workflow creatorCreate automationsFull server control
Non-admin userLimited operationsInfrastructure compromise
External integratorAPI accessHost system access

CVE-2026-0863: Python sandbox escape

Severity: CVSS 8.5 High

n8n’s Python Code Node runs in a restricted environment that blocks dangerous builtins and imports. The bypass combines two Python behaviors:

Attack technique

PhaseTechnique
1Format string object introspection
2Python 3.10+ AttributeError.obj behavior
3Regain access to restricted builtins/imports
4Execute OS commands

Format string introspection

Python format strings can access object attributes. By crafting specific format strings, attackers can introspect Python’s internal object model.

Python 3.10+ AttributeError.obj

When an AttributeError is raised, Python 3.10+ includes a reference to the object that caused the error in the obj attribute. This provides a path back to restricted builtins and imports.

The result: Attackers regain access to blocked functionality and execute arbitrary OS commands.

Python 3.10+ behavior change

The AttributeError.obj attribute was added in Python 3.10 (October 2021) for improved error messages. This well-intentioned change inadvertently created a security issue:

Python versionAttributeError behavior
< 3.10No object reference in exception
≥ 3.10AttributeError.obj contains reference to object

When combined with format string introspection, this allows attackers to “climb back” through Python’s object model to access restricted builtins even after they’ve been explicitly blocked.

Deployment mode impact

n8n can run Python in two modes:

ModePython ExecutionCVE-2026-0863 Impact
External (recommended)Separate Docker sidecarAttacker contained in sidecar; additional escape needed
InternalSubprocess on main nodeFull n8n instance compromise

Organizations running n8n in “Internal” mode face higher risk. The “External” configuration provides defense in depth through containerization.

Deployment mode comparison

FactorInternal modeExternal mode
Python executionMain node subprocessDocker sidecar
Compromise scopeFull n8n instanceContainer only
Additional escape neededNoYes (container escape)
Defense in depthNoneContainer isolation
RecommendedNoYes

Patched versions

CVEFixed Versions
CVE-2026-14701.123.17, 2.4.5, 2.5.1
CVE-2026-08631.123.14, 2.3.5, 2.4.2

The n8n cloud platform has been patched. Only self-hosted instances running vulnerable versions are affected.

Relationship to CVE-2026-21858

These vulnerabilities are separate from CVE-2026-21858 (Ni8mare), the CVSS 10.0 unauthenticated RCE patched in January 2026.

n8n vulnerability summary (2026)

CVETypeAuth RequiredCVSSFixed In
CVE-2026-21858Content-Type confusionNo10.01.121.0
CVE-2026-1470JavaScript sandbox escapeYes9.91.123.17+
CVE-2026-0863Python sandbox escapeYes8.51.123.14+

Organizations running n8n should verify they’ve addressed all three CVEs.

Recommendations

Immediate actions

PriorityAction
CriticalUpdate to latest n8n version (addresses all known vulnerabilities)
HighAudit workflow creators—review who has permission to create/modify workflows
HighUse External Python mode—provides container isolation
HighReview existing workflows for suspicious expression or Python code

Defense in depth

ControlPurpose
Principle of least privilegeLimit workflow creation to trusted users
Network segmentationIsolate n8n from sensitive systems
Container hardeningAdditional restrictions on Python sidecar
MonitoringAlert on unusual workflow executions
Credential rotationLimit exposure of connected service credentials

Architecture considerations

ConsiderationRecommendation
Self-hosted vs cloudEvaluate n8n cloud for managed security
Python execution modeAlways use External (Docker sidecar) mode
Workflow permissionsRestrict to verified, trusted users
Connected credentialsUse service accounts with minimal permissions
Network exposureNever expose n8n to internet

Detection guidance

IndicatorMeaning
Unusual workflow expressionsPossible exploitation attempt
with statement in expressionsCVE-2026-1470 exploitation
Format string manipulation in PythonCVE-2026-0863 exploitation
Unexpected child processes from n8nPost-exploitation activity
Outbound connections from n8n hostC2 or data exfiltration

JFrog’s assessment

“These vulnerabilities highlight how difficult it is to safely sandbox dynamic, high-level languages such as JavaScript and Python. Even with multiple validation layers, deny lists, and AST-based controls in place, subtle language features and runtime behaviors can be leveraged to bypass security assumptions.”

Sandboxing challenges

Language featureSecurity assumptionBypass reality
Deprecated with statementNot commonly usedStill parsed by AST
Format stringsString formatting onlyObject introspection possible
AttributeErrorError handlingContains object references
Builtins blockingPrevents dangerous functionsAlternative paths exist

Context

n8n has now had three critical/high-severity vulnerabilities disclosed in early 2026. The platform’s role in enterprise automation—connecting to databases, cloud services, CI/CD pipelines, and business applications—makes these vulnerabilities particularly impactful.

Organizations should:

PriorityAction
CriticalMaintain aggressive patching cycles for n8n
HighTreat n8n as a high-value target requiring enterprise-grade security
HighConsider whether self-hosted deployment is appropriate given patching burden
MediumEvaluate whether n8n cloud platform’s managed security is preferable
OngoingMonitor JFrog and n8n security advisories

The difficulty of safely sandboxing dynamic languages means that similar vulnerabilities will likely continue to emerge. Defense in depth—container isolation, least privilege, network segmentation—provides essential protection when sandbox bypasses occur.

Current exploitation status

FactorStatus
Active exploitationNot reported as of disclosure
Public PoCTechnical details published by JFrog
Weaponized exploitNot publicly available
Cloud platformAlready patched
Self-hostedRequires manual update

While no active exploitation has been reported, the detailed technical writeup from JFrog provides sufficient information for skilled attackers to develop working exploits. Organizations running self-hosted n8n should patch immediately.

Comparison with CVE-2026-21858 (Ni8mare)

AttributeCVE-2026-21858CVE-2026-1470CVE-2026-0863
NameNi8mareN/AN/A
CVSS10.09.98.5
Auth requiredNoYesYes
ComponentContent-Type handlingExpression sandboxPython sandbox
Fixed in1.121.01.123.17+1.123.14+

The January 2026 Ni8mare vulnerability (CVE-2026-21858) was more severe because it required no authentication. However, CVE-2026-1470 and CVE-2026-0863 are still critical because they allow privilege escalation from any authenticated user to infrastructure control.