GHSA-hv7x-3x78-gx53

What it actually does

n8n's evaluations test-run creation endpoint enforces the wrong OAuth scope, so a caller with a valid token that lacks the intended privileged scope can still create evaluation test runs. This is broken access control on a write API: authentication can succeed while authorization is weaker than designed, allowing unauthorized creation of evaluation runs and associated workflow/evaluation state changes.

Why it matters to the business

Unauthorized operators or integrations can start evaluation test runs, consuming execution capacity, touching evaluation datasets or results, and weakening least-privilege OAuth for automation. The issue is not listed in CISA KEV, is not associated with ransomware campaigns, and has no reported in-the-wild exploit maturity, but it has been public for roughly four months—unpatched n8n instances remain an avoidable access-control gap for any team that exposes the API or issues scoped tokens.

How an attack unfolds

An attacker who already holds a legitimate n8n OAuth token (stolen, over-privileged, or issued for a narrower integration) authenticates to the API and calls the evaluations test-run creation endpoint. Because the handler checks an incorrect scope, the request is accepted even though the token should not be allowed to create test runs. The attacker can then create evaluation runs they were not granted, potentially observing or influencing evaluation activity. No public exploit maturity or named threat actors are associated with this issue; abuse depends on possessing a valid token and network reachability to the n8n API.

How to fix it

Upgrade n8n (npm) to a fixed release for your branch: 1.123.55 on the 1.x line, 2.25.7 on 2.25.x, or 2.26.2 (or later) on 2.26+. Prefer the newest supported fixed version on the branch you run. After upgrade, rotate OAuth client secrets and access tokens that could have been used against the evaluations API, review issued OAuth scopes so evaluation write access is granted only where required, and restrict API exposure (network allowlists, SSO, and least-privilege tokens) so a remaining scoped-token mistake cannot be reached from untrusted networks.

How to confirm the fix worked

Confirm the installed n8n package version is at or above 1.123.55 (1.x), 2.25.7 (2.25.x), or 2.26.2 (2.26+), for example via package lockfiles or `npm ls n8n`. In a staging instance, authenticate with a token that has only non-evaluation scopes and verify that creating an evaluation test run is denied; repeat with a correctly scoped token and confirm allowed behavior. Review OAuth client configurations so the evaluations write scope is required for that endpoint. Check reverse-proxy and application logs for successful POSTs to evaluation test-run creation routes from clients that should not hold that privilege.

Typical attack path

1. Obtain a valid n8n OAuth access token that is not intended to authorize evaluation test-run creation (for example via a limited integration, leaked credential, or overly broad token issuance).
2. Reach the n8n API over the network as an authenticated client.
3. Invoke the evaluations test-run creation endpoint with that token.
4. Bypass the intended scope check because the endpoint validates the wrong OAuth scope.
5. Create unauthorized evaluation test runs and follow-on evaluation activity permitted by that write.
6. Optionally persist access by repeating the same authorized-looking API calls, which may blend into normal automation traffic.

How to detect it

There is no public exploit kit or named actor activity to key on; look for already-successful abuse of the evaluations test-run creation API. Review n8n application logs, reverse-proxy/WAF access logs, and API gateway logs for authenticated create requests to evaluation test-run routes, especially from OAuth clients, service accounts, or users that should lack evaluation write permission. Correlate token/client IDs with your OAuth scope inventory. On the host, inspect n8n audit/workflow history for unexpected evaluation runs around and after mid-June 2026. Absence of matching logs does not prove non-exploitation if logging was incomplete.

• POST /rest/evaluations
• POST /api/v1/evaluations
• /evaluation-test-runs
• /evaluations/test-runs
• testRun
• test-run
• scope=
• oauth
• n8n
• evaluations

What your security team should do

• Patch n8n to 1.123.55, 2.25.7, or 2.26.2+ immediately on internet-reachable and multi-tenant instances, then remaining internal nodes.
• Inventory OAuth clients and tokens; revoke or rotate any that could call the evaluations API, and re-issue with least-privilege scopes.
• Limit n8n API exposure to trusted networks and identities; require SSO/MFA for human operators.
• Hunt historical API logs for evaluation test-run creation by tokens or users that should not have that permission.
• Add regression tests or API authorization checks so evaluation write endpoints reject tokens missing the correct scope after upgrade.
• Track this as standard patch hygiene rather than KEV/ransomware emergency, but do not defer given 100+ days of public disclosure.