The n8n-mcp local workflow-backup authorization reused the original n8n API-key value as a lasting access identity without checking whether that key was still valid. An actor must possess a formerly valid key and request backup data from the affected adapter; this does not mean the key still grants access to the live n8n API. The revoked key could continue…
Inspect the ClaimsCase · DiggingBeagle record
n8n-mcp workflow backups remained accessible after source API-key revocation
The n8n-mcp local workflow-backup authorization reused the original n8n API-key value as a lasting access identity without checking whether that key was still valid. The revoked key could continue listing, reading or deleting retained local backup versions until their separate retention or authorization expired.
Scope
An actor must possess a formerly valid key and request backup data from the affected adapter; this does not mean the key still grants access to the live n8n API. The risk applies to retained backups, not automatic reactivation of a revoked token at the upstream n8n service.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
The cited primary technical report or advisory supports the stated mechanism within its reported scope. The assessment does not infer a production breach, a victim count or a comparable impact score from a laboratory result. A maintainer or advisory names a patched release; that does not prove every deployed instance has updated. Boundary: Revoking the upstream n8n API key does not revoke a backup credential cached and authorized by the separate n8n-mcp adapter unless the adapter checks current grant state.
Assessed Oct 29, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-CP23-N8NMCP-STALE-BACKUP-KEY-1 · CLM-ENRICH-20261029-26 · n8n-mcp backup access after n8n key revocation advisory
At a glance
The revoked key could continue listing, reading or deleting retained local backup versions until their separate retention or authorization expired.
Read the implicationsThe risk applies to retained backups, not automatic reactivation of a revoked token at the upstream n8n service.
Limits and uncertaintyFull account
The n8n-mcp local workflow-backup authorization reused the original n8n API-key value as a lasting access identity without checking whether that key was still valid.
An actor must possess a formerly valid key and request backup data from the affected adapter; this does not mean the key still grants access to the live n8n API. The revoked key could continue listing, reading or deleting retained local backup versions until their separate retention or authorization expired.
The risk applies to retained backups, not automatic reactivation of a revoked token at the upstream n8n service. Upgrade n8n-mcp to 2.99.0 or later and bind backup access to current authenticated principal and explicit revocation state.
Evidence interpretation and control boundary. Revoking the upstream n8n API key does not revoke a backup credential cached and authorized by the separate n8n-mcp adapter unless the adapter checks current grant state. The reproducible boundary is a locally retained backup API after upstream access was disabled. A post-revocation operation should be tested for list, read and delete separately; it is not evidence that revoked credentials still access the live n8n service.
Mechanism and trust boundary
- 01
Step
- 02
Step
- 03
Step
Claims & evidence
CLM-ENRICH-20261029-26The n8n-mcp advisory describes locally stored workflow backup access continuing after its associated source n8n API key was revoked, without restoring privileges to the live n8n server.supported
Basis: reported finding
- supportsn8n-mcp backup access after n8n key revocation advisoryprimary disclosure
GHSA-74hp-7jv7-vx4j: local backup access checks, key revocation and patched release
CLM-CP23-N8NMCP-STALE-BACKUP-KEY-1The n8n-mcp local workflow-backup authorization reused the original n8n API-key value as a lasting access identity without checking whether that key was still valid. An actor must possess a formerly valid key and request backup data from the affected adapter; this does not mean the key still grants access to the live n8n API. The revoked key could continue listing, reading or deleting retained local backup versions until their separate retention or authorization expired.supported
Basis: reported finding
- supportsn8n-mcp backup access after n8n key revocation advisoryprimary disclosure
GHSA-74hp-7jv7-vx4j: local backup access checks, key revocation and patched release
Implications
The revoked key could continue listing, reading or deleting retained local backup versions until their separate retention or authorization expired.
Controls and mitigations
- Upgrade n8n-mcp to 2.99.0 or later and bind backup access to current authenticated principal and explicit revocation state.
Unknowns and contradictions
- The risk applies to retained backups, not automatic reactivation of a revoked token at the upstream n8n service.
Sources and citation
Material revision history
- Oct 29, 2026 · Canonical change recorded · new in release · revision 202