Skip to main content
Vulnerability Database/CVE-2026-92716

CVE-2026-92716: Shuffle Cross-Tenant Privilege Escalation

CVE-2026-92716 is a cross-tenant privilege escalation flaw in Shuffle through version 2.2.1 that allows admins to access API keys across organizations. This post explains its impact, affected versions, and mitigation steps.

Updated:

CVE-2026-92716 Overview

CVE-2026-92716 is a cross-tenant privilege escalation vulnerability in Shuffle through version 2.2.1. The flaw resides in the HandleApiGeneration endpoint, which fails to validate that the target user belongs to the same organization as the requesting administrator. An authenticated admin in one tenant can supply arbitrary user IDs and reset the API keys of non-administrator users in other organizations. The returned key grants full account takeover across tenant boundaries. The vulnerability is classified as [CWE-639: Authorization Bypass Through User-Controlled Key].

Critical Impact

Any admin in a Shuffle deployment can reset and read API keys belonging to non-admin users in other organizations, enabling cross-tenant account takeover in shared or multi-tenant Shuffle instances.

Affected Products

  • Shuffle through 2.2.1
  • shuffle-shared library up to v1.2.50
  • Multi-tenant Shuffle SOAR deployments

Discovery Timeline

  • 2026-09-16 - CVE-2026-92716 published to NVD
  • 2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92716

Vulnerability Analysis

Shuffle is an open-source Security Orchestration, Automation, and Response (SOAR) platform that supports multi-organization tenancy. The HandleApiGeneration function in shared.go processes requests to regenerate a user's API key. The handler accepts a target UserId from the request body and looks up that user, but does not verify that the caller and target share the same organization context.

As a result, an administrator in Organization A can submit a request specifying the user ID of a non-administrator in Organization B. The server generates a new API key for that user and returns it in the response. The attacker then authenticates as the victim using the returned key and inherits their access to workflows, apps, secrets, and connected integrations.

Root Cause

The root cause is missing authorization on the target user object. Prior to the patch, the code checked whether the target user's role was admin before allowing the operation but did not compare foundUser.Id to userInfo.Id or validate organization membership. This is a classic Insecure Direct Object Reference where the user-controlled UserId parameter is trusted without an ownership check.

Attack Vector

Exploitation requires network access to the Shuffle API and valid admin credentials in any tenant on the instance. The attacker sends an authenticated request to the API key generation endpoint with a target user ID belonging to a different organization. No user interaction is required on the victim side, and the reset silently replaces the victim's key.

go
// Security patch in shared.go - fix: user api key generation logic
			return
		}

+		if foundUser.Id != userInfo.Id {
+			log.Printf("[AUDIT] %s tried and failed to change apikey for %s (1)", userInfo.Username, t.UserId)
+			resp.WriteHeader(401)
+			resp.Write([]byte(fmt.Sprintf(`{"success": false, "reason": "Can't change the apikey of another user"}`)))
+			return
+		}
+
		// FIXME: May not be good due to different roles in different organizations.
		if foundUser.Role == "admin" {
			log.Printf("[AUDIT] %s tried and failed to change apikey for %s. Skipping because users' role is admin", userInfo.Username, t.UserId)

Source: Shuffle shuffle-shared commit c1b582e. The patch introduces an identity check that rejects the request when the requesting user's ID does not match the target user's ID.

Detection Methods for CVE-2026-92716

Indicators of Compromise

  • Audit log entries showing API key regeneration events where the requesting admin and the target user belong to different organizations.
  • Unexpected apikey field changes on user records in the Shuffle datastore.
  • Sudden authentication activity from a user account using a new API key that the legitimate user did not request.
  • Workflow executions or app configurations modified by service accounts shortly after an API key rotation event.

Detection Strategies

  • Instrument the HandleApiGeneration endpoint with logging that records both userInfo.OrgId and the resolved foundUser.OrgId on every call and alert on mismatches.
  • Correlate API key rotation events with subsequent authentication events from new source IPs or user agents within a short time window.
  • Review historical HTTP access logs for POST requests to the API key generation route that reference user IDs not present in the caller's organization.

Monitoring Recommendations

  • Forward Shuffle application and audit logs to a centralized analytics pipeline for cross-tenant correlation.
  • Monitor for privilege escalation patterns such as a single admin account triggering key resets against multiple user IDs in rapid succession.
  • Alert on any use of legacy shuffle-shared versions at or below v1.2.50 in running deployments.

How to Mitigate CVE-2026-92716

Immediate Actions Required

  • Upgrade Shuffle and the shuffle-shared dependency to a version that includes commit c1b582e91b429bc7d5ad02e6c22f98234ec67615 or later.
  • Rotate API keys for all non-administrator users across every tenant on the instance to invalidate any keys that may have been silently reset.
  • Audit admin accounts across all organizations and revoke any that are unnecessary or shared between tenants.

Patch Information

The fix is committed in the shuffle-shared repository under commit c1b582e91b429bc7d5ad02e6c22f98234ec67615. It adds an explicit check that foundUser.Id == userInfo.Id before allowing an API key regeneration, returning HTTP 401 and writing an audit log entry when the check fails. Refer to the VulnCheck advisory for Shuffle and the Shuffle source repository for release details.

Workarounds

  • Restrict network access to the Shuffle API to trusted administrative networks until patching is complete.
  • Reduce the number of accounts with admin role across tenants to limit the blast radius of the vulnerability.
  • Deploy a reverse-proxy rule that blocks requests to the API key generation endpoint when the request body contains a user ID outside the caller's known organization scope.
bash
# Example: pin shuffle-shared to a patched version in go.mod
require github.com/shuffle/shuffle-shared v1.2.51

# Verify the running version after upgrade
go list -m github.com/shuffle/shuffle-shared

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.