ZenML server counts need a service-account review

ZenML connects pipelines, stacks, components, service connectors, and deployment infrastructure. A ZenML server may expose a UI, an OpenAPI interface, pipeline metadata, secrets, and service accounts. The exposed endpoint matters, but the more useful security question is whether an API key can act across organizations and workspaces with more authority than the workflow needs.

Measurement

On 2026-11-03 UTC, ZoomEye was queried with page 1, pagesize=1, and sub_type=all. app="ZenML" returned 179 observations. title="ZenML" returned 528.

The application count is a reasonable primary discovery set. The title count is a broader lead list and should not be added to it. Both are matching observations, not confirmed vulnerable servers.

API keys are long-lived paths into the server

ZenML's API documentation describes interactive user login, service accounts, and API keys. It recommends using a short-lived token exchanged from the API key rather than sending the long-lived key with every request. The service-account documentation says API keys can access the ZenML server and should be rotated and deactivated when no longer needed.

That guidance is directly useful for exposure review. A key found in a CI job or notebook may have the same permissions as the service account that created it. The operator should determine the account's roles, the workspaces it can reach, and whether a token exchange is in use.

Review the surrounding stack

ZenML service connectors can hold credentials to cloud resources. The documentation warns that implicit authentication can give users access to the same resources as the ZenML server and recommends temporary, down-scoped credentials where possible. A server exposure therefore intersects with the credentials stored in connectors, not just the permissions of a ZenML user.

For each confirmed deployment, inventory the API host, workspace, identity provider, service accounts, active API keys, and connectors. Confirm that users cannot create or alter service accounts beyond their role. Review which pipeline runs can use each connector and whether the target resource enforces its own authorization.

Investigate safely

Do not test an unknown public server with a pipeline run or a secret request. Start with ownership records and controlled requests that cannot change state. In a non-production workspace, verify that a short-lived token expires, that a revoked account loses API access, and that one workspace cannot use a service connector assigned to another.

Review server and audit logs for new service accounts, API-key creation, connector changes, and unusual pipeline runs. Preserve the relevant records before revoking a key. If a key was exposed, revoke it, rotate the associated connector credentials, and inspect the cloud resources the connector could reach.

Practical response

Restrict unwanted public access to the server and OpenAPI interface. Prefer short-lived tokens over long-lived API keys in request headers. Scope service accounts to the workspaces and tasks they need, and remove implicit or inherited credentials that are not required.

Use the 179 application observations as a prioritized lead set and the 528 title observations as a secondary review queue. The responsible conclusion is that ZenML-branded surfaces exist and that owner-specific authentication and connector scope must be checked. The counts alone do not establish that any particular server is insecure.

References

• ZenML OSS API authentication
• ZenML service accounts
• ZenML service-connector security