GHSA-664h-gpgq-h6xx

What it actually does

n8n evaluation test-run API endpoints enforce an incorrect OAuth scope, so an already-authenticated caller whose token lacks the intended evaluation permission can still invoke those endpoints. This is an authorization-bypass (broken object/function-level authorization) that can expose or alter evaluation test-run records, associated metadata, and related test artifacts that should have been gated by the proper scope. It does not by itself grant unauthenticated access, remote code execution, or a full privilege escalation to instance administration.

Why it matters to the business

Organizations using n8n for workflow or AI evaluations can have evaluation results, test datasets, and process details disclosed to users or integrations that were only meant to have weaker API access. Impact is typically confidentiality and limited integrity of evaluation data rather than full platform takeover. Severity is moderate (CVSS 5.4), the issue is not listed in CISA KEV, ransomware use is not reported, and public exploit maturity is none; patches have been available for about four months, so residual risk is mainly unpatched n8n deployments that expose the evaluation APIs.

How an attack unfolds

An attacker who already holds a valid n8n API or OAuth credential with some scopes—but not the evaluation-related scope those endpoints were supposed to require—sends otherwise ordinary authenticated requests to evaluation test-run operations. Because the endpoints check the wrong scope, the server authorizes the call and returns or updates test-run data. Abuse is limited to what those evaluation endpoints can read or change and depends on the attacker already having a live token or account; there is no indication of in-the-wild campaigns or named threat actors targeting this issue.

How to fix it

Upgrade n8n to a fixed release for your line: 1.123.55 on the 1.x line, 2.25.7 on 2.25.x, or 2.26.2 (or later) on 2.26.x and above. After upgrading, rotate API keys and OAuth client secrets that may have been used against evaluation endpoints, review which tokens are granted evaluation-related scopes, and restrict evaluation APIs to identities that actually need them. If you cannot patch immediately, disable or tightly ACL evaluation/test-run features and avoid issuing broad OAuth tokens to untrusted automations.

How to confirm the fix worked

Confirm the running n8n package version is 1.123.55, 2.25.7, 2.26.2, or a later patched build. With a test token that deliberately omits evaluation scopes, verify evaluation test-run operations now return authorization failures (for example HTTP 401/403) rather than test-run data. Repeat with a correctly scoped token to confirm legitimate access still works. Inventory npm/lockfile and container images for unpatched n8n and re-scan after deployment.

Typical attack path

1. Obtain or reuse a legitimate n8n API or OAuth token that is missing the evaluation-related scope
2. Authenticate to an n8n instance that still runs an affected version and has evaluation features enabled
3. Call evaluation test-run operations that incorrectly accept the weaker scope
4. Read or modify evaluation test-run records and related metadata the token should have been denied
5. Use any exposed evaluation content for further reconnaissance of workflows or test data

How to detect it

There are no public exploit signatures or named actor TTPs for this issue. Hunt historically (around and after 2026-06-17) in n8n application, reverse-proxy, and API gateway logs for authenticated calls to evaluation or test-run APIs from users, service accounts, or OAuth clients that were not granted evaluation permission. Flag successful (2xx) responses to those operations from under-privileged identities, unusual spikes in evaluation test-run list/read/update activity, and tokens used only for unrelated scopes that suddenly touch evaluation resources. Compare identity-to-scope mappings from your IdP or n8n credential store against those log hits; absence of matching evaluation scope on a successful call is the primary indicator of abuse of this bug.

What your security team should do

• Patch all n8n instances to 1.123.55, 2.25.7, or 2.26.2+ as soon as change control allows
• Inventory OAuth clients and API tokens and remove unused or overly broad scopes
• Review audit and API logs for historical evaluation test-run access by identities that should not have had evaluation permission
• Disable or network-restrict evaluation features on internet-facing or multi-tenant n8n nodes until patched
• Add a version-control/check to CI and image pipelines so unpatched n8n cannot be redeployed