n8n 1.123.60 - Execution Count and Security Fixes

n8n [email protected] was published on June 22, 2026, with a narrow set of fixes for workflow accounting and dependency security. The main operational change is that error workflow executions are excluded from the billable execution count, which matters when n8n is used as a scheduled ETL or web processing control plane. This release is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

The most visible platform fix in this release is in core accounting. n8n now excludes error workflow executions from the billable execution count, tracked in #32544 and commit f3fbfb0.

That detail is small, but it touches a common automation pattern. Many production n8n installs run a primary workflow and a separate error workflow for alerting, incident routing, dead letter handling, or recovery tasks. Counting those error workflows as billable executions can make failure periods look like higher intentional throughput.

For data teams, the distinction matters during noisy upstream failures. A bad API response, malformed payload, expired credential, or source system outage can trigger many error paths. With this fix, those error path runs should no longer inflate the billable count in the same way as normal workflow executions.

The release notes do not describe a schema migration or user action for this change. Operators should still check their own execution metrics after upgrade, especially if internal cost reports, chargeback models, or workflow usage dashboards read from n8n execution counts.

The rest of [email protected] is dependency security work. The release includes one batch that fixes 21 security issues across tmp, protobufjs, ws, and eight more packages, tracked in #32687 and commit bf85807.

A second batch fixes five more security issues across tmp, ws, axios, and one more package, tracked in #32706 and commit 68fb550.

The notes do not enumerate CVE IDs, affected version ranges, or exploit conditions. That limits what operators can infer from the release page alone. The practical read is simpler: this version refreshes parts of the Node dependency graph that sit near temporary file handling, WebSocket behavior, protocol buffer parsing, and HTTP client behavior.

Those areas are relevant to web processing systems because n8n workflows often connect to untrusted services, long lived APIs, webhook sources, and third party data providers. Even when a workflow is internal, the runtime still parses network input and moves payloads through package code maintained outside the n8n repo.

This is a maintenance release, not a feature release. There are no new nodes, CLI flags, config keys, or documented workflow behavior changes in the notes beyond execution accounting for error workflows.

That makes the upgrade decision mostly about risk management. If an n8n deployment is exposed to webhooks, processes external data, or runs customer supplied payloads through workflow logic, the dependency fixes are the main reason to move. If an install also uses execution counts for billing review or capacity reporting, the core accounting fix is directly relevant.

The sparse notes also mean teams should avoid assuming broader security coverage. The two security bullets name several packages, but not every package. Treat this release as a focused dependency update for the packages listed, plus the core billing count correction.

For staged rollout, watch the same signals that matter for any workflow runtime upgrade: failed executions, webhook latency, queue backlog, and error workflow volume. The change to error workflow billing is expected to affect counts, so compare before and after numbers with that accounting change in mind rather than reading every count movement as load growth.

The GitHub release page is the source of record for the release notes.

• Release page: GitHub release page
• Repository: GitHub repository
• Tag: [email protected]