n8n's queue-mode handler skipped name, permission, checksum and npm safety checks, so Redis write access could install any npm package cluster-wide. Fixed; no known exploitation.
A missing-authorization flaw in n8n's queue-mode community-package handler lets anyone who can write to the cluster's Redis make every instance install and load an npm package. It is fixed, there is no known exploitation, and Redis access is a precondition.
What happened
n8n has fixed CVE-2026-103251, a missing-authorization flaw in the community-package install handler used by queue-mode (Redis-scaled) deployments. The internal handler applied none of the checks the normal install path performs: name and prefix validation, the install-permission check, checksum verification and the npm safety check. According to the GitHub advisory, anyone able to write to the Redis instance "could have n8n download, install and load any npm package on every instance in the cluster, with no n8n account," an action that is otherwise restricted to the instance owner.
Affected versions are n8n before 1.123.80, 2.0.0 up to but not including 2.39.6, and 2.40.0 up to but not including 2.40.1. The fixed releases (1.123.80, 2.39.6 and 2.40.1) were published on 2026-09-16, the same day as the GitHub advisory GHSA-fmmv-p585-7c8x. The CVE record was published on 2026-10-01 by VulnCheck, the CNA. The reporter is credited as AyushParkara.
Why it matters
n8n is a workflow automation platform that typically holds credentials for many other systems, so code execution on its workers is a high-value outcome. It is the same shape as other AI-infrastructure flaws we have covered, where access to an internal component becomes code execution, such as the LiteLLM proxy admin RCE and the LightLLM RPyC pickle RCE. The flaw turns write access to a message broker into a cluster-wide package-install capability.
Scope matters. This is not an internet-facing unauthenticated bug in n8n itself: the attacker must first be able to write to the Redis instance the cluster uses. That precondition is reflected in the scores: both VulnCheck vectors use an adjacent-network attack vector and require low privileges. Exposed or weakly protected Redis, or an attacker already inside the network segment, is the realistic path. Only queue-mode deployments are described as affected. You are in queue mode if EXECUTIONS_MODE=queue is set on your main instance and workers. n8n's queue-mode docs say Redis does not require a password by default, so check QUEUE_BULL_REDIS_USERNAME and QUEUE_BULL_REDIS_PASSWORD are set and that port 6379 is not published (n8n queue-mode docs).
No exploitation is reported. CISA's SSVC entry in NVD lists exploitation "none" and automatable "no" with technical impact "total", and the CVE was not in the CISA KEV catalog when we checked on 2026-10-04.
Technical details
In queue mode, n8n instances coordinate through Redis pub/sub commands. The n8n 2.40.1 source defines a community-package-install command carrying packageName, packageVersion and an optional checksum (alongside community-package-update and community-package-uninstall). Per the advisory, the handler reacting to this command trusted the message and skipped the validation that the REST install path enforces. A forged message therefore causes each instance to install and load the named package.
The advisory does not spell out what the package can do once loaded, and we have not confirmed it. Installing an npm package normally allows lifecycle scripts to run, and community packages are loaded as n8n nodes, so the practical expectation is code execution in the n8n process; treat that as inference, not a vendor statement (for the Python equivalent, see install-time code execution in PyPI packages). We did not confirm the exact Redis channel name from the advisory.
One forged Redis pub/sub message is enough in queue mode; Redis write access is the precondition.
Scores, both assigned by VulnCheck (NVD has not scored it; status is Deferred):
| Version | Score | Vector |
|---|---|---|
| CVSS 4.0 | 7.5 High | AV:A/AC:L/AT:P/PR:L/UI:N, VC:H/VI:H/VA:H |
| CVSS 3.1 | 7.1 High | AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H |
The weakness is CWE-862 (Missing Authorization). Note the two vectors differ on attack complexity (low in v4, high in v3.1).
What defenders should do
- Upgrade to 1.123.80, 2.39.6, 2.40.1 or later.
- Restrict Redis to trusted n8n components only: require authentication and use firewall rules or private networking. This is worth doing regardless of this CVE.
- If community nodes are not needed, set
N8N_COMMUNITY_PACKAGES_ENABLED=false. - Audit installed community packages on every main and worker instance for unexpected entries and remove them. Review Redis connections with
ACL LOGor your firewall or proxy logs; Redis keeps no access log by default. - Limit n8n instance access to trusted users.
The advisory states the workarounds "do not fully remediate the risk" and are short-term measures.
What is still unclear
- The exact pub/sub channel and handler code path are not described in the advisory.
- What a malicious package can do on load is not documented by the vendor.
- There is no public exploit or exploitation report that we found.
- The GitHub advisory record itself carries no CVE id; the link comes from the NVD and VulnCheck references.
- This CVE is one of a batch (CVE-2026-103245 through CVE-2026-103260) that VulnCheck published on 2026-10-01 for the same fixed versions, so upgrading addresses several unrelated n8n issues at once.