Go to packages list

n8n

Ecosystem: npm

Downloads: 519.19 K

Vulnerabilities from the last (months)
  • 24CriticalAffects 54 versions
  • 65HighAffects 148 versions
  • 0MediumAffects 0 versions
  • 85ModerateAffects 167 versions
  • 0LowAffects 0 versions
Severity distribution (all time)
174vulnerabilities
  • Critical24 (13.8%)
  • High65 (37.4%)
  • Medium0 (0.0%)
  • Moderate85 (48.9%)
  • Low0 (0.0%)

Monthly breakdown

  • Critical
  • High
  • Medium
  • Moderate
  • Low
  • 17 vulnerabilities
    • Critical: 0
    • High: 5
    • Medium: 0
    • Moderate: 12
    • Low: 0
  • 57 vulnerabilities
    • Critical: 0
    • High: 28
    • Medium: 0
    • Moderate: 29
    • Low: 0
  • 20 vulnerabilities
    • Critical: 0
    • High: 8
    • Medium: 0
    • Moderate: 12
    • Low: 0
  • 7 vulnerabilities
    • Critical: 3
    • High: 2
    • Medium: 0
    • Moderate: 2
    • Low: 0
  • 12 vulnerabilities
    • Critical: 2
    • High: 4
    • Medium: 0
    • Moderate: 6
    • Low: 0
  • 15 vulnerabilities
    • Critical: 2
    • High: 5
    • Medium: 0
    • Moderate: 8
    • Low: 0
  • 24 vulnerabilities
    • Critical: 11
    • High: 6
    • Medium: 0
    • Moderate: 7
    • Low: 0
  • 5 vulnerabilities
    • Critical: 3
    • High: 0
    • Medium: 0
    • Moderate: 2
    • Low: 0
  • 5 vulnerabilities
    • Critical: 3
    • High: 2
    • Medium: 0
    • Moderate: 0
    • Low: 0
  • 2 vulnerabilities
    • Critical: 0
    • High: 2
    • Medium: 0
    • Moderate: 0
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 2 vulnerabilities
    • Critical: 0
    • High: 1
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 2 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 2
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 3 vulnerabilities
    • Critical: 0
    • High: 2
    • Medium: 0
    • Moderate: 1
    • Low: 0

Vulnerabilities (174)

Known vulnerabilities affecting n8n, based on data from OSV.

Vulnerabilities affecting n8n
IDSeveritySummaryAffected versionsPublishedSource
GHSA-34ff-336r-5q23Highn8n: Domain-Restriction Bypass via Unguarded Model-Search Endpoint in OpenAI Chat Model Node## Impact The OpenAI Chat Model node checked a custom base URL against the credential's allowed-domains configuration before sending a request, but the model-search dropdown did not. A request setting `options.baseURL` on that path reached an arbitrary host with the credential attached, so the domain restriction an administrator configured did not hold for every route the node offered. The patch routes every OpenAI call site, including model listing, through one shared allowed-domains check. ## Patches The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgra
  • < 1.123.76
  • >= 2.38.0, < 2.38.2
  • >= 2.0.0, < 2.37.7
GitHub (opens in a new tab)
GHSA-35jj-42hp-8gmqModeraten8n: Anonymous Approval-Gate Bypass via Reused resumeToken over the Chat WebSocket## Impact The `/chat` WebSocket route resumed a paused execution from a resume token without checking that the node being resumed was a chat node. n8n hands that token to anonymous form submitters, so a party with no account could present it on the chat route and release an execution waiting at an approval gate, the control an author puts in front of an action considered too consequential to automate. The patch restricts resume over the chat route and Chat Hub to chat-capable node types. ## Patches The issue has been fixed in n8n versions 2.37.7 and 2.38.2. Users should upgrade to one of th
  • >= 2.38.0, < 2.38.2
  • < 2.37.7
GitHub (opens in a new tab)
GHSA-5m98-cgcr-xx3qModeraten8n: GitHub Trigger 422 Reuse Path Skips Webhook Secret Storage, Causing Signature Verification to Fail-Open## Impact The GitHub Trigger generated a signing secret when it registered a webhook and verified `X-Hub-Signature-256` on each delivery. When GitHub answered the create request with a 422 because a webhook for the URL already existed, the node adopted the remote hook but kept only its id and events, discarding the secret it had generated. Deliveries to that workflow's webhook URL were then accepted from anyone. The patch re-fetches the existing hook by its stored id, re-applies the signing secret, and makes verification fail closed when no secret is stored. ## Patches The issue has been fi
  • < 1.123.76
  • >= 2.38.0, < 2.38.2
  • >= 2.0.0, < 2.37.7
