Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to Zscaler MCP Server (PR:L)
-
DeliveryRequest confirmation token for a legitimate delete
-
ExploitReuse unbound HMAC token on different same-type resource
-
ExecutionServer accepts replayed token
-
ImpactUnauthorized resource deletion (I:L/A:L)
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Primary weakness mitigation
|
| Exploitation Conditions | Requires an authenticated MCP client or agent (PR:L) already interacting with the Zscaler MCP Server's confirmation-token workflow and possessing a valid HMAC confirmation token for a delete operation on affected services (ZPA, ZIA, or ZTW). The specific enabling defect is that delete operations passed empty parameters ({}) to check_confirmation(), so the resulting HMAC-SHA256 tokens are fungible and replayable across any other resource of the same type. Limiting factors: exploitation is confined to same-type resources, needs prior authenticated access and a legitimately issued token (UI:R), and affects only versions 0.7.0/0.7.1 - patched in 0.7.2, which binds the specific resource identifier into the HMAC payload. |
| Impact | This is a genuinely moderate-to-low real-world risk. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:L, base 4.6) tells a coherent story: exploitation requires an already-authenticated MCP client/agent (PR:L) holding a valid confirmation token, some interaction from the agent workflow (UI:R), and yields only partial integrity and availability impact with NO confidentiality loss (C:N). There is no EPSS score, no CISA KEV listing, and no public exploit code provided - so this is 'no public exploit identified at time of analysis'. This is NOT a high-CVSS-but-hyped issue; it is correctly scored low. Two signals conflict with the input metadata: (1) the input Tag 'Information Disclosure' contradicts the CVSS vector's C:N - this is an integrity/availability weakness (unauthorized cross-resource deletion via replayed confirmation tokens), not disclosure; (2) NVD assigns CWE-305 (Authentication Bypass by Primary Weakness) while the vendor's own fix PR describes it as CWE-345 (Insufficient Verification of Data Authenticity), which better matches the 'HMAC token not bound to resource' root cause. The vulnerability is vendor-self-reported and fully patched in 0.7.2, further reducing urgency. |
| Exploit ScenarioDerived | An authenticated operator or AI agent using the Zscaler MCP Server obtains a valid HMAC-SHA256 confirmation token for a legitimate delete operation on one resource (e.g. a specific ZPA/ZIA/ZTW object). Because the token is generated from empty parameters and is not bound to a resource identifier, the client replays that same token against a different resource of the same type to confirm and execute an unintended deletion. No public exploit code is identified; exploitation requires existing authenticated access to the MCP server and its confirmation workflow. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 28, 2026
Replay of HMAC confirmation tokens in Zscaler MCP Server 0.7.0 and 0.7.1 lets an authenticated MCP client or agent reuse a confirmation token minted for one resource to authorize a destructive delete against a different resource of the same type. Because the affected delete handlers called check_confirmation() with empty parameters ({}), the resulting HMAC-SHA256 tokens carried no binding to the target resource identifier, making them fungible across 31 delete operations in the ZPA, ZIA, and ZTW service modules. The vendor addressed the issue by binding the resource identifier into the HMAC payload and shipping regression tests (including AST-based static analysis) in version 0.7.2; there is no KEV listing, and no public exploit identified at time of analysis, with the moderate CVSS score of 4.6 (AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:L) reflecting that exploitation requires prior authenticated access, a legitimately issued token, and is limited to same-type resources.
RemediationAI
Vendor-released patch: 0.7.2 - upgrade Zscaler MCP Server from 0.7.0 or 0.7.1 to 0.7.2, which binds the resource identifier into the HMAC confirmation payload; the change and release notes are at https://github.com/zscaler/zscaler-mcp-server/pull/41. If immediate upgrade is not possible, reduce exposure by restricting which services the server loads: use the --disabled-services CLI flag or the ZSCALER_MCP_DISABLED_SERVICES environment variable (accepted values include zcc, zdx, zia, zpa, ztw, zid) to unload ZPA, ZIA, and ZTW tooling, which removes the vulnerable delete paths at the cost of losing that automation entirely. Additionally, restrict network reachability of the MCP server to trusted clients, treat a confirmation prompt as non-transferable at the human-process level (do not approve deletes on behalf of another session), and monitor Zscaler audit logs for delete operations whose resource does not match the originally confirmed target - the trade-off being that audit-only controls are detective rather than preventive and depend on log ingestion latency. After upgrading, rotate any long-lived Zscaler OneAPI credentials used by affected server instances as a precaution, since the integrity assumption of the confirmation workflow was violated for the vulnerable period.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Zscaler MCP Server exposes Zscaler platform services (ZPA, ZIA, ZTW, and others) to Model Context Protocol clients and autonomous agents. Its destructive operations use a human-in-the-loop confirmation workflow in which check_confirmation() produces an HMAC-SHA256 token that the client echoes back to authorize the action. In versions 0.7.0 and 0.7.1 that function was invoked with an empty parameter dictionary, so the signed payload was identical regardless of which resource was about to be deleted. The root cause is a broken binding between a cryptographic authorization artifact and the object it authorizes - the CVE record classifies this as CWE-305 (Authentication Bypass by Primary Weakness), while the vendor's own changelog for PR #41 describes it as CWE-345 (Insufficient Verification of Data Authenticity); both framings converge on the same defect, namely that token validity was checked without verifying it was issued for the specific target resource. As a result, any token legitimately obtained for a delete on one resource is equally valid for any other resource of the same type within the affected services, undermining the integrity guarantee the confirmation step is meant to provide. The upstream fix binds the specific resource identifier into the HMAC payload and adds six regression tests plus static analysis to prevent reintroduction. Impact is constrained: the CVSS vector (S:U, C:N, I:L, A:L) indicates no confidentiality loss and only limited integrity and availability effects, consistent with unauthorized deletion of individual same-type configuration objects rather than a broad compromise of the Zscaler tenant.
Know when Zscaler Mcp Server gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:L
Authenticated MCP client with a valid token (PR:L, UI:R); replay causes unauthorized same-type resource deletion (I:L/A:L) with no data disclosure (C:N).
Primary rating from Vendor (Zscaler).
CVSS VectorVendor: Zscaler
Lifecycle Timeline
1DescriptionCVE.org
Zscaler MCP Server versions 0.7.0 and 0.7.1 has an issue where HMAC confirmation tokens were not bound to the target resource identifier, allowing an MCP client or agent to replay a token generated for one resource to affect another resource of the same type. This issue is fixed in version 0.7.2.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
EUVD-2026-88244
GHSA-6wjq-5f4c-p8f7
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB