n8n Git node argument injection allows arbitrary file read

CVE-2026-44790 is an *argument injection* flaw in n8n's Git node during the Push operation. A user who can create or modify workflows can smuggle extra CLI flags into the underlying git command, turning a normal source-control action into arbitrary file read on the n8n server. The reviewed sources point to affected ranges of all 1.x before 1.123.43, 2.0.0-rc.0 through 2.20.6, and 2.21.0 through 2.22.0, with fixes in 1.123.43, 2.20.7, and 2.22.1.

The vendor advisory scores it as critical, but operationally that overshoots reality for most enterprises. This is *not* unauthenticated internet RCE; it requires authenticated access plus workflow-edit capability plus reachability to the Git node push path, which makes it a post-initial-access or insider-abuse problem. The impact is absolutely ugly once those prerequisites are met, but the attacker-position friction is strong enough to land this at = ASSESSED AT HIGH rather than CRITICAL.

Why this verdict

• Downward pressure: requires authenticated remote access — this is not unauthenticated internet exploitation; the attacker must already be in the app.
• More downward pressure: requires workflow creation or editing rights — that implies a specific role, not just any session, which narrows the reachable victim population in real deployments.
• Additional friction: Git node push path must be present and usable — many enterprises will not expose or rely on this exact node path in every instance.
• Upward pressure: blast radius is bigger than 'just file read' — on n8n, arbitrary file read usually means secrets theft, and secrets on an automation hub often unlock the host and downstream SaaS or databases.
• No exploitation evidence to force CRITICAL — no KEV listing and no reviewed public PoC means there is no current pressure to override the role-based friction.

Why not higher?

CRITICAL should be reserved for things defenders can expect to be hit from the outside with minimal preconditions or for flaws already being exploited at scale. This one needs a valid account plus workflow-edit capability and a relevant node path, so the reachable attacker population is meaningfully smaller than the vendor-style impact score suggests.

Why not lower?

Dropping this to MEDIUM would understate the consequences once the prerequisites are met. n8n is an orchestration hub that routinely stores privileged credentials, so arbitrary host file read can become tenant-wide or environment-wide compromise with very little extra work.

1. Restrict workflow editing to trusted admins — Treat this as the primary choke point because the exploit dies without workflow create/edit rights. Review RBAC, remove editor rights from standard users and service identities, and complete that access reduction within 30 days.
2. Disable the Git node where not required — Add n8n-nodes-base.git to NODES_EXCLUDE on instances that do not genuinely need Git operations. This directly removes the vulnerable execution path and should be deployed within 30 days if patch rollout is not immediate.
3. Put n8n behind strong identity controls — Enforce SSO, MFA, IP allowlists/VPN, and session monitoring on all self-hosted n8n admin surfaces. This does not fix the bug, but it materially raises the bar for reaching the authenticated prerequisite and should be enforced within 30 days.
4. Run n8n with least OS privilege — Use a dedicated low-privilege service account, minimize mounted secrets, and keep filesystem permissions tight so arbitrary file read returns less useful material. This is blast-radius reduction, not remediation, and should be implemented within 30 days on high-value deployments.
5. Audit and rotate exposed secrets after suspected abuse — Because the exploit path is file read, assume .env, tokens, SSH keys, and integration credentials may have been copied if you find suspicious workflow changes. Prioritize rotation of secrets reachable by the n8n process within 30 days, faster if compromise indicators exist.

Run this on the target n8n host or inside the n8n container; non-root is fine as long as you can execute n8n --version or read the installed package.json. Example: bash check_cve_2026_44790.sh or bash check_cve_2026_44790.sh /usr/local/lib/node_modules/n8n/package.json.

#!/usr/bin/env bash
# check_cve_2026_44790.sh
# Detects whether the installed n8n version falls in the vulnerable ranges for CVE-2026-44790.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

