al-ice.ai

ZenML Stack Endpoint Exposed Cross-Tenant Deployment Metadata — CVE-2026-11876

AI Vulnerabilities & CVEs by al-ice.ai Editorial

An authorization gap in ZenML’s stack-deployment API allowed any authenticated user to request information about deployed stacks belonging to other users and tenants. The disclosed response could include stack components, service-connector information, owner user IDs, infrastructure topology, and deployment metadata. The issue is tracked as CVE-2026-11876 and is fixed in ZenML 0.95.0.

The CVE record identifies version 0.94.2 and marks releases before 0.95.0 as affected. The CNA assigned CVSS 3.0 score 5.0, with low confidentiality impact and no direct integrity or availability impact. That medium score should not be read as “only cosmetic”: connector and infrastructure metadata can give a low-privileged tenant a map for later credential, cloud, pipeline, or lateral-movement attacks.

ZenML shipped the repair in 0.95.0 on June 17; the CVE became public on July 21 and CISA’s ADP update recorded a proof of concept on July 22. Operators on 0.94.x or older should move to a current supported release rather than relying on network placement to compensate for missing object-level authorization.

The endpoint crossed two authorization layers

The affected route was GET /api/v1/stack-deployment/stack, implemented by get_deployed_stack. According to the CVE description, it lacked an endpoint-level RBAC check and created a server-side Client() that accessed the database through SqlZenStore, bypassing the normal RBAC enforcement layer. An authenticated request could therefore retrieve a deployed stack without proving permission to read the underlying objects.

This is a recurring API failure mode: the outer route appears protected because authentication is present, while an internal convenience client operates with service authority. Authentication answers who called. It does not answer whether that caller may read this stack, its connector, or another tenant’s deployment.

The patch is compact but instructive. ZenML added permission helpers, verifies READ access for both the deployed stack and its associated service connector, and dehydrates the response model before returning it. The 0.95.0 release notes explicitly describe those two authorization checks. Fixing only the stack check would have left connector metadata reachable through an authorized parent object.

Metadata is a credential-adjacent asset

The public record does not claim that CVE-2026-11876 directly returned secret values, enabled code execution, or modified deployments. Its documented impact is cross-tenant reconnaissance. That distinction matters: defenders should not inflate the bug into a credential leak, but they should also avoid treating service-connector details as harmless inventory.

In an ML platform, stack metadata can disclose which orchestrators, artifact stores, container registries, cloud integrations, and execution backends are in use. Owner identifiers and connector relationships help an attacker select identities and interfaces for follow-on attempts. The exposed information can shorten discovery even when actual tokens remain encrypted or hidden.

The tenant-isolation pattern resembles the n8n-MCP backup flaws, though the documented impact differs. Both show why an authenticated automation platform must enforce authorization again at every object boundary. A user’s ability to invoke an API route must not imply visibility into every workflow, stack, connector, or backup the service account can access.

Upgrade and investigate, not just patch

  • Upgrade to ZenML 0.95.0 or later. Prefer the latest supported release and account for the documented 0.95.0 breaking changes and the debug-log deadlock fixed in 0.95.1.
  • Inventory exposed servers. Identify multi-user or multi-tenant ZenML deployments that ran a release before 0.95.0, including managed, self-hosted, staging, and internet-reachable instances.
  • Review access logs. Search for calls to /api/v1/stack-deployment/stack by low-privileged identities, unusual tenants, unexpected source addresses, or users with no operational reason to inspect deployment metadata.
  • Correlate follow-on activity. Check whether suspicious enumeration was followed by connector access, secret-resolution attempts, stack or pipeline queries, new API keys, repository access, cloud authentication, or deployment changes.
  • Rotate selectively when evidence warrants it. The CVE does not establish direct secret disclosure. Rotate connector or cloud credentials if logs indicate suspicious use, if sensitive values were present in locally customized responses, or if access history cannot be reconstructed.
  • Test object-level isolation. Build negative tests using two tenants and multiple roles. Assert that a user cannot read stacks, connectors, artifacts, secrets, or deployment metadata owned by the other tenant—even through nested and convenience endpoints.
  • Keep internal clients least-privileged. Server-side clients that bypass policy should be narrowly isolated and never fed user-selected object identifiers without an explicit authorization check at the boundary.

CVE-2026-11876 is a useful reminder that ML orchestration metadata sits inside the security boundary. Stacks connect code, infrastructure, secrets, and execution. A route that exposes those relationships across tenants can provide the reconnaissance layer for a much more consequential attack, even when its immediate CVSS impact is limited to confidentiality.

Sources: