CVE-2026-59563: Zscaler MCP Server Auth Bypass Vulnerability

CVE-2026-59563 Overview

CVE-2026-59563 affects Zscaler MCP Server versions 0.7.0 and 0.7.1. The flaw stems from HMAC confirmation tokens that are not bound to the target resource identifier. A Model Context Protocol (MCP) client or agent can replay a token issued for one resource against a different resource of the same type. This weakness falls under [CWE-305: Authentication Bypass by Primary Weakness]. Zscaler fixed the issue in version 0.7.2.

Critical Impact
An authenticated MCP client can reuse a valid confirmation token to perform actions on an unintended resource, undermining per-resource authorization controls.

Affected Products

Zscaler MCP Server version 0.7.0
Zscaler MCP Server version 0.7.1
Fixed in Zscaler MCP Server version 0.7.2

Discovery Timeline

2026-09-28 - CVE-2026-59563 published to the National Vulnerability Database (NVD)
2026-09-28 - Last updated in NVD

Technical Details for CVE-2026-59563

Vulnerability Analysis

The Zscaler MCP Server issues HMAC-based confirmation tokens to validate sensitive actions requested by MCP clients or agents. In vulnerable builds, the token's signed payload omits the target resource identifier. The server therefore accepts any token of the correct type and signature, regardless of which resource the token was originally generated for. An attacker who controls or influences an MCP client can capture a legitimate token and replay it against a sibling resource. The result is an authorization bypass that lets the client affect resources beyond the one the operator intended to confirm.

Root Cause

The underlying defect is missing resource-scope binding in the HMAC payload. Confirmation tokens must cryptographically bind to the resource identifier they authorize. Without that binding, the token functions as a generic capability for the resource class rather than for a single instance. The upstream fix in GitHub Pull Request #41 adds the resource identifier to the signed payload and validates it on redemption.

Attack Vector

Exploitation requires network access to the MCP server and a client with low-level privileges. The attacker needs an existing valid token issued to a legitimate client, plus user interaction to initiate a second confirmation flow. The attacker then substitutes the captured token when confirming an action against a different resource of the same type. See the vendor's GitHub Pull Request for Zscaler MCP Server for the technical fix details.

Detection Methods for CVE-2026-59563

Indicators of Compromise

Repeated use of the same HMAC confirmation token value across requests targeting different resource identifiers.
Confirmation requests where the resource identifier in the request body differs from the resource context under which the token was originally issued.
MCP server audit entries showing successful confirmations without a preceding token-generation event for that specific resource.

Detection Strategies

Correlate token issuance events with token redemption events and alert when the redeemed token's associated resource identifier does not match the issuance context.
Baseline normal MCP client behavior and flag clients that submit confirmation tokens against unexpected resources.
Review Zscaler MCP Server logs for versions 0.7.0 and 0.7.1 running in production and prioritize upgrade verification.

Monitoring Recommendations

Enable verbose logging on the MCP server for token generation and confirmation flows, including resource identifiers.
Forward MCP server logs to a centralized analytics platform for cross-session correlation of token reuse patterns.
Monitor for anomalous bursts of confirmation activity from a single MCP agent or client identity.

How to Mitigate CVE-2026-59563

Immediate Actions Required

Upgrade Zscaler MCP Server to version 0.7.2 or later, which binds HMAC confirmation tokens to the target resource identifier.
Inventory all MCP Server deployments to confirm no instances remain on 0.7.0 or 0.7.1.
Rotate any long-lived credentials or signing keys used by vulnerable MCP Server deployments as a precaution.

Patch Information

Zscaler addressed the issue in Zscaler MCP Server version 0.7.2. The fix is tracked in GitHub Pull Request #41 and modifies the HMAC payload to include and validate the resource identifier during token redemption.

Workarounds

Restrict network access to the MCP server so that only trusted MCP clients and agents can reach the confirmation endpoints.
Require operator review of all confirmation actions in sensitive workflows until the upgrade is complete.
Reduce token lifetimes and invalidate tokens immediately after a single successful use to limit replay windows.

bash

# Configuration example
# Upgrade Zscaler MCP Server to the fixed release
pip install --upgrade "zscaler-mcp-server==0.7.2"

# Verify the installed version
python -c "import importlib.metadata; print(importlib.metadata.version('zscaler-mcp-server'))"