get_version() {
  local pkg_path="${1:-}"

  if [ -n "$pkg_path" ] && [ -f "$pkg_path" ]; then
    local v
    v=$(grep -E '"version"[[:space:]]*:' "$pkg_path" 2>/dev/null | head -n1 | sed -E 's/.*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/')
    if [ -n "$v" ]; then
      echo "$v"
      return 0
    fi
  fi

  if command -v n8n >/dev/null 2>&1; then
    local v
    v=$(n8n --version 2>/dev/null | head -n1 | tr -d '\r')
    if [ -n "$v" ]; then
      echo "$v"
      return 0
    fi
  fi

  for p in \
    /usr/local/lib/node_modules/n8n/package.json \
    /opt/n8n/package.json \
    /home/node/.n8n/package.json \
    ./package.json; do
    if [ -f "$p" ]; then
      local v
      v=$(grep -E '"version"[[:space:]]*:' "$p" 2>/dev/null | head -n1 | sed -E 's/.*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/')
      if [ -n "$v" ]; then
        echo "$v"
        return 0
      fi
    fi
  done

  return 1
}

normalize() {
  echo "$1" | tr -d '[:space:]' | sed 's/^v//' | sed 's/+.*$//'
}

main() {
  local raw_version
  if ! raw_version=$(get_version "${1:-}"); then
    echo "UNKNOWN - could not determine installed n8n version"
    exit 2
  fi

  local version
  version=$(normalize "$raw_version")
  local base="${version%%-*}"

  IFS='.' read -r major minor patch <<< "$base"

  if ! [[ "$major" =~ ^[0-9]+$ && "$minor" =~ ^[0-9]+$ && "$patch" =~ ^[0-9]+$ ]]; then
    echo "UNKNOWN - unrecognized version format: $raw_version"
    exit 2
  fi

  # Vulnerable ranges gathered from reviewed sources:
  #   1.x < 1.123.43
  #   2.0.0-rc.0 through 2.20.6
  #   2.21.0 through 2.22.0
  # Fixed:
  #   1.123.43+
  #   2.20.7+
  #   2.22.1+

  if [ "$major" -eq 0 ]; then
    echo "VULNERABLE - n8n version $raw_version"
    exit 1
  fi

  if [ "$major" -eq 1 ]; then
    if [ "$minor" -lt 123 ] || { [ "$minor" -eq 123 ] && [ "$patch" -lt 43 ]; }; then
      echo "VULNERABLE - n8n version $raw_version"
      exit 1
    else
      echo "PATCHED - n8n version $raw_version"
      exit 0
    fi
  fi

  if [ "$major" -eq 2 ]; then
    if [ "$minor" -lt 20 ]; then
      echo "VULNERABLE - n8n version $raw_version"
      exit 1
    elif [ "$minor" -eq 20 ]; then
      if [ "$patch" -lt 7 ]; then
        echo "VULNERABLE - n8n version $raw_version"
        exit 1
      else
        echo "PATCHED - n8n version $raw_version"
        exit 0
      fi
    elif [ "$minor" -eq 21 ]; then
      echo "VULNERABLE - n8n version $raw_version"
      exit 1
    elif [ "$minor" -eq 22 ]; then
      if [ "$patch" -lt 1 ]; then
        echo "VULNERABLE - n8n version $raw_version"
        exit 1
      else
        echo "PATCHED - n8n version $raw_version"
        exit 0
      fi
    else
      echo "PATCHED - n8n version $raw_version"
      exit 0
    fi
  fi

  if [ "$major" -gt 2 ]; then
    echo "PATCHED - n8n version $raw_version"
    exit 0
  fi

  echo "UNKNOWN - unable to classify n8n version $raw_version"
  exit 2
}

main "$@"

Sources

1. n8n GitHub Security Advisory GHSA-57g9-58c2-xjg3
2. n8n Security Overview
3. GitLab Advisory Database for CVE-2026-44790
4. CISA Known Exploited Vulnerabilities Catalog
5. Black Kite analysis of May 2026 n8n vulnerabilities
6. SecurityOnline coverage of n8n node vulnerabilities
7. FIRST EPSS project