n8n published security bulletins on October 1 and October 14, 2026, and both fixed several high-severity vulnerabilities. If you use n8n Cloud, n8n has already patched your instance and there is nothing to do. If you self-host, the upgrade is on you: stable users should be on 2.43.5 or later, anyone still on 1.x should be on 1.123.85 or later, and beta users on 2.44.1 or later. n8n has shipped newer releases since then, so the simplest move is to go straight to the latest version on your release line. Below is what the two bulletins fixed, which setups should move first, and how to upgrade a Docker install without breaking things.
Compiled from n8n's official community security advisories and GitHub release notes as of October 23, 2026. For exact details and affected versions, the official advisories are the reference.
What the two October bulletins fixed
The October 1 bulletin's high-severity items include SQL injection in the Microsoft SQL node through expression interpolation into the query field, an HMAC bypass in Send and Wait that let unauthenticated users approve waiting executions, and code execution through the Git node's log operation. The fixed versions are 1.123.83 on the 1.x line, 2.41.4 on stable and 2.42.1 on beta.
The October 14 bulletin's high-severity items include prototype pollution in workflow history compaction that can take the service down, stored cross-site scripting through webhook responses served without the sandbox policy, a crafted workflow ID that gives access to data tables in other projects, and credential secrets showing up in the execution error data of several nodes. The medium-severity items include Slack token exfiltration and SSRF through the Slack Trigger webhook. The fixed versions are 1.123.85 on 1.x, 2.43.5 on stable and 2.44.1 on beta. This bulletin states that n8n Cloud instances were patched automatically.
In practice, upgrading to the October 14 fixed versions or anything newer covers both bulletins. This also isn't the first advisory of the year: in January, the n8n blog published one covering versions 1.65 to 1.120.4. If you self-host, regular upgrades belong in your routine.
Which setups should move first
If your n8n exposes public webhooks, or you use Send and Wait for approvals, upgrade first. Those issues are reachable from outside. A workflow that sends an approve or reject button by email or chat and waits for a manager to click it could, before the patch, be approved by someone who never logged in.
Teams that share one n8n and separate access with projects should pay attention to the cross-project data table issue: until you patch, data may not be as separated between projects as you think. The credential exposure in error data affects anyone who can see executions. If many people on your team can open execution logs, or you have pasted error screenshots to someone, rotating the API keys for important services after upgrading is the safer call. If you use the Microsoft SQL, Git or Slack Trigger nodes, make sure the upgrade actually landed.
Check which version you are running
n8n is currently patching three release lines: 1.x (the 1.123 series), 2.x stable and 2.x beta. On Docker, open docker-compose.yml and look at the tag after the n8n image. If it says latest, you are running whatever was latest the last time you pulled, not necessarily today's release. You can check directly on the server with docker exec your-container n8n --version.
Upgrading a Docker install safely
- Back up first. With SQLite, copy the .n8n folder; with PostgreSQL, take a database dump. You can also export workflows and credentials separately with
n8n export:workflow --allandn8n export:credentials --all; credentials are exported encrypted by default. - Make sure you still have the encryption key. Credentials are encrypted with N8N_ENCRYPTION_KEY (if you never set it, n8n saved a key in the config file inside the .n8n folder). If you rebuild the container or move servers without it, none of your credentials will decrypt.
- Pin the image to an explicit version, for example 2.43.5 or later on stable, instead of latest; it also makes rolling back clearer. Then run
docker compose pullfollowed bydocker compose up -d. - After the upgrade, run a few of your most-used workflows by hand, confirm webhooks arrive and schedules fire, and check the execution log for new errors. If something breaks, set the version back and restore the backup you just took.
If you are still on 1.x, patch within the 1.x line first by moving to 1.123.85 or later. Going from 1.x to 2.x is a major upgrade with its own official change notes; read them and schedule it separately instead of bundling it with a security patch.
If you would rather not chase every bulletin yourself
Self-hosting is still the most flexible option. It suits people who know Docker, run a modest number of workflows and are willing to set aside regular maintenance time. Subscribe to the security advisories category on the official forum and schedule an upgrade whenever a bulletin lands. For what doing it yourself really costs, see Is self-hosting n8n actually cheaper?
On n8n Cloud, patching is n8n's job, and this bulletin confirms Cloud users need to do nothing. Cloud bills by workflow executions, so do the math if your workflows run often; the differences are covered in n8n self-hosted vs n8n Cloud.
The third route is a managed service. RoamerHost's managed n8n runs in its own container with automatic updates, automatic backups, 24/7 monitoring and auto-restart, and no caps on executions or workflows. It is NT$5,988 billed yearly (NT$499 a month on average) and is ready about 60 seconds after payment. You can export your workflows as JSON at any time, so you are not locked in; plan details are on the managed n8n page. If your n8n currently runs on Zeabur, which has announced it will shut down at the end of the year, read our Zeabur migration guide and move your workflows and keys together.
FAQ
Q: I use n8n Cloud. Do I need to do anything?
No upgrade is needed. The October 14 bulletin says Cloud instances were patched automatically. If many people on your team can see execution logs and you are worried credentials appeared in error data, you can decide whether to rotate important API keys.
Q: Do I have to move to 2.x?
Not right away. Both bulletins also patched the 1.x line, so 1.123.85 or later covers both. 2.x is a separate major version; move once you have read the official change notes and tested your workflows.
Q: Will upgrading break my workflows?
Upgrades within one release line usually change less than a jump between major versions, but back up first and run your key workflows by hand afterward. If something breaks, set the image back to the old version and restore the backup. Changing only the version without restoring the database can fail, because the newer release may already have changed the tables.
Q: Where do I find the next bulletin?
n8n's community forum has a security advisories category where every bulletin is posted, and the GitHub security advisories page lists each vulnerability with its affected versions.
Sources
- n8n community forum: Security update, October 1, 2026, Security update, October 14, 2026, Security advisories category
- n8n on GitHub: Releases, Security advisories
- n8n blog: January 2026 security advisory (versions 1.65 to 1.120.4), Introducing n8n 2.0
- RoamerHost: Managed n8n plans and FAQ
n8n
