n8n 1.123.52 Security Patch: Rejecting Unsafe $jmespath Tokens

What changed

n8n 1.123.52 introduces a targeted security fix that rejects unsafe property tokens in the in-isolate $jmespath evaluator. This patch prevents certain tokens from being interpreted when workflows run JMESPath expressions inside isolated contexts, closing an avenue where malicious or malformed input could influence evaluation results.

Why it matters to businesses

Workflow automation platforms like n8n are often used to handle sensitive orchestration across SaaS and internal APIs. A flaw in expression evaluators can lead to data leakage, privilege escalation inside workflow logic, or unexpected behavior that undermines trust in automation pipelines. Organizations relying on n8n for customer data flows, billing, or provisioning should treat this as a security update with potential operational impact.

Recommended actions for leaders

Ensure your n8n deployments are upgraded to 1.123.52 or a later patched release as soon as your change control allows. Validate critical workflows and custom nodes in a staging environment to surface any behavioral changes in $jmespath-driven logic. Where possible, adopt strict input validation and minimize use of dynamic expression evaluation for untrusted inputs.

Operational controls and longer-term measures

Add this release to your dependency and patch-management dashboards so teams can demonstrate timely remediation. Consider scanning repositories and workflow libraries for places that rely on dynamic property access and add unit tests that simulate malformed tokens. Finally, require pinned n8n versions and change approvals in CI/CD to avoid silent rollbacks to vulnerable builds without review.