n8n patches two server-takeover flaws rated CVSS 8.7 and 9.4 across three release lines

An n8n expression is a snippet such as `={{ $json.name }}` inside a node parameter. It is evaluated when the workflow runs ^[6]. The sandbox around it lets the snippet transform data. It is also supposed to keep the snippet off the server, stop it spawning processes and block the JavaScript `Function` constructor ^[6]. According to a dev.to write-up of n8n's advisory GHSA-hw8v-xxg5-vvvx, the expression compiler resolved its sanitizer through a dynamically scoped `this` ^[7]. That meant an expression could redefine the sanitizer. An attacker could declare a class field named `__sanitize`, rebind the sanitizer to a malicious value and reach the `Function` constructor ^[7].

To exploit it, the attacker has to write an expression. The write-up counts anyone who can create or edit a workflow as an expression author ^[11]. On an instance with one operator, the only author is the operator. On a shared instance, every client, contractor and junior team member with edit rights is an author. The write-up says those deployments should treat the upgrade as urgent ^[11].

The patch rejects reserved class-member names such as `__sanitize` ^[10]. It is a small change that is easy to review. I want that in a fix shipped on three release lines at once ^[4].

CVE-2026-44790 is harder to plan around. It has the higher score and a critical rating ^[3]. According to the write-up, n8n has published fewer details about it than about the sandbox escape ^[12]. The write-up does not say which input reaches the injected arguments, or what access an attacker needs first. It recommends patching both flaws in the same window ^[17]. The advisory metadata says vendor patches were already shipping in the fixed lines, so one upgrade covers both flaws ^[16].

Do the upgrade steps in this order:

1. Export `N8N_ENCRYPTION_KEY` from the running container into a secrets manager. Stored credentials are encrypted with this key. If an upgrade fails and the key is gone, those credentials stay locked ^[13]. 2. Back up the data store, which is a SQLite file or a Postgres database ^[13]. For Docker with a named volume, the write-up stops the container, tars the volume through a throwaway alpine container and starts n8n again. An external Postgres database gets a `pg_dump` instead ^[15]. A volume backup without the key restores credentials nobody can decrypt ^[13]. 3. Pull the fixed build for the release line you already run in production ^[4][14].