GitHub (opens in a new tab)
GHSA-65xw-2v52-jhxcModeraten8n: Cross-User Active Workflow ID and Lifecycle Event Disclosure via Missing userId Filter## Impact The endpoint `/rest/active-workflows` returned every active workflow ID on the instance to any member, regardless of sharing, and workflow activation, deactivation and publication push events were broadcast to every connected client, carrying workflow IDs, version IDs and activation-error detail across users. The patch scopes both the listing and the push events through the sharing service, so a user only sees workflows they can access. ## Patches The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remedi
  • < 1.123.76
  • >= 2.38.0, < 2.38.2
  • >= 2.0.0, < 2.37.7
GitHub (opens in a new tab)
GHSA-679f-58pq-4v2cModeraten8n: Prototype Pollution via Workflow Structure Summary Can Lead to Denial of Service## Impact The Instance AI workflow summary built its result with get-or-create-then-nested-write idioms keyed by node names and connection keys taken from the stored workflow. Those are arbitrary strings: the restricted-name guard n8n shows in the editor is client-side and is bypassed by posting the workflow to the REST API directly. So a reserved key such as `__proto__` resolved up the prototype chain instead of creating an own key, and the write landed on `Object.prototype` in the main n8n process, affecting every later request. The patch builds the summary with null-prototype accumulators
  • >= 2.38.0, < 2.38.2
  • < 2.37.7
GitHub (opens in a new tab)
GHSA-6xcw-7xm6-48c6Highn8n: Expression Sandbox Escape via Shared Builtin Tampering and Code-Printer Injection Leads to Code Execution## Impact Two stages of expression code generation built source text by calling the global `JSON.stringify` at generation time: the compiler when printing synthetic string literals, and the isolate bridge when interpolating a timezone value into its per-evaluation wrapper. An expression that replaced that global therefore changed the code that was subsequently generated and executed, turning literal data into executable source. The patch renders both code-generation stages through a reference captured at module load, so a later change to global state cannot alter the generated source. This v
  • < 1.123.76
  • >= 2.38.0, < 2.38.2
  • >= 2.0.0, < 2.37.7
GitHub (opens in a new tab)
GHSA-cqr2-h44g-v75vModeraten8n: Cross-Tenant Project-Member PII Disclosure via Missing Per-Project Scope Check on Role Assignment Endpoints## Impact The endpoints `/rest/roles/:slug/assignments` and `/rest/roles/:slug/assignments/:projectId/members` checked only that the caller could manage the role type, not that they could see the project named in the request. A user holding role-management permission could therefore name any project on the instance and read back its members' names and email addresses. The patch adds a project-access check to both routes, hiding projects the caller cannot see and returning not-found for a project it cannot list. ## Patches The issue has been fixed in n8n versions 2.38.2 and 2.37.7. Users sho
  • >= 2.38.0, < 2.38.2
  • < 2.37.7
GitHub (opens in a new tab)
GHSA-cw9w-vv67-hf73Moderaten8n: Per-Resource OAuth Consent Bypass via Unbound Refresh Token Resource Substitution## Impact The OAuth token endpoint bound an authorization code's first access token to the consented resource, but not its refresh token. Refreshing only checked that the requested resource was registered, not that it matched the original grant. An OAuth client approved for one workflow could refresh with a different workflow's URL and get a valid, unapproved token for it. The patch binds refresh tokens to the granted resource and rejects mismatches. Exploitation requires the attacker to register an OAuth client, convince an authenticated user to approve that client for one known protected r
  • >= 2.38.0, < 2.38.1
  • < 2.37.7
GitHub (opens in a new tab)
GHSA-f2cp-m7mv-8jpvModeraten8n: Path Injection in Elasticsearch and ElasticSecurity Nodes via Unencoded Identifiers## Impact The Elasticsearch and ElasticSecurity nodes built REST endpoints by interpolating user-provided identifiers straight into the request path. A value containing path separators or dot segments changed which endpoint the request actually reached, so an operation intended for one document could hit another index or a cluster administration endpoint instead, under the stored Elasticsearch credential. The patch encodes each identifier as a single URL path segment and rejects values that normalise away. ## Patches The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Use
  • < 1.123.76
  • >= 2.38.0, < 2.38.2
  • >= 2.0.0, < 2.37.7
