n8n 1.123.44 Patches the Sandbox and LangSmith Dependencies Under AI Workflow Automation

The most important n8n release today is easy to underrate because the changelog line looks like maintenance work: “Fix 11 critical issues in vm2, protobufjs, langsmith and 1 more.” That is not housekeeping. For a workflow automation platform with native AI features, LangChain-backed workflows, custom Code nodes, credentials, integrations, and self-hosted deployments, dependency security is the runtime boundary users actually bet on.

n8n 1.123.44, published May 18, patches a set of vulnerabilities across vm2, protobufjs, langsmith, and @protobufjs/utf8. The linked PR, #30563, was merged May 17 by aikido-autofix[bot] with 68 additions and 39 deletions across four files. The PR says the fixes cover critical sandbox escape RCE, code injection, prototype pollution, and denial-of-service issues. That is a lot of blast radius hiding behind four files.

n8n is not a niche toy at this point. At research time, n8n-io/n8n had roughly 188,505 stars, 57,763 forks, 1,473 open issues, and had been pushed minutes after the release. The product describes itself as workflow automation with 400-plus integrations, native AI capabilities, code/no-code flexibility, cloud deployment, and self-hosting. Its advanced AI docs say AI workflow features have been available on cloud and self-hosted installs since version 1.19.4, including chatbots, document and data processing, templates, and LangChain-based workflows.

The sandbox is not a nice-to-have when users can run code

The vm2 bump is the urgent part for operators. n8n’s Code node lets users write JavaScript or Python as a workflow step. On n8n Cloud, external JavaScript modules are restricted to crypto and moment. Self-hosted deployments can enable built-in and external npm modules. The JavaScript Code node docs say it cannot access the filesystem or make HTTP requests directly, pointing users to dedicated nodes for those operations. Native Python support uses task runners, denies insecure built-ins by default, and lets self-hosters include and allowlist third-party modules in runner images.

Those constraints are good. They also make the sandbox dependency part of the product’s security promise. A sandbox escape remote-code-execution bug is not “just another vulnerable package” when the product’s job includes running user-authored or AI-generated code near credentials and integrations. PR #30563 lists CVE-2026-45411 as a critical vm2 sandbox escape involving async generator/yield exception handling, where closing a generator and catching runtime exceptions can enable arbitrary host code execution. It also lists AIKIDO-2026-10808 for a similar isolation bypass.

If you self-host n8n for one trusted user on an isolated machine, the risk profile is one thing. If you run a shared workspace, let multiple teams author Code nodes, allow AI-generated workflows, or connect production credentials, the risk profile is very different. In that environment, a sandbox escape is the shortest path from “clever workflow” to “host compromise.” Upgrade windows should reflect that.

This is also where AI changes the operational calculus without changing the underlying computer science. The vulnerability class is old. The new part is how code gets into the workflow. AI workflow builders can generate glue code, transform snippets, or orchestration logic faster than teams can review every line with care. That does not mean AI-generated code is inherently malicious. It means the system will produce more dynamic code, more often, under more ambiguous authorship. Sandboxes matter more, not less.

Protobuf bugs land below the attention line

The protobuf fixes are less theatrical but just as worth taking seriously. The PR updates the protobuf override from protobufjs@<=7.5.5: 7.5.5 to protobufjs@<=7.5.6: 7.5.6, addressing high-severity issues including code injection through crafted bytes field defaults and prototype pollution. Serialization libraries are the classic “nobody owns this until the incident” dependency. They sit underneath request parsing, event payloads, workflow state, trace data, model/tool schemas, and integration messages.

AI workflow systems are especially serialization-heavy. They shuttle model outputs, tool definitions, webhook bodies, structured extraction results, trace events, and stored workflow state through layers of SDKs. A prototype pollution issue in that stack is not glamorous, but it can distort application behavior in places engineers do not expect. A code-injection issue in a schema compiler is worse because it turns a data-description layer into an execution surface.

The practitioner lesson is not “panic about protobuf.” It is: stop treating low-level dependency updates as disconnected from agent safety. Agent orchestration is ordinary software supply-chain security with more triggers. The model prompt may be novel. The exploit path may still be a stale package, a permissive sandbox, or a schema parser doing too much.

Tracing clients are production dependencies now

The LangSmith bump is the most AI-specific change. n8n upgrades langsmith in packages/@n8n/ai-workflow-builder.ee from 0.5.19 to 0.6.0. The PR explicitly checks compatibility: the changelog’s pydantic v2 breaking change applies to Python users, while n8n uses the JavaScript/TypeScript client for creating LangSmith clients, tracing clients, reading datasets, listing datasets, and importing TypeScript types.

That note is the right behavior. Tracing and eval libraries used to feel like developer tooling. In agent systems, they increasingly sit on the runtime path. They receive prompts, outputs, tool-call metadata, dataset references, evaluation artifacts, and sometimes user content. They are part observability, part governance, part debugging surface. Teams should review their upgrades like production code, not like optional test dependencies.

The deeper issue is that n8n sits at a crowded boundary: workflow engine, Code node, task runner, credential broker, model integrations, LangChain/LangSmith clients, external APIs, and self-hosted runtime. There is no single perimeter. There are many small perimeters. A good security posture means each one holds: sandbox isolation, module allowlists, credential scoping, network egress rules, dependency updates, logging, and human review for promoted workflows.

That matters because automation platforms are attractive places to put agents. They already have integrations. They already know how to move data between systems. They already have credentials. Add natural-language workflow generation and model-assisted branching, and suddenly the automation platform becomes the agent runtime by default. Convenient, yes. Also a bigger attack surface than many teams have modeled.

The operational advice is direct. Upgrade self-hosted n8n instances promptly, especially where Code nodes, AI workflow builder features, or multi-user workspaces are enabled. Check whether external modules are allowed in JavaScript Code nodes and whether that setting is still justified. Review Python task-runner allowlists. Treat AI-generated code as code: review it before promotion, test it, and do not give it broader credentials than necessary. Keep tracing/eval SDKs in your production dependency inventory. If your n8n instance can reach internal services, think hard about network egress and which nodes are allowed to fetch URLs.

There was no useful release-specific discussion on Hacker News or Reddit during the research window. That silence is normal for dependency security releases, and it is exactly why this belongs in the morning brief. The industry loves arguing about whether agents are the future. Meanwhile, the future is apparently running through vm2, protobuf, and a tracing client. Ship the patch.

Sources: n8n 1.123.44 release, n8n PR #30563, n8n Advanced AI docs, n8n Code node docs