Zscaler Mcp Server
Monthly
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.
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.