GitHub (opens in a new tab)
GHSA-hh89-3r9w-qj3jHighn8n: Unauthenticated Persistent Storage Exhaustion via OAuth Dynamic Client Registration Endpoint## Impact The OAuth Dynamic Client Registration endpoints validated field sizes only for `redirect_uris`, leaving `client_name` and `grant_types` bounded by presence checks alone. An unauthenticated remote caller could submit arbitrarily large values in either field and have them persisted to the database. Repeated registration therefore grew persistent storage without limit and without any account on the instance. The patch caps `client_name` at its column length and limits `grant_types` to the grant types the server actually implements, with the array capped at that count. ## Patches The
  • >= 2.38.0, < 2.38.2
  • < 2.37.7
GitHub (opens in a new tab)
  • GHSA-34ff-336r-5q23High
    n8n: Domain-Restriction Bypass via Unguarded Model-Search Endpoint in OpenAI Chat Model Node
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • +1 more
    GitHub (opens in a new tab)
    Affected versions:
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • >= 2.0.0, < 2.37.7

    ## Impact The OpenAI Chat Model node checked a custom base URL against the credential's allowed-domains configuration before sending a request, but the model-search dropdown did not. A request setting `options.baseURL` on that path reached an arbitrary host with the credential attached, so the domain restriction an administrator configured did not hold for every route the node offered. The patch routes every OpenAI call site, including model listing, through one shared allowed-domains check. ## Patches The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgra

    CVE: CVE-2026-86082

  • GHSA-35jj-42hp-8gmqModerate
    n8n: Anonymous Approval-Gate Bypass via Reused resumeToken over the Chat WebSocket
    • >= 2.38.0, < 2.38.2
    • < 2.37.7
    GitHub (opens in a new tab)

    ## Impact The `/chat` WebSocket route resumed a paused execution from a resume token without checking that the node being resumed was a chat node. n8n hands that token to anonymous form submitters, so a party with no account could present it on the chat route and release an execution waiting at an approval gate, the control an author puts in front of an action considered too consequential to automate. The patch restricts resume over the chat route and Chat Hub to chat-capable node types. ## Patches The issue has been fixed in n8n versions 2.37.7 and 2.38.2. Users should upgrade to one of th

    CVE: CVE-2026-86077

  • GHSA-5m98-cgcr-xx3qModerate
    n8n: GitHub Trigger 422 Reuse Path Skips Webhook Secret Storage, Causing Signature Verification to Fail-Open
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • +1 more
    GitHub (opens in a new tab)
    Affected versions:
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • >= 2.0.0, < 2.37.7

    ## Impact The GitHub Trigger generated a signing secret when it registered a webhook and verified `X-Hub-Signature-256` on each delivery. When GitHub answered the create request with a 422 because a webhook for the URL already existed, the node adopted the remote hook but kept only its id and events, discarding the secret it had generated. Deliveries to that workflow's webhook URL were then accepted from anyone. The patch re-fetches the existing hook by its stored id, re-applies the signing secret, and makes verification fail closed when no secret is stored. ## Patches The issue has been fi

    CVE: CVE-2026-86080

  • GHSA-65xw-2v52-jhxcModerate
    n8n: Cross-User Active Workflow ID and Lifecycle Event Disclosure via Missing userId Filter
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • +1 more
    GitHub (opens in a new tab)
    Affected versions:
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • >= 2.0.0, < 2.37.7

    ## Impact The endpoint `/rest/active-workflows` returned every active workflow ID on the instance to any member, regardless of sharing, and workflow activation, deactivation and publication push events were broadcast to every connected client, carrying workflow IDs, version IDs and activation-error detail across users. The patch scopes both the listing and the push events through the sharing service, so a user only sees workflows they can access. ## Patches The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remedi

    CVE: CVE-2026-86994

  • GHSA-679f-58pq-4v2cModerate
    n8n: Prototype Pollution via Workflow Structure Summary Can Lead to Denial of Service
    • >= 2.38.0, < 2.38.2
    • < 2.37.7
    GitHub (opens in a new tab)

    ## Impact The Instance AI workflow summary built its result with get-or-create-then-nested-write idioms keyed by node names and connection keys taken from the stored workflow. Those are arbitrary strings: the restricted-name guard n8n shows in the editor is client-side and is bypassed by posting the workflow to the REST API directly. So a reserved key such as `__proto__` resolved up the prototype chain instead of creating an own key, and the write landed on `Object.prototype` in the main n8n process, affecting every later request. The patch builds the summary with null-prototype accumulators

    CVE: CVE-2026-86078

  • GHSA-6xcw-7xm6-48c6High
    n8n: Expression Sandbox Escape via Shared Builtin Tampering and Code-Printer Injection Leads to Code Execution
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • +1 more
    GitHub (opens in a new tab)
    Affected versions:
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • >= 2.0.0, < 2.37.7

    ## Impact Two stages of expression code generation built source text by calling the global `JSON.stringify` at generation time: the compiler when printing synthetic string literals, and the isolate bridge when interpolating a timezone value into its per-evaluation wrapper. An expression that replaced that global therefore changed the code that was subsequently generated and executed, turning literal data into executable source. The patch renders both code-generation stages through a reference captured at module load, so a later change to global state cannot alter the generated source. This v

    CVE: CVE-2026-86083

  • GHSA-cqr2-h44g-v75vModerate
    n8n: Cross-Tenant Project-Member PII Disclosure via Missing Per-Project Scope Check on Role Assignment Endpoints
    • >= 2.38.0, < 2.38.2
    • < 2.37.7
    GitHub (opens in a new tab)

    ## Impact The endpoints `/rest/roles/:slug/assignments` and `/rest/roles/:slug/assignments/:projectId/members` checked only that the caller could manage the role type, not that they could see the project named in the request. A user holding role-management permission could therefore name any project on the instance and read back its members' names and email addresses. The patch adds a project-access check to both routes, hiding projects the caller cannot see and returning not-found for a project it cannot list. ## Patches The issue has been fixed in n8n versions 2.38.2 and 2.37.7. Users sho

    CVE: CVE-2026-86085

  • GHSA-cw9w-vv67-hf73Moderate
    n8n: Per-Resource OAuth Consent Bypass via Unbound Refresh Token Resource Substitution
    • >= 2.38.0, < 2.38.1
    • < 2.37.7
    GitHub (opens in a new tab)

    ## Impact The OAuth token endpoint bound an authorization code's first access token to the consented resource, but not its refresh token. Refreshing only checked that the requested resource was registered, not that it matched the original grant. An OAuth client approved for one workflow could refresh with a different workflow's URL and get a valid, unapproved token for it. The patch binds refresh tokens to the granted resource and rejects mismatches. Exploitation requires the attacker to register an OAuth client, convince an authenticated user to approve that client for one known protected r

    CVE: CVE-2026-86073

  • GHSA-f2cp-m7mv-8jpvModerate
    n8n: Path Injection in Elasticsearch and ElasticSecurity Nodes via Unencoded Identifiers
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • +1 more
    GitHub (opens in a new tab)
    Affected versions:
    • < 1.123.76
    • >= 2.38.0, < 2.38.2
    • >= 2.0.0, < 2.37.7

    ## Impact The Elasticsearch and ElasticSecurity nodes built REST endpoints by interpolating user-provided identifiers straight into the request path. A value containing path separators or dot segments changed which endpoint the request actually reached, so an operation intended for one document could hit another index or a cluster administration endpoint instead, under the stored Elasticsearch credential. The patch encodes each identifier as a single URL path segment and rejects values that normalise away. ## Patches The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Use

    CVE: CVE-2026-86079

  • GHSA-hh89-3r9w-qj3jHigh
    n8n: Unauthenticated Persistent Storage Exhaustion via OAuth Dynamic Client Registration Endpoint
    • >= 2.38.0, < 2.38.2
    • < 2.37.7
    GitHub (opens in a new tab)

    ## Impact The OAuth Dynamic Client Registration endpoints validated field sizes only for `redirect_uris`, leaving `client_name` and `grant_types` bounded by presence checks alone. An unauthenticated remote caller could submit arbitrarily large values in either field and have them persisted to the database. Repeated registration therefore grew persistent storage without limit and without any account on the instance. The patch caps `client_name` at its column length and limits `grant_types` to the grant types the server actually implements, with the array capped at that count. ## Patches The

    CVE: CVE-2026-86075

Showing 1-10 of 174 vulnerabilities